[Twisted-Python] Permissions to trigger buildbot tests
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 10:04 am, adi@roiban.ro wrote:
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".
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 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
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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>>)
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 01:46 am, glyph@twistedmatrix.com wrote:
Hmmm okay. :P
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On Mon Nov 17 2014 at 2:18:13 PM Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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:
-- Adi Roiban
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 13:44, <exarkun@twistedmatrix.com> wrote:
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!
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 16 November 2014 22:44, <exarkun@twistedmatrix.com> wrote:
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
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 11:04, Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 11:55, <exarkun@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 12:10 pm, adi@roiban.ro wrote:
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 09:44 am, adi@roiban.ro wrote:
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?
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 13:40, <exarkun@twistedmatrix.com> wrote:
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.
Will search for it and try to update the wiki. Thanks!
-- Adi Roiban
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 14:21, Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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:
-- Adi Roiban
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 10:04 am, adi@roiban.ro wrote:
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".
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 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
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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>>)
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 01:46 am, glyph@twistedmatrix.com wrote:
Hmmm okay. :P
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/1327ce755b24b956995d68accae3eab2.jpg?s=120&d=mm&r=g)
On Mon Nov 17 2014 at 2:18:13 PM Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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:
-- Adi Roiban
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 13:44, <exarkun@twistedmatrix.com> wrote:
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!
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 16 November 2014 22:44, <exarkun@twistedmatrix.com> wrote:
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
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 11:04, Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 11:55, <exarkun@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 12:10 pm, adi@roiban.ro wrote:
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
![](https://secure.gravatar.com/avatar/607cfd4a5b41fe6c886c978128b9c03e.jpg?s=120&d=mm&r=g)
On 09:44 am, adi@roiban.ro wrote:
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?
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 13:40, <exarkun@twistedmatrix.com> wrote:
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.
Will search for it and try to update the wiki. Thanks!
-- Adi Roiban
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 17 November 2014 14:21, Glyph <glyph@twistedmatrix.com> wrote:
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
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
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:
-- Adi Roiban
participants (5)
-
Adi Roiban
-
exarkun@twistedmatrix.com
-
Glyph
-
Glyph Lefkowitz
-
Jonathan Lange