On ma, 2010-04-19 at 15:47 +0000, Peter Landry wrote: > > > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote: > > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry <plan...@provplan.org> wrote: > >> 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? > > > > FTR, I think this is a fine idea, and I think most (all?) of the other > > Django core developers do, too. It's just waiting on someone to Just > > Do It. > > > > Anyone -- preferably a group -- who wants to start such a branch could > > go ahead and start one using the DVCS tool of their choice (Django has > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and > > I'll start watching it; show some continued motion and I'll spend some > > time getting a buildbot going against the branch; show high quality > > and I'll start pulling from it more and more frequently; show > > incredibly quality and I'll suggest that the maintainer(s) get commit. > > > >> 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. > > > > Quality is important, and if this branch is created it needs to > > maintain that quality. If this hypothetical branch is low-quality it's > > just a different tool for a queue of un-reviewed patches, and I've > > already got one of those. I'm not willing to compromise on quality: if > > patches don't meet our standards, they don't go in. > > > > Jacob > > I fully agree regarding quality, my point being that this branch itself may > not be "trunk ready" at any given time, but patches/pulls from it would be; > quality of patches would obviously need to meet existing standards. Perhaps > that distinction isn't helpful, necessary, or desirable.
I've been thinking of starting a proper contribution in django in a similar way: a github repo with per-ticket branches that are trunk-ready and regularly updated (rebased) against trunk until they are applied. So far I've only done so for a pony of mine as a test, but as soon as the ash cloud clears, I will look at existing tickets. Would this approach be useful for core committers to pull patches from? -- Dennis K. They've gone to plaid! -- 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.