On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com> wrote: > On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote: >> >> If you have suggestions on how we can improve Django's development >> process and address these issues, we're happy to hear them. >> > > You may find this interesting: > > http://openbsd.org/papers/asiabsdcon2009-release_engineering/ > > (There's also a video of the presentation on YouTube.)
I've seen the video before; I didn't know the slide deck was available. Thanks for the link. My take on this is that we're reasonably close to OpenBSD's development process. The only significant difference is that we have the 'feature discussion' period where very little gets done on the tree, and major features are committed once that discussion period has lapsed. If you look at the 1.2 cycle, most of the major features were committed in December, just prior to the alpha release. If you dropped the 'feature discussion' period from the 1.2 timeline, you would end up with a development cycle that matches fairly closely to OpenBSD's. We have the feature development phase for a very good reason -- we have extremely limited resources (based on the charts in that slide deck, *much* lower than OpenBSD), and we want to focus those resources. If we continued to discuss new features while we were trying to get a release out the door, it becomes even harder to meet deadlines, because resources that would be dedicated to finding and fixing bugs (both core team resources and general community resources) are diverted into developing new code. > Tenets: > > - all development on trunk (no $ for QA team in free software) We already do this. > - daily snapshots (eat your own dogfood) In an era where you can pip install from a git/hg/svn repository, this isn't as important as it once was (or as important as it is for system software like OpenBSD). However, I agree that it would be good to automate this process somewhat (if only because we have a very low bus factor when it comes to release management). > - random api lock (people tend towards complacency) I'm not entirely certain I understand this point -- or, at least, how it would apply to Django. Our APIs are always locked, since we don't allow backwards incompatible API changes. Major new features don't get added to trunk until we're happy with their API, so new features aren't subject to API changes, either. > - punish dev's who don't fix their bugs quickly after api lock > > (The presentation lacks specifics on the last point. ;) Which is a big omission. When you're not paying anyone, and you already have a problem getting contributions, you have limited options for punishment. I'd be very interested to hear what constitutes "punishment" in this approach. > Also, hackathons are a great idea. A room full of core developers can > get a hell of a lot done in a week. You won't get any argument from me on this one. The complication is geography, and the resultant cost. I'm based in Western Australia, so it costs around $3000 to get me in a room with the other core developers somewhere in the US. That number is slightly less for Malcolm, because he's based on the east coast of Australia. Luke and Jannis both have to cross the Atlantic. And this completely avoids the question of how we find the time out of our work schedules to contribute a week of development effort. Any suggestions on how to overcome these limitations will be gratefully received:-) Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
