[Twisted-Python] Permissions to trigger buildbot tests
Hi, To help with the review process I would like to ask permissions for triggering buildbot builds. Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo? -------- In the same time, maybe we can write a few words about the steps required for a new contributor to become a full reviewer. Ex. 1. Contribute a few patches (ex 10) and learn the basic review process. Observe how reviewers respond to your patch. 2. Start doing review as junior reviewer, without merging. Once you are ok with the patch, invite another core developer to take a final view and merge the patch 3. Once you have reviewed a few patches without errors (ex 10) you can ask for full review permission or a core developer will let you know that you can merge the patch without asking someone else. This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess What do you think? Is not much, but should provide some guidance and hope! Thanks! -- Adi Roiban
On 10:04 am, adi@roiban.ro wrote:
Hi,
To help with the review process I would like to ask permissions for triggering buildbot builds.
Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds. There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
--------
In the same time, maybe we can write a few words about the steps required for a new contributor to become a full reviewer. Ex.
There is no official process but the frequently discussed unofficialy process is just getting commit access. The project doesn't distinguish between committers in any way as far as the development workflow is concerned. Perhaps it should and we should discuss how it could do this.
1. Contribute a few patches (ex 10) and learn the basic review process. Observe how reviewers respond to your patch.
2. Start doing review as junior reviewer, without merging. Once you are ok with the patch, invite another core developer to take a final view and merge the patch
3. Once you have reviewed a few patches without errors (ex 10) you can ask for full review permission or a core developer will let you know that you can merge the patch without asking someone else.
This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess
What do you think?
I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are). A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc. After demonstrating competence in all areas the "junior" reviewer could advance to normal review status. Unfortunately notice I didn't say anything about the software being built or changed itself. I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code. Jean-Paul
On Nov 16, 2014, at 23:44, exarkun@twistedmatrix.com wrote:
On 10:04 am, adi@roiban.ro wrote:
Hi,
To help with the review process I would like to ask permissions for triggering buildbot builds.
Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds.
There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
--------
In the same time, maybe we can write a few words about the steps required for a new contributor to become a full reviewer. Ex.
There is no official process but the frequently discussed unofficialy process is just getting commit access. The project doesn't distinguish between committers in any way as far as the development workflow is concerned.
Perhaps it should and we should discuss how it could do this.
I think that we should have an official process; the way we do it is pretty arbitrary. An official advancement process can be a motivator for contributors, as well as a way to more clearly establish community norms. (I have a feeling if we did have an official process for getting commit access we would actually have more active committers.) (This is a good talk on the subject: <http://www.kateheddleston.com/talk/ef464595-b113-4c1b-9c5b-cc1f3681055c <http://www.kateheddleston.com/talk/ef464595-b113-4c1b-9c5b-cc1f3681055c>>)
1. Contribute a few patches (ex 10) and learn the basic review process. Observe how reviewers respond to your patch.
2. Start doing review as junior reviewer, without merging. Once you are ok with the patch, invite another core developer to take a final view and merge the patch
3. Once you have reviewed a few patches without errors (ex 10) you can ask for full review permission or a core developer will let you know that you can merge the patch without asking someone else.
This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess
What do you think?
I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are).
A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc. After demonstrating competence in all areas the "junior" reviewer could advance to normal review status.
This sounds great. Could you jot it down on a wiki page?
Unfortunately notice I didn't say anything about the software being built or changed itself. I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code.
We can easily have a suggested process for this too, if we have to have subjective evaluations, then let's just be explicit that some specific group has to make some specific evaluation... -glyph
On 01:46 am, glyph@twistedmatrix.com wrote:
On Nov 16, 2014, at 23:44, exarkun@twistedmatrix.com wrote:
On 10:04 am, adi@roiban.ro wrote:
This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess
What do you think?
I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are).
A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc. After demonstrating competence in all areas the "junior" reviewer could advance to normal review status.
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
Unfortunately notice I didn't say anything about the software being built or changed itself. I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code.
We can easily have a suggested process for this too, if we have to have subjective evaluations, then let's just be explicit that some specific group has to make some specific evaluation...
After sleeping on this, it doesn't seem quite as bad as I thought, I guess. The tracking overhead can mainly be taken on by contributors who are interested in gaining access. Casual committers can just ignore this and their lives will be unchanged. Perhaps we can put together a committer "bingo card" and let people fill in the boxes. When someone has checked all the boxes they can hand over the information to a ... review committee? to verify everything looks good or point out areas where improvement is needed (either because some task didn't really satisfy a box or because of subjective reasons). Jean-Paul
On 11:48 am, exarkun@twistedmatrix.com wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical). Jean-Paul
On Nov 17, 2014, at 14:44, exarkun@twistedmatrix.com wrote:
On 11:48 am, exarkun@twistedmatrix.com wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical).
Thank you so much for doing this, JP. I've wanted to do something about onboarding for a while and it's just been difficult to work up the enthusiasm. -glyph
On Mon Nov 17 2014 at 2:18:13 PM Glyph <glyph@twistedmatrix.com> wrote:
On Nov 17, 2014, at 14:44, exarkun@twistedmatrix.com wrote:
On 11:48 am, exarkun@twistedmatrix.com wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ ContributorAdvancementPath>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical).
Thank you so much for doing this, JP. I've wanted to do something about onboarding for a while and it's just been difficult to work up the enthusiasm.
Thanks indeed! I like this idea, and think it's worth trying. I can participate in one or two candidate reviews (depending on exactly when). jml
Based on feedback I assume that this is a dead end and for now new contributions will still need to find for themselves what is the path for becoming a core contributor. I would like to ask commit permission, at least to merge the 10 patches from eeshangarg ... as looks like there is little interest in merging the cleanup work. Thanks! On 22 November 2014 at 14:59, Jonathan Lange <jml@mumak.net> wrote:
On Mon Nov 17 2014 at 2:18:13 PM Glyph <glyph@twistedmatrix.com> wrote:
On Nov 17, 2014, at 14:44, exarkun@twistedmatrix.com wrote:
On 11:48 am, exarkun@twistedmatrix.com wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ ContributorAdvancementPath>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical).
Thank you so much for doing this, JP. I've wanted to do something about onboarding for a while and it's just been difficult to work up the enthusiasm.
Thanks indeed!
I like this idea, and think it's worth trying. I can participate in one or two candidate reviews (depending on exactly when).
jml
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Adi Roiban
On Jan 22, 2015, at 2:12 AM, Adi Roiban <adi@roiban.ro> wrote:
Based on feedback I assume that this is a dead end and for now new contributions will still need to find for themselves what is the path for becoming a core contributor.
Characterizing this as a "dead end" is probably inaccurate. There seems to be consensus that it would be a good idea if someone had the time to do it. For now though, your conclusion is probably right.
I would like to ask commit permission, at least to merge the 10 patches from eeshangarg ... as looks like there is little interest in merging the cleanup work.
Since I'd offered it to you in the past and you'd turned it down, I'm happy to reverse that decision :). I take it that https://github.com/adiroiban.keys <https://github.com/adiroiban.keys> is an adequate source of credential material for you? -glyph
Thanks!
On 22 November 2014 at 14:59, Jonathan Lange <jml@mumak.net <mailto:jml@mumak.net>> wrote: On Mon Nov 17 2014 at 2:18:13 PM Glyph <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
On Nov 17, 2014, at 14:44, exarkun@twistedmatrix.com <mailto:exarkun@twistedmatrix.com> wrote:
On 11:48 am, exarkun@twistedmatrix.com <mailto:exarkun@twistedmatrix.com> wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath>>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical).
Thank you so much for doing this, JP. I've wanted to do something about onboarding for a while and it's just been difficult to work up the enthusiasm.
Thanks indeed!
I like this idea, and think it's worth trying. I can participate in one or two candidate reviews (depending on exactly when).
jml
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
-- Adi Roiban _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On 17 November 2014 13:44, <exarkun@twistedmatrix.com> wrote:
On 11:48 am, exarkun@twistedmatrix.com wrote:
This sounds great. Could you jot it down on a wiki page?
Hmmm okay. :P
I wrote up <https://twistedmatrix.com/trac/wiki/Proposal/ ContributorAdvancementPath>. Notice "Proposal" in the URL. It would be nice to get feedback from some more contributors - particularly people who have recently gotten commit access (about whether the problems are real and what they think of the proposed solutions) but also from other long-time Twisted contributors about whether they like this new idea about how to bring more people in (and whether they would volunteer to do the necessary candidate reviews - without which effort this isn't practical).
Many thanks! Twisted requires a high/excellent quality for contributions. This is great and hope it will never change and will never lower the barrier. As a new developer, who was formed in a mediocre university and working for a mediocre/shitty company, learning what are the real good manners is not easy. Having the possibility to progress based on well defined skill/competencies should make it easier to contribute and solve at least some of the tickets from the review queue. Once the skills are defined I am up for setting up a page and following the process. What is not clear for me, is in what circumstance I can consider a patch or review successful and able to put in on my progress page / bingo card ? Thanks!
On 16 November 2014 22:44, <exarkun@twistedmatrix.com> wrote:
On 10:04 am, adi@roiban.ro wrote:
Hi,
To help with the review process I would like to ask permissions for triggering buildbot builds.
Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds.
There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
I got them. Is there a wiki page describing how buildbot should be used? I found some notes hidden in the review process page... it looks like builds are triggered from the web page with click. The review page also talks about a misterious force-builds.py script which is not part of the main twisted repo.. or at least, I could not found it I was expecting a buidbot try scheduler and use buildbot command line tools to trigger remote tests
--------
In the same time, maybe we can write a few words about the steps required for a new contributor to become a full reviewer. Ex.
There is no official process but the frequently discussed unofficialy process is just getting commit access. The project doesn't distinguish between committers in any way as far as the development workflow is concerned.
Perhaps it should and we should discuss how it could do this.
1. Contribute a few patches (ex 10) and learn the basic review process. Observe how reviewers respond to your patch.
2. Start doing review as junior reviewer, without merging. Once you are ok with the patch, invite another core developer to take a final view and merge the patch
3. Once you have reviewed a few patches without errors (ex 10) you can ask for full review permission or a core developer will let you know that you can merge the patch without asking someone else.
This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess
What do you think?
I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are).
A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc. After demonstrating competence in all areas the "junior" reviewer could advance to normal review status.
Unfortunately notice I didn't say anything about the software being built or changed itself. I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code.
Ok. In this case, maybe just a note that developers should send enough patches and do enough "junior reviews" until their patches are submitted for the first time without major errors and no major errors pass their initial review.. this is close to common sense, but some might argue that there is no such thing as common sense. -- Adi Roiban
On 17 November 2014 09:44, Adi Roiban <adi@roiban.ro> wrote: [snip] There's no standard policy or procedure for granting commit access to the
repository. Usually it goes like "someone asks for it, someone gives it to them".
I got them.
Is there a wiki page describing how buildbot should be used?
I found some notes hidden in the review process page... it looks like builds are triggered from the web page with click. The review page also talks about a misterious force-builds.py script which is not part of the main twisted repo.. or at least, I could not found it
I was expecting a buidbot try scheduler and use buildbot command line tools to trigger remote tests
I tried to use buildbot, but I failed :) I want to ask buildbot to run the test for a patch: * apply the patch to trunk * run all test * publish a link to trac How do I do that without creating a branch, ie requiring write permissions to main repo? Thanks! [snip] -- Adi Roiban
On Nov 17, 2014, at 10:53, Adi Roiban <adi@roiban.ro> wrote:
I tried to use buildbot, but I failed :)
I want to ask buildbot to run the test for a patch: * apply the patch to trunk * run all test * publish a link to trac
How do I do that without creating a branch, ie requiring write permissions to main repo?
This is not currently possible. Permission to get the buildbots to run code is managed via write permissions to the SVN repository. In other words: we do not have a buildbot try scheduler. -glyph
On 17 November 2014 11:04, Glyph <glyph@twistedmatrix.com> wrote:
On Nov 17, 2014, at 10:53, Adi Roiban <adi@roiban.ro> wrote:
I tried to use buildbot, but I failed :)
I want to ask buildbot to run the test for a patch: * apply the patch to trunk * run all test * publish a link to trac
How do I do that without creating a branch, ie requiring write permissions to main repo?
This is not currently possible. Permission to get the buildbots to run code is managed via write permissions to the SVN repository. In other words: we do not have a buildbot try scheduler.
Can I then get write permissions for SVN repo? I will not touch trunk, only create branches for tests. ---- Is there a reason why a try scheduler is not implemented? I find it awesome for TDD! On my normal workflow I can do this, even without commiting changes: ./HELPER test some.test ./HELPER test-remote sol-10-sparc some.test test-remote just wraps buildot try --builder --properties --wait --vc -- Adi Roiban
On 11:48 am, adi@roiban.ro wrote:
Is there a reason why a try scheduler is not implemented? I find it awesome for TDD!
On my normal workflow I can do this, even without commiting changes:
./HELPER test some.test ./HELPER test-remote sol-10-sparc some.test
test-remote just wraps buildot try --builder --properties --wait --vc
Because it requires setting up proper credentials to access control the feature. Jean-Paul
On 17 November 2014 11:55, <exarkun@twistedmatrix.com> wrote:
On 11:48 am, adi@roiban.ro wrote:
Is there a reason why a try scheduler is not implemented? I find it awesome for TDD!
On my normal workflow I can do this, even without commiting changes:
./HELPER test some.test ./HELPER test-remote sol-10-sparc some.test
test-remote just wraps buildot try --builder --properties --wait --vc
Because it requires setting up proper credentials to access control the feature.
But there are already credentials for the HTTP status page... why not configure the same credentials for buildbot try? What I would like to hear is something like this: * buildbot try is too simple, does not work with our workflow and for our project... we don't want to spend time implementing it or * buildbot try could help, it still has some problems and we don't have time to fix issue 1, 2, 3, ... etc -- Adi Roiban
On 12:10 pm, adi@roiban.ro wrote:
On 17 November 2014 11:55, <exarkun@twistedmatrix.com> wrote:
On 11:48 am, adi@roiban.ro wrote:
Is there a reason why a try scheduler is not implemented? I find it awesome for TDD!
On my normal workflow I can do this, even without commiting changes:
./HELPER test some.test ./HELPER test-remote sol-10-sparc some.test
test-remote just wraps buildot try --builder --properties --wait --vc
Because it requires setting up proper credentials to access control the feature.
But there are already credentials for the HTTP status page... why not configure the same credentials for buildbot try?
The credentials for the HTTP status page are there to prevent annoying spurious builds. The credentials for `buildbot try` need to be serious, secure credentials because they prevent attackers from submitting arbitrary code to execute on the buildslaves. Basically, it's more work. If someone wanted to set it up right, I don't know of any reason we wouldn't want to allow it. Though that may just be because we haven't ever used it so I haven't yet learned the reasons it's undesirable to have enabled. ;) Jean-Paul
What I would like to hear is something like this:
* buildbot try is too simple, does not work with our workflow and for our project... we don't want to spend time implementing it
or
* buildbot try could help, it still has some problems and we don't have time to fix issue 1, 2, 3, ... etc
-- Adi Roiban
On 09:44 am, adi@roiban.ro wrote:
On 16 November 2014 22:44, <exarkun@twistedmatrix.com> wrote:
Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds.
There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
I got them.
Is there a wiki page describing how buildbot should be used?
I just created <https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow>. Feel free to edit it if you think parts are unclear. Or point out any questions you think it doesn't answer. I haven't linked to it from anywhere yet. Suggestions about where a good place (such that people will actually find it) welcome.
I found some notes hidden in the review process page... it looks like builds are triggered from the web page with click.
I guess maybe this would be an okay place?
The review page also talks about a misterious force-builds.py script which is not part of the main twisted repo.. or at least, I could not found it
It's part of one of the twisted dev tools repositories (used to be twisted-dev-tools but I think someone moved it, not sure exactly to where). Perhaps you could update this page to mention where - if you find it. Jean-Paul
On 17 November 2014 13:40, <exarkun@twistedmatrix.com> wrote:
On 09:44 am, adi@roiban.ro wrote:
On 16 November 2014 22:44, <exarkun@twistedmatrix.com> wrote:
Is there a wiki page describing what are the steps required for a regular
contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds.
There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
I got them.
Is there a wiki page describing how buildbot should be used?
I just created <https://twistedmatrix.com/trac/wiki/ContinuousIntegration/ DeveloperWorkflow>. Feel free to edit it if you think parts are unclear. Or point out any questions you think it doesn't answer. I haven't linked to it from anywhere yet. Suggestions about where a good place (such that people will actually find it) welcome.
I found some notes hidden in the review process page... it looks like builds are triggered from the web page with click.
I guess maybe this would be an okay place?
I have added a link to the new page in both author and reviewer section.. and remove duplicate info. I did read the review page many times but always skipped the section dedicated to comitters... I now see that username and password is public.. so I moved the credentials on the new wiki page. Feel free to remove them.
The review page also talks about a misterious force-builds.py script which
is not part of the main twisted repo.. or at least, I could not found it
It's part of one of the twisted dev tools repositories (used to be twisted-dev-tools but I think someone moved it, not sure exactly to where). Perhaps you could update this page to mention where - if you find it.
Will search for it and try to update the wiki. Thanks!
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Adi Roiban
On Nov 17, 2014, at 14:40, exarkun@twistedmatrix.com wrote:
The review page also talks about a misterious force-builds.py script which is not part of the main twisted repo.. or at least, I could not found it
It's part of one of the twisted dev tools repositories (used to be twisted-dev-tools but I think someone moved it, not sure exactly to where). Perhaps you could update this page to mention where - if you find it.
Since we've added the buildbot link to trac pages, force-builds.py is basically obsolete. I think we should just scrub all mentions of it, and probably delete it. However, here's where it lives now: <https://github.com/twisted/twisted-dev-tools/blob/master/bin/force-build <https://github.com/twisted/twisted-dev-tools/blob/master/bin/force-build>> -glyph
On 17 November 2014 14:21, Glyph <glyph@twistedmatrix.com> wrote:
On Nov 17, 2014, at 14:40, exarkun@twistedmatrix.com wrote:
The review page also talks about a misterious force-builds.py script which is not part of the main twisted repo.. or at least, I could not found it
It's part of one of the twisted dev tools repositories (used to be twisted-dev-tools but I think someone moved it, not sure exactly to where). Perhaps you could update this page to mention where - if you find it.
Since we've added the buildbot link to trac pages, force-builds.py is basically obsolete. I think we should just scrub all mentions of it, and probably delete it.
I can take care of this
https://github.com/twisted/twisted-dev-tools/issues/5 Can you please update the wiki page https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow to describe how builds are linked to tickets? Thanks! -- Adi Roiban
On Nov 17, 2014, at 15:43, Adi Roiban <adi@roiban.ro> wrote:
Can you please update the wiki page https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow <https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow> to describe how builds are linked to tickets?
I may have been overly verbose, so feel free to edit it, but I added a new section on this. -glyph
Looks good. I would like to ask write permissions for Twisted SVN repo. For now, I plan to use this power to create branches for tickets in the review queue launch a buildbot test for a submitted patch. I think that this will make my review more useful as the developer could see the exact impact of the patch against the test. What do you think? Thanks! On 19 November 2014 14:47, Glyph <glyph@twistedmatrix.com> wrote:
On Nov 17, 2014, at 15:43, Adi Roiban <adi@roiban.ro> wrote:
Can you please update the wiki page https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow to describe how builds are linked to tickets?
I may have been overly verbose, so feel free to edit it, but I added a new section on this.
-glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Adi Roiban
I am certainly in favor, especially given that I had already offered commit access based on our previous informal process for this very reason :-). -glyph
On Nov 25, 2014, at 09:52, Adi Roiban <adi@roiban.ro> wrote:
Looks good.
I would like to ask write permissions for Twisted SVN repo. For now, I plan to use this power to create branches for tickets in the review queue launch a buildbot test for a submitted patch. I think that this will make my review more useful as the developer could see the exact impact of the patch against the test.
What do you think?
Thanks!
On 19 November 2014 14:47, Glyph <glyph@twistedmatrix.com <mailto:glyph@twistedmatrix.com>> wrote:
On Nov 17, 2014, at 15:43, Adi Roiban <adi@roiban.ro <mailto:adi@roiban.ro>> wrote:
Can you please update the wiki page https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow <https://twistedmatrix.com/trac/wiki/ContinuousIntegration/DeveloperWorkflow> to describe how builds are linked to tickets?
I may have been overly verbose, so feel free to edit it, but I added a new section on this.
-glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
-- Adi Roiban _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (5)
-
Adi Roiban -
exarkun＠twistedmatrix.com -
Glyph -
Glyph Lefkowitz
-
Jonathan Lange