On Tue, Apr 19, 2011 at 3:22 PM, 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 Hi All - In general I prefer to think about this the other way around: If we have a most current stable release of product X, it makes sense to fix any bugs that come up in that product. For the sake of the next release, assuming the bug was not fixed or made obsolete by some other change, it then also makes sense to /forward port/ that bug fix to the current (unstable) development trunk. Calling it "forward porting" rather than "back porting" makes it sound better, too. :-) This workflow fits quite well if you're using one of the DVCS mirrors of the Django repository, as it can be as easy as merging the latest release branch into default/master on a regular basis. There is obviously more to the story (running tests, dealing with the occasional merge conflict), but to me, it seems like the majority of the work is in fixing the original bug in the first place, not in applying that same fix to another branch of the code. If my assumption is true, we might as well apply the fix in both places once it has been made. Being a non-core-committer perhaps I don't fully understand the additional work involved, but I do appreciate the focus on stability in Django's releases and I'd rather be forced to upgrade due to new features that I want, rather than some silly bug that'll never be fixed -- especially if a stable release that includes the fix I need is not even available yet. In other words, if a bug in a product has been fixed, it seems odd to me that no stable release of the product will include that fix. What if the window for bug fixes was time boxed, so that bug fixes would be back/forward ported as usual up until 1-2 months prior to a new stable release (perhaps coinciding with the first release candidate)? This way at least we have some semblance of a stable release destined to include all bug fixes at all points in time, and the actual window in which a bug fix might not make it into the current official stable release is reduced. Just my 2 cents - hope that helps! Tobias -- Tobias McNulty, Managing Partner Caktus Consulting Group, LLC http://www.caktusgroup.com -- 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.
