The DVCS conversation has been had many times over the last year or two on
this list and in other places.  I mention this not to say that you should
know already as it isn't clearly documented, but as a suggestion that you
should make sure that you are bringing something new and concrete to the
discussion before starting it again.

The current view of the core team is that the combination of a central,
authoritative, Subversion server with semi-official mirrors for Git,
Mercurial, and Bazaar is sufficient for the foreseeable future.  All of the
benefits of the distributed systems are available via the mirrors and
there's no disruption to users who are used to the current
workflow/infrastructure.

If you would like to make a contribution to Django, you can work with
whichever of the three most common DVCSs and there will be several core devs
able to accept your changes without any problems.

____________________________
Sean O'Connor
http://seanoc.com

P.S.  I am not a core dev so any of the core devs should feel free to
correct me on this. That being said this view has been clearly expressed
several times on this list and in other venues.


On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected]>
> > wrote:
> >> On ma, 2010-04-19 at 15:47 +0000, Peter Landry wrote:
> >>
> >>
> >>
> >>
> >>
> >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" <[email protected]> wrote:
> >>
> >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry <[email protected]>
> 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 [email protected]
> .
> >> To unsubscribe from this group, send email to
> [email protected]<django-developers%[email protected]>
> .
> >> 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 [email protected].
> > To unsubscribe from this group, send email to
> [email protected]<django-developers%[email protected]>
> .
> > 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected]<django-developers%[email protected]>
> .
> 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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to