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
faster, but allows people that depend on stable releases to "scratch their
itch", backport the important bugfixes, and get them as part of a
"blessed" stable branch release.
On Tue, 19 Apr 2011 22:22:26 +0300, Jacob Kaplan-Moss <ja...@jacobian.org>
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
Django could move forward a bit faster [1], and we'd like to be able
to deliver more awesomeness in less time. Ultimately, the goal will be
to put out releases quicker, hit our deadlines more accurately, and be
able to respond to community suggestions and patches in a more timely
manner.
[1] This isn't unique to Django, of course; almost every open
source project wishes they could release more features more quickly.
One way that we'd like to improve our speed is by modifying our
existing backport policy. To refresh your memories, right now we
backport any non-feature-containing patches to the previous release.
So if we fix a bug on trunk, we backport the bug fix to the 1.3.X
branch, where it would become part of the 1.3.1 release. This is a
fair bit of work: it basically means we have to fix each bug twice.
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:
* Security issues.
* Data-loss bugs.
* Crashing bugs.
* Major functionality bugs in newly-introduced features.
In other words, we'd basically only backport bugs that would have
prevented a release in the first place.
Practically, this means that if there's a minor bug in 1.3 -- for
example, #15795, a bug with the representation of RegexURLPattern --
the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.*
release will contain the fix, even if it's fixed in trunk. To get the
fix for these bugs, users will have to upgrade to 1.4.
The upside, of course, is that bug fixes will be quicker to apply, so
we can fix more bugs, so we can get that 1.4 release out sooner [2].
Additionally, this'll give users more of an incentive to upgrade to
the latest-and-greatest. This means that they get new features, and we
(the development community) get to focus more clearly on moving
forward, not maintaining older releases.
[2] Look for a proposed release date soon. Spoiler alert: it's
sooner than you think.
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 likely you'll contribute? Less likely?
Thanks!
Jacob
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
