Re: RFC: new backports policy

2011-04-20 Thread Jacob Kaplan-Moss
On Wed, Apr 20, 2011 at 5:24 PM, Luke Plant wrote: > Hmm, Jacob didn't specifically mention regressions, though in our > discussions on django-core we did include them. Yup, sorry - was moving too fast. Regressions, clearly, get backported -- if something worked in 1.2, it

Re: RFC: new backports policy

2011-04-20 Thread Luke Plant
On 20/04/11 22:37, Tobias McNulty wrote: > Okay, I do think the regression issue makes a much stronger argument > than the developer time issue. > > I'd be more comfortable if the policy stated that any new bugs > introduced by the last release would be backported to that release. > It's

Re: RFC: new backports policy

2011-04-20 Thread Carl Meyer
On 04/20/2011 04:37 PM, Tobias McNulty wrote: > I'd be more comfortable if the policy stated that any new bugs > introduced by the last release would be backported to that release. > It's possible that "major functionality bugs in newly-introduced > features" will equate to virtually the same

Re: RFC: new backports policy

2011-04-20 Thread Tobias McNulty
On Wed, Apr 20, 2011 at 3:56 PM, Paul McMillan wrote: > +1, I agree with Carl and Luke. The issue here is that for > non-showstopper bugs, users have probably found (or may even be > relying on!) the existing behavior. Keeping the "stable" branch more > stable by only changing

Re: RFC: new backports policy

2011-04-20 Thread Jeremy Dunck
On Wed, Apr 20, 2011 at 3:32 PM, Markus Gattol wrote: > That's certainly a move in the right direction so +1 from me too. The > problem of > backporting correlates with how much time passes between any release > i.e. long time between releases gives bigger pita with

Re: RFC: new backports policy

2011-04-20 Thread Markus Gattol
That's certainly a move in the right direction so +1 from me too. The problem of backporting correlates with how much time passes between any release i.e. long time between releases gives bigger pita with backporting. Even more so because you have several version control systems etc. etc. (not

Re: RFC: new backports policy

2011-04-20 Thread Markus Gattol
That's certainly a move in the right direction so +1 from me too. The problem of backporting correlates with how much time passes between any release i.e. long time between releases gives bigger pita with backporting. Even more so because you have several version control systems etc. etc. (not

Re: RFC: new backports policy

2011-04-20 Thread Markus Gattol
That's certainly a move in the right direction so +1 from me too. The problem of backporting correlates with how much time passes between any release i.e. long time between releases gives bigger pita with backporting. Even more so because you have several version control systems etc. etc. (not

Re: RFC: new backports policy

2011-04-20 Thread Paul McMillan
+1, I agree with Carl and Luke. The issue here is that for non-showstopper bugs, users have probably found (or may even be relying on!) the existing behavior. Keeping the "stable" branch more stable by only changing things when there's a serious issue seems to be a positive improvement. I think

Re: RFC: new backports policy

2011-04-19 Thread Carl Meyer
On 04/19/2011 05:24 PM, Luke Plant wrote: > Another issue with regards to backporting bug fixes that Jacob didn't > mention is the fact that bug fixes often introduce subtle regressions > and backwards incompatibilities. > > Personally, I find that backporting a fix very often takes only a >

Re: RFC: new backports policy

2011-04-19 Thread Luke Plant
Another issue with regards to backporting bug fixes that Jacob didn't mention is the fact that bug fixes often introduce subtle regressions and backwards incompatibilities. Personally, I find that backporting a fix very often takes only a minute, by appropriate use of DVCS features (e.g. hg

Re: RFC: new backports policy

2011-04-19 Thread Ivan Sagalaev
On 04/19/2011 02:35 PM, Daniel Moisset wrote: I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider

Re: RFC: new backports policy

2011-04-19 Thread Daniel Moisset
On Tue, Apr 19, 2011 at 4:22 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > > The core team has come to a rough consensus and we're planning to drop > this backport-everything policy. Instead, we'll only backport critical > patches. That is, we'd only backport patches for: > >

Re: RFC: new backports policy

2011-04-19 Thread Yishai Beeri
Perhaps augment the new policy by stating that contributed backports for bugs that are left out by this change will be favorably looked upon, and committed to the branch unless there is a good reason no to commit them. This still achieves the goal of making the routine bugfix commit cycle

Re: RFC: new backports policy

2011-04-19 Thread Aymeric Augustin
On 19 avr. 2011, at 21:22, Jacob Kaplan-Moss wrote: > We'd like to make this change effective immediately, but we also don't > want to just issue this change by fiat. So we're requesting comments > and feedback on this change. Do you like the idea? Why or why not? > Will this policy make it more

Re: RFC: new backports policy

2011-04-19 Thread Tobias McNulty
On Tue, Apr 19, 2011 at 3:22 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > Over the past few weeks, the core development team have been > discussing how we can streamline our process to get more work done > quicker. It's pretty clear that the bulk of the community wishes >

RFC: new backports policy

2011-04-19 Thread Jacob Kaplan-Moss
Hi folks -- Over the past few weeks, the core development team have been discussing how we can streamline our process to get more work done quicker. It's pretty clear that the bulk of the community wishes Django could move forward a bit faster [1], and we'd like to be able to deliver more