Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.05.15 um 09:59 schrieb Larry Hastings: When you say branch testing, you mean running the buildbots against it? Right now the UI for doing that is pretty clunky. Kicking off a build against a server-side clone (iirc) requires clicking through a couple web pages, filling out a form, and clicking on a teeny-tiny button. It would help *tremendously* here if I could get this automated, so I could run a script locally that made everything happen. Is there a remote API for starting builds? Or existing automation of any kind? Who should I talk to about this stuff? Antoine, or me. For branch builds, it would be better to configure them into the buildbot configuration, instead of trying to force them from the outside. To make this happen, you need to add a repository URL and branch name into the buildbot configuration, and a post-push hook on the repository to trigger the build. It's actually possible to configure a bitbucket POST hook to trigger a buildbot build, but we haven't yet integrated that into the buildbot master. Regards, Martin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVfivYACgkQavBT8H2dyNIzCACdG3yHShN/ZEc1sIiOVYj0lcg0 K9IAnjqLCFN+EewBPLfh651wQUq64nun =0j5m -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 8:04 PM, Larry Hastings la...@hastings.org wrote: What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 --Berker ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 05:19 PM, Nick Coghlan wrote: Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org http://hg.python.org for branch testing. I sort of assumed the buildbots would start building the 3.5 branch once it was created, yes. (Are there any branches in the cpython repo that they ignore?) When you say branch testing, you mean running the buildbots against it? Right now the UI for doing that is pretty clunky. Kicking off a build against a server-side clone (iirc) requires clicking through a couple web pages, filling out a form, and clicking on a teeny-tiny button. It would help *tremendously* here if I could get this automated, so I could run a script locally that made everything happen. Is there a remote API for starting builds? Or existing automation of any kind? Who should I talk to about this stuff? (Possible alternative plan for the latter: rc1 isn't until August, and I could aim to have a pilot Kallithea instance set up by then that uses bugs.python.org http://bugs.python.org credentials to log in. If we didn't get that up and running for some reason, BitBucket could still be a fallback plan) I'm happy to consider it. My proposed workflow is only using a very small set of features, and I gather Kallithea already has those features. Bolting on authentication from bugs.python.org would make it *less* friction than using Bitbucket. But I couldn't say for sure until I got to try it. So get cracking, Nick! //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org wrote: [SNIP] What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:04, Larry Hastings la...@hastings.org wrote: Workflow 1 == When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo on bitbucket for 3.5.0, and we use bitbucket pull requests for cherry-picks from 3.5.1 into 3.5.0. This gives us a pilot project to try out a web GUI for merging. It makes my workflow easier, as I can push a button to accept cherry-picks. (If they don't apply cleanly I can tell the author to go fix the conflict and resubmit it.) The downside: it requires core devs to have and use bitbucket accounts. One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Workflow 2 == When I ship beta 1, trunk remains 3.5. When I ship rc 1, we create the 3.5 branch. The 3.5 branch is 3.5.0 and trunk is 3.5.1. Only blessed stuff gets cherry-picked from 3.5.1 back into 3.5.0. Where does 3.6.x fit into Workflow 2? -- Ned Deily n...@acm.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org server-side clone and kick off the buildbots from there. Where does 3.6.x fit into Workflow 2? It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38, Larry Hastings la...@hastings.org wrote: On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org server-side clone and kick off the buildbots from there. I wasn't worrying about the 3.5.0rc branch, but, yeah, we could probably improvise ones for that as you suggest. So, buildbots would be: 3.5 branch (-3.5.1 as of beta1), 3.5rc (as needed from rc1 to final), along with the current 3.x (-3.5.0 today, - 3.6.0, as of beta1), 3.4, and 2.7 buildbots. I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. In other words, while nice, the use of Bitbucket is not a critical feature of Workflow 1. I think 1 is the best choice with or without the use of Bitbucket. But we should also recognize that adopting it can make more work for committers fixing bugs over the next few months (between beta1 and final), as we need to consider testing and pushing each fix to default (for 3.6.0), 3.5 (for 3.5.0 until rc1, then for 3.5.1), 3.4 (for 3.4.4), and/or 2.7 (for 2.7.11). That's the tradeoff for allowing feature work to be committed, integrated, and tested during the beta and rc periods. Where does 3.6.x fit into Workflow 2? It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. Workflow 0 = -1 Workflow 1 = +1 Workflow 2 = -0.5 -- Ned Deily n...@acm.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38 AM, Larry Hastings wrote: It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings on what will be 3.6, then going with workflow 1 will be an interesting social experiment. I'm fine with any of them as long as the workflow is *well documented*, preferably in the devguide. Cheers, -Barry pgpr_x4ASMLvd.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 11:18 AM, Jesus Cea wrote: Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this? Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6). It doesn't get us testing of the 3.5.0 release candidates automatically, because those would be hosted at bitbucket. However: hg.python.org allows creating server-side clones which can manually run tests against the buildbots. So if I create a server-side clone, then push the release candidate branch there, I can kick off buildbot tests. Who knows, maybe I'd even automate that process. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings la...@hastings.org wrote: BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Probably. It's water under the bridge now--that all happened last February and I'm not doing it that way again. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 13 May 2015 03:47, Brett Cannon br...@python.org wrote: On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org wrote: [SNIP] What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org for branch testing. (Possible alternative plan for the latter: rc1 isn't until August, and I could aim to have a pilot Kallithea instance set up by then that uses bugs.python.org credentials to log in. If we didn't get that up and running for some reason, BitBucket could still be a fallback plan) Cheers, Nick. ___ python-committers mailing list python-committ...@python.org https://mail.python.org/mailman/listinfo/python-committers ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 11:21 AM, Ned Deily wrote: I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. For 3.4, I had an amazing number of cherry-picked revisions. By the end it was... 72? over 100? I'm no longer even sure. Granted, 3.4 had the new module asyncio, and I got a deluge of cherry-pick requests just for that one module. I permitted 'em because a) they wanted it to be ready for prime time when 3.4 shipped, b) there was no installed base, and c) a healthy percentage of those changes were doc-only. (But if Victor tries that again during the 3.5 betas, he may have another thing coming!) BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious: https://hg.python.org/release/file/b7529318e7cc/3.4/threefourtool.py I have since given up this foolish desire. I'll be happy to have a nice grubby revision DAG if it means I can spend more time on the internet cruising for funny cat videos. In short, as release manager, I'm pretty stoked by the idea of pressing a big shiny button on a website exactly once when I accept a cherry-pick request. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
