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
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
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
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
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
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
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
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
+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
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
>
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
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
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:
>
>
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
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
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
>
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
17 matches
Mail list logo