On Fri, 29 Jun 2012 02:23:12 +0200, Jesus Cea firstname.lastname@example.org 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.