If you contribute to open source projects, at one point you'll be faced with the forced choice to use git. It is extremely popular (I believe it's the most popular after svn), and unlike svn it's popular for a good reason. However, hg is decent as well; whatever the django team chooses, as long as it's not cvs it can't really be worse than svn.
(bzr fan, personally, but I'd prefer it if django moved over to git) J. Leclanche / Adys On Tue, Apr 20, 2010 at 2:58 AM, VernonCole <vernondc...@gmail.com> wrote: > 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. > > -- 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.
