On Mon, Apr 19, 2010 at 3:54 PM, Peter Landry <plan...@provplan.org> wrote: > On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote: > >> Hi folks -- >> >> I'd like to try to reboot the discussion that's been going on about >> Django's development process. >> >> I'm finding the current thread incredibly demoralizing: there's a >> bunch of frustration being expressed, and I hear that, but I'm having >> trouble finding any concrete suggestions. Instead, the thread has >> devolved into just going around in circles on the same small handful >> of issues. >> >> So: here's your chance. You have suggestions about Django's >> development process? Make them. I'm listening. >> >> Jacob > > One suggestion that jumped out at me (which I admittedly know very little > history about with regards to Django or other projects) was the "trunk > ready" branch(es) [1]. Perhaps an effort to outline what that process might > entail in detail, to determine if it would address any concerns? > > For my part, I see that it could be helpful to let some patches/ideas get a > shot at integration without having to endure the (necessarily) more rigorous > core commit trails. > > I'm not really comfortable suggesting any concrete plans for how that might > happen though. A single almost-trunk branch? A branch per > lieutenant/component? I'm wary of adding too much bureaucracy and overhead. > I think it's pretty clear that the core Django process is successful, and > this seems like a low impact (though potentially high effort?) way to > involve more of the community. > > Peter > > [1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b >
People only talk about a trunk-ready branch if they treat trunk as some sort of continually updated, always correct, release branch. IMHO trunk is where you commit features you want to be released, and you deal with fallout on trunk - you can always revert changes. An example of something that should have been committed to trunk already (immediately following release of django 1.1 imo) is custom FilterSpecs, #5833. This has been pushed from releases for 3 years, first from 1.0, then 1.1, now 1.2 - all for a feature that should be available in the admin. This is a ticket that displays a lot of the issues discussed in the other thread. The patch is feature complete, and community members have been updating it to recent versions of django for 3 years. It has comments of (seemingly) approval from core comitters, but lacks documentation and tests, and so sits, dead in the water, missing another release. A system that works on other projects is a mentorship system. I'm sure you have had lots of applicants to take part in GSoC - how about recruiting some of the rejected proposals and have them work through tickets like this, triaging and polishing to a committable state, at which point they coordinate with their mentor to have it committed. Obviously, they'd have to want to do this for free... One thing is true, the status quo doesn't seem to be resolving these forgotten tickets. Cheers Tom -- 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.
