> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > > Sorry to hear that. The document you linked is a start, but I'm a bit > > concerned by this goal: > > "to keep the main integration branch as stable as the official trunk > > so that it can be used in actual deployments" > > > My concern here would be that people become dependent on your > > selections for prod, and some of these changes never get merged to > > mainline, so that there's functionally a fork in terms of support and > > community.
I would really, really want to avoid that. The merge branch would let people test things out properly, perhaps even in production, and run a buildbot off it. But the goal of the effort as a whole is just getting high-quality reviewed, tested and integrated patches back to Django trac. The wording is just a sketch, seems I have to re-iterate that no forking in the "bad" sense of the word will occur. The work is meant for merging back and the main value lies in ticket branches, not in the merge branch. What I envision is the following: * there's a specific goal and deadline (i.e. fix 10 bugs in 2 weeks), * sprinters claim tickets in trac, * sprinters create ticket branches in their corresponding forks of the Django SVN mirror and work off their branches, * when the work is ready, it will be reviewed and merged into the mq by sprint lieutenants, * buildbots run tests off the mq, * if all is well, the sprinter uploads the final patch to the corresponding ticket, * when the deadline is reached, the tickets that were properly fixed during the spring are presented to core and will be eventually merged to SVN trunk simply via the patches in trac. As far as I can understand, core has been opposed to taking more work upon themselves, so the last step should be effortless, i.e. core can assume that the patch is well reviewed, tested and non-controversial. This workflow is suitable for janitor-type work, not for epic or controversial changes. On Dec 8, 7:40 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: > Because of this work to review tickets, provide feedback, and get them > into an RFC state is far more important IMO. Exactly. However, there needs to be a coordinated effort and a deadline to rally the masses :). The Django community is vast and certainly full of excellent people who are more than able to fix a couple of the 1700 open tickets. However, people who provide patches are few and the patches are mostly proof-of-concept quality. I myself am used to providing somewhat proof-of-concept quality patches. Analyzing the reasons, I noticed that I semi-consciously am thinking that the trunk changes too much to make polishing feasible and that a core reviewer "knows better" and will rewrite it anyway. This attitude doesn't work within the merge queue workflow, where most of the work is quickly integrated and thus the contributor needs to pay more attention to polish. So, there's a psychological benefit of the mq besides the real one. Over and out for today, best, MS -- 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.
