From ezio.melotti at gmail.com Sat Jul 5 14:46:21 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 5 Jul 2014 15:46:21 +0300 Subject: [core-workflow] Use buildbot to test tracker patches Message-ID: Hi, I recently had a chance to learn a bit more about buildbot, and it occurred to me than adding a new builder for testing tracker patches shouldn't be too difficult. This is how it should work: 1) a new "Test with buildbot" (or whatever) button is added to the tracker next to each patch, and developers/triagers can press it to trigger the build; 2) the buildbot builder receives the URL of the issue and of the patch and run all the usual steps with two differences: a) a new step to run "hg import --no-c url_of_the_patch" is added after the cloning step; b) an email with the results is sent back to the bug tracker once the slaves are done; Unless I'm missing something, both these changes should be trivial. On the tracker side is enough to add a form with a couple of (hidden) fields with the URLs and a submit button. On the buildbot side it should be enough to create a new builder (by copying one of the existing ones in the buildbot config file and adding the two steps mentioned above). Putting together a mail summary with the results of all the slaves might require a bit of extra code, but it shouldn't be anything too difficult. Some of the issues with this proposal are: 1) users uploading patches with malicious code -- this shouldn't be a problem if we only allow developers/triagers to trigger the build manually and tell them to review the code before doing so; 2) overloading of the slaves -- cloning/compiling/testing/cleaning takes quite a lot of time, and if this new feature starts to be used heavily it might start to give too much work for the slaves. I don't know what the current load is though, so I'm not sure this will be an issue; 3) testing/implementing the feature -- I think it should be possible to test the feature locally before actually applying the changes on the real buildbot master, but unless someone is going to apply them on my behalf I would probably need access to the buildbot repo (is there a public repo?); 4) determine which branch the patch should be applied to -- this could be done by adding a new "branch" field on the tracker; rietveld could use it too; 5) if the patch fails to apply there's no need to launch the build on all the slaves -- a single slave (or maybe even the master?) could check if the patch applies cleanly, and if it does trigger all the other slaves. More fine-grained options could be added to the request form too (e.g. run only on specific slaves/operating systems); If the idea is reasonable and I didn't miss anything I can try to find some time to work on it. Best Regards, Ezio Melotti From techtonik at gmail.com Sat Jul 5 16:45:57 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 5 Jul 2014 17:45:57 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On Sat, Jul 5, 2014 at 3:46 PM, Ezio Melotti wrote: > > This is how it should work: > 1) a new "Test with buildbot" (or whatever) button is added to the > tracker next to each patch, and developers/triagers can press it to > trigger the build; > 2) the buildbot builder receives the URL of the issue and of the > patch and run all the usual steps with two differences: > a) a new step to run "hg import --no-c url_of_the_patch" is added > after the cloning step; > b) an email with the results is sent back to the bug tracker once > the slaves are done; How about a separate CI service that automatically testes all patches submitted and Roundup server just fetches their status. Similar how Travis CI works on Github to check the status of commits in pull requests. > Unless I'm missing something, both these changes should be trivial. > On the tracker side is enough to add a form with a couple of (hidden) > fields with the URLs and a submit button. On the buildbot side it > should be enough to create a new builder (by copying one of the > existing ones in the buildbot config file and adding the two steps > mentioned above). Putting together a mail summary with the results of > all the slaves might require a bit of extra code, but it shouldn't be > anything too difficult. Yep. It is feasible. > Some of the issues with this proposal are: > 1) users uploading patches with malicious code -- this shouldn't be > a problem if we only allow developers/triagers to trigger the build > manually and tell them to review the code before doing so; No. Make environment safe from abuse. People will be tempted to press button ASAP, because process takes time to complete. For an example of safe service see drone.io (open source, Go). > 2) overloading of the slaves -- cloning/compiling/testing/cleaning > takes quite a lot of time, and if this new feature starts to be used > heavily it might start to give too much work for the slaves. I don't > know what the current load is though, so I'm not sure this will be an > issue; The public information on http://speed.python.org tells me that it is still unused. > 3) testing/implementing the feature -- I think it should be possible > to test the feature locally before actually applying the changes on > the real buildbot master, but unless someone is going to apply them on > my behalf I would probably need access to the buildbot repo (is there > a public repo?); Making it a separate patch tracker service will allow to reuse it for different projects and more easy customization. I don't want people to learn Roundup, TAL and other ancient technologies just to improve this code. If you don't mind against starting from other's code: 1. Google Chromium Try Server http://www.chromium.org/developers/testing/try-server-usage 2. Mercurial Patch Tracker http://patchwork.serpentine.com/project/hg/list/ > 4) determine which branch the patch should be applied to -- this > could be done by adding a new "branch" field on the tracker; rietveld > could use it too; patch can be valid for multiple branches, properly exported patch has a header with parent revision. > 5) if the patch fails to apply there's no need to launch the build > on all the slaves -- a single slave (or maybe even the master?) could > check if the patch applies cleanly, and if it does trigger all the > other slaves. More fine-grained options could be added to the request > form too (e.g. run only on specific slaves/operating systems); More useful thing IMHO is to detect which commit broke which patch. > If the idea is reasonable and I didn't miss anything I can try to find > some time to work on it. The idea is awesome. -- anatoly t. From francismb at email.de Sat Jul 5 19:06:31 2014 From: francismb at email.de (francis) Date: Sat, 05 Jul 2014 19:06:31 +0200 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: <53B83097.8010407@email.de> On 07/05/2014 02:46 PM, Ezio Melotti wrote: > 1) a new "Test with buildbot" (or whatever) button is added to the > tracker next to each patch, and developers/triagers can press it to > trigger the build; Just an small detail/question: does it make a difference to change the "trigger the build"-button with a "continuously check this patch" -checkbox? The idea is not to check when the button is pressed (if I've understood the original idea correctly) but just to set the check and from then on get continuously feedback that's (still) working (e.g. with a small green icon nearby the patch). Regards, francis From ezio.melotti at gmail.com Sat Jul 5 19:24:10 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 5 Jul 2014 20:24:10 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On Sat, Jul 5, 2014 at 5:45 PM, anatoly techtonik wrote: > On Sat, Jul 5, 2014 at 3:46 PM, Ezio Melotti wrote: >> >> This is how it should work: >> 1) a new "Test with buildbot" (or whatever) button is added to the >> tracker next to each patch, and developers/triagers can press it to >> trigger the build; >> 2) the buildbot builder receives the URL of the issue and of the >> patch and run all the usual steps with two differences: >> a) a new step to run "hg import --no-c url_of_the_patch" is added >> after the cloning step; >> b) an email with the results is sent back to the bug tracker once >> the slaves are done; > > How about a separate CI service that automatically testes all patches > submitted and Roundup server just fetches their status. Similar how > Travis CI works on Github to check the status of commits in pull > requests. > That would be better, but I'm not able to do that currently (due to lack of knowledge/time). My suggestion shouldn't take more than a weekend of work, so I might give it a shot. >> Unless I'm missing something, both these changes should be trivial. >> On the tracker side is enough to add a form with a couple of (hidden) >> fields with the URLs and a submit button. On the buildbot side it >> should be enough to create a new builder (by copying one of the >> existing ones in the buildbot config file and adding the two steps >> mentioned above). Putting together a mail summary with the results of >> all the slaves might require a bit of extra code, but it shouldn't be >> anything too difficult. > > Yep. It is feasible. > >> Some of the issues with this proposal are: >> 1) users uploading patches with malicious code -- this shouldn't be >> a problem if we only allow developers/triagers to trigger the build >> manually and tell them to review the code before doing so; > > No. Make environment safe from abuse. People will be tempted to > press button ASAP, because process takes time to complete. For an > example of safe service see drone.io (open source, Go). > This also would be a better solution but I'm unable to do that (also because I think this should be done for the individual slaves, and might be different depending on the OS and other things). FWIW I know of projects that trust the contributors and just test all the patches that get submitted and so far they never had problems, but I understand that is better to err on the safe side. Requiring the build to be manually triggered by devs after a review sounds like a good compromise until we have a better solution. >> 2) overloading of the slaves -- cloning/compiling/testing/cleaning >> takes quite a lot of time, and if this new feature starts to be used >> heavily it might start to give too much work for the slaves. I don't >> know what the current load is though, so I'm not sure this will be an >> issue; > > The public information on http://speed.python.org tells me that it is > still unused. > >> 3) testing/implementing the feature -- I think it should be possible >> to test the feature locally before actually applying the changes on >> the real buildbot master, but unless someone is going to apply them on >> my behalf I would probably need access to the buildbot repo (is there >> a public repo?); > > Making it a separate patch tracker service will allow to reuse it for > different projects and more easy customization. Are you suggesting that other projects reuse our code to test their own patches on their own buildbots or that they reuse our buildbots to test their things by using our code? In both cases I'm not sure there's much to reuse, since they might have a different bug tracker and they will probably want different building steps. > I don't want people > to learn Roundup, TAL and other ancient technologies just to improve > this code. If you don't mind against starting from other's code: > That would requires us to switch to more recent technologies, and is also something that can't be done in a weekend :) > 1. Google Chromium Try Server > http://www.chromium.org/developers/testing/try-server-usage > 2. Mercurial Patch Tracker > http://patchwork.serpentine.com/project/hg/list/ > >> 4) determine which branch the patch should be applied to -- this >> could be done by adding a new "branch" field on the tracker; rietveld >> could use it too; > > patch can be valid for multiple branches, properly exported patch > has a header with parent revision. > Patches created with "hg diff" that don't use the --git format do, but they have other limitations. Patches created with "hg export" might have all the required informations, though I'm not sure if they are automatically applied to the tip of the branch or somewhere else. >> 5) if the patch fails to apply there's no need to launch the build >> on all the slaves -- a single slave (or maybe even the master?) could >> check if the patch applies cleanly, and if it does trigger all the >> other slaves. More fine-grained options could be added to the request >> form too (e.g. run only on specific slaves/operating systems); > > More useful thing IMHO is to detect which commit broke which patch. > That would require to re-test all the tracker patches every time a commit is done, right? What I was thinking is that whenever someone is going to work on an old patch, he could retrigger the build manually from the bug tracker and see if anything changed. >> If the idea is reasonable and I didn't miss anything I can try to find >> some time to work on it. > > The idea is awesome. > -- > anatoly t. From ezio.melotti at gmail.com Sat Jul 5 19:43:08 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 5 Jul 2014 20:43:08 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: <53B83097.8010407@email.de> References: <53B83097.8010407@email.de> Message-ID: On Sat, Jul 5, 2014 at 8:06 PM, francis wrote: > On 07/05/2014 02:46 PM, Ezio Melotti wrote: >> >> 1) a new "Test with buildbot" (or whatever) button is added to the >> tracker next to each patch, and developers/triagers can press it to >> trigger the build; > > > Just an small detail/question: does it make a difference to change the > "trigger the build"-button with a "continuously check this patch" > -checkbox? The idea is not to check when the button is pressed > (if I've understood the original idea correctly) but just to set the > check and from then on get continuously feedback that's (still) working > (e.g. with a small green icon nearby the patch). The advantage of this is that people can know immediately if a patch still applies (assuming someone checked the checkbox before and that the check runs often enough). However this will waste lot of machine time if no one is looking at the patch for a long time, especially if we consider that there are over 2000 patches currently on the tracker. On the technical side there are two issues: 1) it's easier to send the request whenever someone press the button, rather than having something that keeps track of all the patches that need to be checked and either keeps checking it or keeps sending requests to the buildbot master; 2) the green icon is a good idea, but also requires either a different way for the buildbot master to inform the tracker of the results, or some way to intercept the email send to the tracker and convert it to a green/red icon instead of adding a regular message. A third and simpler option is to just add the icon via JS on the client-side, and possibly also collapse buildbot messages so that they don't flood the message list. > > Regards, > francis > From techtonik at gmail.com Sat Jul 5 20:20:10 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 5 Jul 2014 21:20:10 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: <53B83097.8010407@email.de> Message-ID: On Sat, Jul 5, 2014 at 8:43 PM, Ezio Melotti wrote: > On Sat, Jul 5, 2014 at 8:06 PM, francis wrote: >> On 07/05/2014 02:46 PM, Ezio Melotti wrote: >>> >>> 1) a new "Test with buildbot" (or whatever) button is added to the >>> tracker next to each patch, and developers/triagers can press it to >>> trigger the build; >> >> >> Just an small detail/question: does it make a difference to change the >> "trigger the build"-button with a "continuously check this patch" >> -checkbox? The idea is not to check when the button is pressed >> (if I've understood the original idea correctly) but just to set the >> check and from then on get continuously feedback that's (still) working >> (e.g. with a small green icon nearby the patch). > > The advantage of this is that people can know immediately if a patch > still applies (assuming someone checked the checkbox before and that > the check runs often enough). > However this will waste lot of machine time if no one is looking at > the patch for a long time, especially if we consider that there are > over 2000 patches currently on the tracker. We already know which files patch touches: https://bitbucket.org/techtonik/python-stdlib/src/567adbfaa3bf1de905949e38a27bee0334081174/modstats.py?at=default#cl-167 so we can automatically detect a subset of patches to try on each commit. We only need a DB with analyzed patch info to run queries. Independent pieces of code that need to be implemented as I see it: 1. [x] patch upload -> [ ] patch detection -> [ ] patch reaction -> -> [x] patch analysis (get paths) -> [ ] store info (I'd use some key/value) 2. [ ] post-commit hook to detect broken patches -> [ ] detect paths -> -> [ ] run query to select patches -> [ ] schedule patch tests against specific commits 3. [ ] get patch from the test queue -> [ ] checkout revision -> [ ] test -> [ ] store result to DB 4. [ ] roundup GUI indicator -> [ ] query DB for patch status > On the technical side there are two issues: > 1) it's easier to send the request whenever someone press the > button, rather than having something that keeps track of all the > patches that need to be checked and either keeps checking it or keeps > sending requests to the buildbot master; > 2) the green icon is a good idea, but also requires either a > different way for the buildbot master to inform the tracker of the > results, or some way to intercept the email send to the tracker and > convert it to a green/red icon instead of adding a regular message. A > third and simpler option is to just add the icon via JS on the > client-side, and possibly also collapse buildbot messages so that they > don't flood the message list. JS that accesses specific URL about patch status. http://hostname/patches/file5555/status { status: "ok", # "check pending..", "broken by commit..", "applied.." } The task seems huge, so instead of making half-baked hack, I propose to add some engineering - write down the roadmap above and concentrate on that, then allow people to have fun adding meat to the bones. This will be a good practice to test more focused distributed workflow. -- anatoly t. From breamoreboy at yahoo.co.uk Sat Jul 5 20:30:46 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sat, 05 Jul 2014 19:30:46 +0100 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On 05/07/2014 13:46, Ezio Melotti wrote: > Hi, > I recently had a chance to learn a bit more about buildbot, and it > occurred to me than adding a new builder for testing tracker patches > shouldn't be too difficult. > > This is how it should work: > 1) a new "Test with buildbot" (or whatever) button is added to the > tracker next to each patch, and developers/triagers can press it to > trigger the build; > 2) the buildbot builder receives the URL of the issue and of the > patch and run all the usual steps with two differences: > a) a new step to run "hg import --no-c url_of_the_patch" is added > after the cloning step; > b) an email with the results is sent back to the bug tracker once > the slaves are done; > > Unless I'm missing something, both these changes should be trivial. > On the tracker side is enough to add a form with a couple of (hidden) > fields with the URLs and a submit button. On the buildbot side it > should be enough to create a new builder (by copying one of the > existing ones in the buildbot config file and adding the two steps > mentioned above). Putting together a mail summary with the results of > all the slaves might require a bit of extra code, but it shouldn't be > anything too difficult. > > Some of the issues with this proposal are: > 1) users uploading patches with malicious code -- this shouldn't be > a problem if we only allow developers/triagers to trigger the build > manually and tell them to review the code before doing so; > 2) overloading of the slaves -- cloning/compiling/testing/cleaning > takes quite a lot of time, and if this new feature starts to be used > heavily it might start to give too much work for the slaves. I don't > know what the current load is though, so I'm not sure this will be an > issue; > 3) testing/implementing the feature -- I think it should be possible > to test the feature locally before actually applying the changes on > the real buildbot master, but unless someone is going to apply them on > my behalf I would probably need access to the buildbot repo (is there > a public repo?); > 4) determine which branch the patch should be applied to -- this > could be done by adding a new "branch" field on the tracker; rietveld > could use it too; > 5) if the patch fails to apply there's no need to launch the build > on all the slaves -- a single slave (or maybe even the master?) could > check if the patch applies cleanly, and if it does trigger all the > other slaves. More fine-grained options could be added to the request > form too (e.g. run only on specific slaves/operating systems); > > If the idea is reasonable and I didn't miss anything I can try to find > some time to work on it. > > Best Regards, > Ezio Melotti Anything to make life easier for everybody. I'd offer to help myself, but having seen the name of a well known PITA on this thread I simply won't bother, it's just more trouble than it's worth. I'm fully aware that I'm no angel, but I can at least plead mitigating circumstances. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From techtonik at gmail.com Sat Jul 5 21:34:03 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 5 Jul 2014 22:34:03 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On Sat, Jul 5, 2014 at 9:30 PM, Mark Lawrence wrote: > On 05/07/2014 13:46, Ezio Melotti wrote: >> >> Hi, >> I recently had a chance to learn a bit more about buildbot, and it >> occurred to me than adding a new builder for testing tracker patches >> shouldn't be too difficult. >> >> This is how it should work: >> 1) a new "Test with buildbot" (or whatever) button is added to the >> tracker next to each patch, and developers/triagers can press it to >> trigger the build; >> 2) the buildbot builder receives the URL of the issue and of the >> patch and run all the usual steps with two differences: >> a) a new step to run "hg import --no-c url_of_the_patch" is added >> after the cloning step; >> b) an email with the results is sent back to the bug tracker once >> the slaves are done; >> >> Unless I'm missing something, both these changes should be trivial. >> On the tracker side is enough to add a form with a couple of (hidden) >> fields with the URLs and a submit button. On the buildbot side it >> should be enough to create a new builder (by copying one of the >> existing ones in the buildbot config file and adding the two steps >> mentioned above). Putting together a mail summary with the results of >> all the slaves might require a bit of extra code, but it shouldn't be >> anything too difficult. >> >> Some of the issues with this proposal are: >> 1) users uploading patches with malicious code -- this shouldn't be >> a problem if we only allow developers/triagers to trigger the build >> manually and tell them to review the code before doing so; >> 2) overloading of the slaves -- cloning/compiling/testing/cleaning >> takes quite a lot of time, and if this new feature starts to be used >> heavily it might start to give too much work for the slaves. I don't >> know what the current load is though, so I'm not sure this will be an >> issue; >> 3) testing/implementing the feature -- I think it should be possible >> to test the feature locally before actually applying the changes on >> the real buildbot master, but unless someone is going to apply them on >> my behalf I would probably need access to the buildbot repo (is there >> a public repo?); >> 4) determine which branch the patch should be applied to -- this >> could be done by adding a new "branch" field on the tracker; rietveld >> could use it too; >> 5) if the patch fails to apply there's no need to launch the build >> on all the slaves -- a single slave (or maybe even the master?) could >> check if the patch applies cleanly, and if it does trigger all the >> other slaves. More fine-grained options could be added to the request >> form too (e.g. run only on specific slaves/operating systems); >> >> If the idea is reasonable and I didn't miss anything I can try to find >> some time to work on it. >> >> Best Regards, >> Ezio Melotti > > > Anything to make life easier for everybody. > > I'd offer to help myself, but having seen the name of a well known PITA on > this thread I simply won't bother, it's just more trouble than it's worth. If you expect me to say "please, please, please, oh help Ezio", then of course, I won't say it. But if you send a pull request, I won't be the one who will decline it, because of emotional reasons. The problem is: 1. There is no place to send PR against 2. There is no workflow 3. There is no roadmap So if you can help Ezio close any of those problems while he is working on Roundup and server configs, in other words help him to make it easier for other people people to help him, that will be a good deal already and a good ontopic activity. I promise not to deliver any emotional distress in the process. > I'm fully aware that I'm no angel, but I can at least plead mitigating > circumstances. Nobody is an angel, but "He who fights monsters should see to it that he himself does not become a monster." -- anatoly t. From ezio.melotti at gmail.com Sat Jul 5 21:55:05 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 5 Jul 2014 22:55:05 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: <53B83097.8010407@email.de> Message-ID: On Sat, Jul 5, 2014 at 9:20 PM, anatoly techtonik wrote: > On Sat, Jul 5, 2014 at 8:43 PM, Ezio Melotti wrote: >> On Sat, Jul 5, 2014 at 8:06 PM, francis wrote: >>> On 07/05/2014 02:46 PM, Ezio Melotti wrote: >>>> >>>> 1) a new "Test with buildbot" (or whatever) button is added to the >>>> tracker next to each patch, and developers/triagers can press it to >>>> trigger the build; >>> >>> >>> Just an small detail/question: does it make a difference to change the >>> "trigger the build"-button with a "continuously check this patch" >>> -checkbox? The idea is not to check when the button is pressed >>> (if I've understood the original idea correctly) but just to set the >>> check and from then on get continuously feedback that's (still) working >>> (e.g. with a small green icon nearby the patch). >> >> The advantage of this is that people can know immediately if a patch >> still applies (assuming someone checked the checkbox before and that >> the check runs often enough). >> However this will waste lot of machine time if no one is looking at >> the patch for a long time, especially if we consider that there are >> over 2000 patches currently on the tracker. > > We already know which files patch touches: > https://bitbucket.org/techtonik/python-stdlib/src/567adbfaa3bf1de905949e38a27bee0334081174/modstats.py?at=default#cl-167 > so we can automatically detect a subset of patches to try on each > commit. We only need a DB with analyzed patch info to run queries. > > Independent pieces of code that need to be implemented as I see it: > > 1. [x] patch upload -> [ ] patch detection -> [ ] patch reaction -> > -> [x] patch analysis (get paths) -> [ ] store info (I'd use some key/value) > This is also something I'm working on, but even though I have some of those pieces already working, integrating everything on the bug tracker (or somewhere else) is not an easy task, so I haven't done it yet. > 2. [ ] post-commit hook to detect broken patches -> [ ] detect paths -> > -> [ ] run query to select patches -> [ ] schedule patch tests against > specific commits > > 3. [ ] get patch from the test queue -> [ ] checkout revision -> [ ] test > -> [ ] store result to DB > > 4. [ ] roundup GUI indicator -> [ ] query DB for patch status > >> On the technical side there are two issues: >> 1) it's easier to send the request whenever someone press the >> button, rather than having something that keeps track of all the >> patches that need to be checked and either keeps checking it or keeps >> sending requests to the buildbot master; >> 2) the green icon is a good idea, but also requires either a >> different way for the buildbot master to inform the tracker of the >> results, or some way to intercept the email send to the tracker and >> convert it to a green/red icon instead of adding a regular message. A >> third and simpler option is to just add the icon via JS on the >> client-side, and possibly also collapse buildbot messages so that they >> don't flood the message list. > > JS that accesses specific URL about patch status. > http://hostname/patches/file5555/status > { > status: "ok", # "check pending..", "broken by commit..", "applied.." > } > This can be done server-side if the status is hosted on the bug tracker. Exposing this info to the outside as JSON is a separate issue. > The task seems huge, so instead of making half-baked hack, I propose to > add some engineering - write down the roadmap above and concentrate on > that, then allow people to have fun adding meat to the bones. > Given the available time I have, I can either offer a half-baked hack or nothing. Once I put the first bone, people can add other bones/meat as they see fit. I don't think having a roadmap will make much difference though. Once you have it you still need to advertise it, reach the set of people with both skill, time, and interest, get them involved, find the time to review and apply the changes, etc.. I think we discussed this already somewhere else, and this thread is not the right place where to bring this up again (if you wish to continue the discussion we can do so off-list, but you should already know what's my opinion on the topic). > This will be a good practice to test more focused distributed workflow. > -- > anatoly t. From ezio.melotti at gmail.com Sat Jul 5 22:22:26 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 5 Jul 2014 23:22:26 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On Sat, Jul 5, 2014 at 10:34 PM, anatoly techtonik wrote: > On Sat, Jul 5, 2014 at 9:30 PM, Mark Lawrence wrote: >> >> Anything to make life easier for everybody. >> >> I'd offer to help myself, but having seen the name of a well known PITA on >> this thread I simply won't bother, it's just more trouble than it's worth. > You shouldn't let the presence of someone you define a PITA (which BTW is impolite and possibly against the CoC of this ML) affect your ability to help me or the Python community in general :) > If you expect me to say "please, please, please, oh help Ezio", then of > course, I won't say it. But if you send a pull request, I won't be the one who > will decline it, because of emotional reasons. The problem is: > > 1. There is no place to send PR against > 2. There is no workflow > 3. There is no roadmap > > So if you can help Ezio close any of those problems while he is working on > Roundup and server configs, in other words help him to make it easier for > other people people to help him, that will be a good deal already and a good > ontopic activity. I promise not to deliver any emotional distress in the > process. > FWIW this is the help I need: * from the current buildbot maintainers I would like: * access to the current buildbot configuration so I can see it, modify it, test it, and prepare a patch; * possibly access to the buildbot master so I can deploy it (I'm happy if they do it on my behalf though); * from people familiar with buildbot I would like feedback if they see any problem with my proposal and/or know any better/easier way to achieve the same goal; * from other developers I would like some general feedback in order to know if this feature will make their life any easier or if they think it's a waste of time that they will never need/use. I don't think I'll need help with the actual code/implementation, and if I do I can probably find it elsewhere (Google, IRC). >> I'm fully aware that I'm no angel, but I can at least plead mitigating >> circumstances. > > Nobody is an angel, but "He who fights monsters should see to it that he > himself does not become a monster." This sounds like a good reason to avoid fighting monster in the first place and just leave them alone :) > -- > anatoly t. From breamoreboy at yahoo.co.uk Sun Jul 6 13:03:29 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sun, 06 Jul 2014 12:03:29 +0100 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On 05/07/2014 21:22, Ezio Melotti wrote: > On Sat, Jul 5, 2014 at 10:34 PM, anatoly techtonik wrote: >> On Sat, Jul 5, 2014 at 9:30 PM, Mark Lawrence wrote: >>> >>> Anything to make life easier for everybody. >>> >>> I'd offer to help myself, but having seen the name of a well known PITA on >>> this thread I simply won't bother, it's just more trouble than it's worth. >> > > You shouldn't let the presence of someone you define a PITA (which BTW > is impolite and possibly against the CoC of this ML) affect your > ability to help me or the Python community in general :) > Tell that to Nick Gochlan. I'll quote in full from here https://mail.python.org/pipermail/core-workflow/2014-April/000059.html to save folks from looking it up "Anatoly, if you try to be part of this project, I will leave it. Your complete lack of empathy for the point of view of others is not acceptable in environments I am attempting to work in." -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From antoine at python.org Mon Jul 7 15:55:38 2014 From: antoine at python.org (Antoine Pitrou) Date: Mon, 07 Jul 2014 09:55:38 -0400 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: Hi, Le 05/07/2014 08:46, Ezio Melotti a ?crit : > I recently had a chance to learn a bit more about buildbot, and it > occurred to me than adding a new builder for testing tracker patches > shouldn't be too difficult. > > This is how it should work: > 1) a new "Test with buildbot" (or whatever) button is added to the > tracker next to each patch, and developers/triagers can press it to > trigger the build; > 2) the buildbot builder receives the URL of the issue and of the > patch and run all the usual steps with two differences: > a) a new step to run "hg import --no-c url_of_the_patch" is added > after the cloning step; > b) an email with the results is sent back to the bug tracker once > the slaves are done; I guess the question is: which problem is being solved? - have tests run faster - that's unlikely, unless we get a very fast builder - have tests run more reliably - unlikely as well, IMO - run tests on a different environment - that's useful; but that assumes we have a couple different builders which are fast, reliable and with a diversity of OSes Regards Antoine. From ezio.melotti at gmail.com Mon Jul 7 16:15:36 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 7 Jul 2014 17:15:36 +0300 Subject: [core-workflow] Use buildbot to test tracker patches In-Reply-To: References: Message-ID: On Mon, Jul 7, 2014 at 4:55 PM, Antoine Pitrou wrote: > > Hi, > > Le 05/07/2014 08:46, Ezio Melotti a ?crit : > >> I recently had a chance to learn a bit more about buildbot, and it >> occurred to me than adding a new builder for testing tracker patches >> shouldn't be too difficult. >> >> This is how it should work: >> 1) a new "Test with buildbot" (or whatever) button is added to the >> tracker next to each patch, and developers/triagers can press it to >> trigger the build; >> 2) the buildbot builder receives the URL of the issue and of the >> patch and run all the usual steps with two differences: >> a) a new step to run "hg import --no-c url_of_the_patch" is added >> after the cloning step; >> b) an email with the results is sent back to the bug tracker once >> the slaves are done; > > > I guess the question is: which problem is being solved? > > - have tests run faster - that's unlikely, unless we get a very fast builder > - have tests run more reliably - unlikely as well, IMO > - run tests on a different environment - that's useful; but that assumes we > have a couple different builders which are fast, reliable and with a > diversity of OSes > The main problem that is being solved is avoiding to manually download a patch, apply/test it, and report the results on the tracker. The ability to easily test a patch on different OSes is also very useful (lot of times I've seen windows buildbots failing after committing/pushing a patch tested on linux only). Checking if a patch (still) applies could also be done by the tracker itself without involving buildbot, but seeing if the tests (still) pass, and if they pass on different platforms requires buildbot. > Regards > > Antoine. > > > > _______________________________________________ > core-workflow mailing list > core-workflow at python.org > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct