Not to start a flame war --- but PLEASE! don't use git. I already have to use the other two leading DVCS's and all three are one too many. I personally prefer bazaar, but python itself and pywin32 are both committed to mercurial. I suspect that hg would be a better choice for most people. -- Vernon Cole
On Apr 19, 10:05 am, Dennis Kaarsemaker <den...@kaarsemaker.net> wrote: > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
