-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Python 3.3 is currently in beta, so the rythm of new patches in "default" will decrease and people with new features MUST wait until 3.3 is out. I think this is a waste of time. And even if people is working with HG private clones, they can't test using the buildbots neither mark a bug as fixed in the tracker.
If we create a new 3.3 branch *NOW* and add it to the buildbots, people can keep working in "default" full speed (for 3.4), while 3.3 branch is getting ready for general release. We only need to remember to appy the same rule current rule: any patch in branch "x" must be "merged" into branch "x+1" too.
Has this step been considered?. I think it is a nice improvement that HG enables and we are not using.
What do you think?.
PS: In the past some people said that this "feature freeze" forces devs to concentrate in getting the release ready. This is a good point, but it should be a social issue to solve, not a technical one. I, for one, would personally invest more time in fixing upcoming 3.3 (soon to be released) than hacking future 3.4 (two years away!). No need to "press me" with an ¿obsolete? technical limitation.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBT+z1cJlgi5GaxT1NAQLt0AP8DsFzMms7Z5JhomDZaTZkZB2X5Dh7SBkK 0XwM5oKASIa2k9OEX8CbKJI6u6dCUT3VGS3qbXNcv1baoK8ldykt2Ats9XHXL3gD 9ZX4Ofcm6Qw738s9OgvsQnDFYcx9FtB8wew5b6qnAsRtDWEo5iv88ZzZEtNMNbxW Rcv9exP38JY= =N8z9 -----END PGP SIGNATURE-----
On Fri, 29 Jun 2012 02:23:12 +0200, Jesus Cea <jcea@jcea.es> wrote:
Python 3.3 is currently in beta, so the rythm of new patches in "default" will decrease and people with new features MUST wait until 3.3 is out. I think this is a waste of time. And even if people is working with HG private clones, they can't test using the buildbots neither mark a bug as fixed in the tracker.
If we create a new 3.3 branch *NOW* and add it to the buildbots, people can keep working in "default" full speed (for 3.4), while 3.3 branch is getting ready for general release. We only need to remember to appy the same rule current rule: any patch in branch "x" must be "merged" into branch "x+1" too.
Has this step been considered?. I think it is a nice improvement that HG enables and we are not using.
Yes, it has been considered. It was rejected by the RM.
What do you think?.
PS: In the past some people said that this "feature freeze" forces devs to concentrate in getting the release ready. This is a good point, but it should be a social issue to solve, not a technical one. I, for one, would personally invest more time in fixing upcoming 3.3 (soon to be released) than hacking future 3.4 (two years away!). No need to "press me" with an ¿obsolete? technical limitation.
For exactly this reason. We want to focus on fixing bugs for 3.3. Having to commit to yet another branch at this time would be a distraction, as would having to pay attention to feature patches going in to default. If the active committers are working on bug fixes, then no features would be getting committed anyway, and the extra merge would just be pointlessly annoying.
Opinions on this can differ, of course.
There is still nothing stopping people from posting new features to the tracker, so there is no reason that non-committer workflow needs to change, they just may need to wait a bit longer for feedback...which they'd have to do regardless of whether we branch now or not.
Georg has indicated he will branch 3.3 at rc1, which I personally think is sensible.
--David
On Fri, Jun 29, 2012 at 12:13 PM, R. David Murray <rdmurray@bitdance.com> wrote:
There is still nothing stopping people from posting new features to the tracker, so there is no reason that non-committer workflow needs to change, they just may need to wait a bit longer for feedback...which they'd have to do regardless of whether we branch now or not.
Also see my previous email regarding the early flagging of high priority or release blocker issues for 3.4, or assigning items to ourselves for later review - we have a triage tool to keep track of changes before they hit the main repo, we may as well make use of it.
Georg has indicated he will branch 3.3 at rc1, which I personally think is sensible.
As do I - it's a not-so-subtle hint as to what our priorities should be between now and rc1 :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
For exactly this reason. We want to focus on fixing bugs for 3.3. Having to commit to yet another branch at this time would be a distraction, as would having to pay attention to feature patches going in to default. If the active committers are working on bug fixes, then no features would be getting committed anyway, and the extra merge would just be pointlessly annoying.
+1 on that one, I’m really glad the current polishing is more or less frictionless. Merging across branches is especially annoying when the commit rates are fairly high like now.
2012/6/28 Jesus Cea <jcea@jcea.es>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Python 3.3 is currently in beta, so the rythm of new patches in "default" will decrease and people with new features MUST wait until 3.3 is out. I think this is a waste of time. And even if people is working with HG private clones, they can't test using the buildbots neither mark a bug as fixed in the tracker.
If we create a new 3.3 branch *NOW* and add it to the buildbots, people can keep working in "default" full speed (for 3.4), while 3.3 branch is getting ready for general release. We only need to remember to appy the same rule current rule: any patch in branch "x" must be "merged" into branch "x+1" too.
Has this step been considered?. I think it is a nice improvement that HG enables and we are not using.
What do you think?.
I, for one, had my fill of maintaining 4 branches when we were doing two versions of 2.x and two versions of 3.x.
People are free to put their features in their own private clones and await 3.4 development beginning.
-- Regards, Benjamin
On 06/29/2012 02:23 AM, Jesus Cea wrote:
3.3 is out. I think this is a waste of time. And even if people is working with HG private clones, they can't test using the buildbots neither mark a bug as fixed in the tracker.
This is also a nice improvement that Mercurial enables, you can commit your code into a private or even public branch and just merge it into default when both your code and default are ready for it.
Regards
Ross Lagerwall
On 29.06.2012 02:23, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Python 3.3 is currently in beta, so the rythm of new patches in "default" will decrease and people with new features MUST wait until 3.3 is out. I think this is a waste of time. And even if people is working with HG private clones, they can't test using the buildbots neither mark a bug as fixed in the tracker.
If we create a new 3.3 branch *NOW* and add it to the buildbots, people can keep working in "default" full speed (for 3.4), while 3.3 branch is getting ready for general release. We only need to remember to appy the same rule current rule: any patch in branch "x" must be "merged" into branch "x+1" too.
Has this step been considered?. I think it is a nice improvement that HG enables and we are not using.
What do you think?.
PS: In the past some people said that this "feature freeze" forces devs to concentrate in getting the release ready. This is a good point, but it should be a social issue to solve, not a technical one. I, for one, would personally invest more time in fixing upcoming 3.3 (soon to be released) than hacking future 3.4 (two years away!). No need to "press me" with an ¿obsolete? technical limitation.
Others have already explained my motive for keeping the "technical limitation": it is really about workload for developers.
And as Ross says: you *can* use the buildbots for personal branches. And if you put the right "Closes #12345" in your commit messages you don't even have to care to remember to close issues after they are merged into mainline.
Georg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/06/12 10:07, Georg Brandl wrote:
And as Ross says: you *can* use the buildbots for personal branches.
I missed that. How is it done?.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBT+2dm5lgi5GaxT1NAQIweAP/fm3lUsr/3T2or6+7mHpzAR5P5+6nGd3g UO2dZWTYjT4FxqMRiZotuO0RgQ6KKUshi2q1KE+0uPgWBUGCpDVBdPl9pmjO8GXK q63vIKzXtrE38UKtMxc9Lu+Ub1oj6C5i6g885WhAdUU9Txm0xfyc4DH0vXNiM1Dn D/CEm13XaeA= =d/GU -----END PGP SIGNATURE-----
On Fri, Jun 29, 2012 at 2:20 PM, Jesus Cea <jcea@jcea.es> wrote:
On 29/06/12 10:07, Georg Brandl wrote:
And as Ross says: you *can* use the buildbots for personal branches.
I missed that. How is it done?.
Go to one of the "custom" builders at http://buildbot.python.org/all/waterfall, for example http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom. Then fill out the "Force build" form with the details of your sandbox repository on hg.python.org.
Unfortunately, it looks like most of the custom builders are currently offline, but I assume that's a transient issue related to the recent change in the location of the buildbot master.
Cheers, Nadeem
Le vendredi 29 juin 2012 à 14:27 +0200, Nadeem Vawda a écrit :
On Fri, Jun 29, 2012 at 2:20 PM, Jesus Cea <jcea@jcea.es> wrote:
On 29/06/12 10:07, Georg Brandl wrote:
And as Ross says: you *can* use the buildbots for personal branches.
I missed that. How is it done?.
Go to one of the "custom" builders at http://buildbot.python.org/all/waterfall, for example http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom. Then fill out the "Force build" form with the details of your sandbox repository on hg.python.org.
Unfortunately, it looks like most of the custom builders are currently offline, but I assume that's a transient issue related to the recent change in the location of the buildbot master.
Uh? Most of them are online: http://buildbot.python.org/all/waterfall?category=custom.stable&category=custom.unstable
Those which are offline are because the buildslaves themselves are offline.
Regards
Antoine.
On Fri, Jun 29, 2012 at 2:34 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Uh? Most of them are online: http://buildbot.python.org/all/waterfall?category=custom.stable&category=custom.unstable
Those which are offline are because the buildslaves themselves are offline.
Oops, my mistake. I should have read more carefully...
participants (9)
-
Antoine Pitrou -
Benjamin Peterson -
Georg Brandl -
Hynek Schlawack -
Jesus Cea -
Nadeem Vawda -
Nick Coghlan -
R. David Murray -
Ross Lagerwall