Brett Cannon writes:
> > You need not feel that way. It's not you---the flexibility of dVCS
> > means that until the Powers That Be promulgate a Workflow, this will
> > be ambiguous.
>
> It also took me quite a while to finally grasp exactly how the typical
> workflow could go with a DVCS.
I don't think there is a "typical" workflow for DVCS yet. For
example, unreconstructed Archers generally do use a "record && request
pull" (from their local repos) workflow. On the other hand, XEmacs
treats its Mercurial repository as "CVS that can do merges sanely"---
patches are submitted to a mailing list for review, but I don't think
any of the core devs' patches ever get applied any more; rather they
go into the trunk quickly and devs and testers alike pull them from
there. The Bazaar guys have a crazy quilt of "Bundle Buggies" and
"Patch Queue Managers" semi-integrated into Launchpad. The Darcs
people have a surprisingly traditional "record && send patch" workflow.
My opinion is that Python's current workflow is pretty good, and
there's not reason to start anywhere but there.
As has been acerbically mentioned, like most mature projects with a
fairly close-knit group of core devs there are problems with casual
contributors' patches getting neglected. I think that a DVCS can
contribute fairly directly to more efficient reviewing, and it will be
easier to make workflow improvements needed for efficient reviewing
with a DVCS.
Hm ... those require ideas would require the contributor to use the
DVCS. That may be an argument for a Python-based VCS that could be
bundled with the sources, an hg-lite or bzr-lite. ("But git is still
faster!"<wink>)
> > The workflow where general contributors commit directly to the trunk
> > surely won't be used in Python, because of the instability it would
> > cause.
>
> I assume by "general contributor" you mean "anybody" and not "core
> developer".
That's right. The current workflow where the senior committers "fire
at will", except when the svn repo is frozen for a release, could be
simulated exactly with any of the DVCSes.
It might make sense to have an alternative workflow that restricts the
"next-to-be-released" repo to the release manager, but that is a
discussion for later, not something that should be implemented
immediately (if at all).
> This is why there is a Terminology section to the PEP; people have not
> fully agreed on terms yet.
I forgot to mention that although your terminology is somewhat
different from what I recommend, so far your definitions seem coherent
and your usage accurate. ("Seem" is not a reflection on you, but on
the inherent ambiguity in trying to adapt terms developed for CVS to
DVCSes.)
> As for how git.kernel.org works, I believe that won't work for Python
> without a cultural shift in how Python development happens. Linus has
> subsystem maintainers who are in charge of certain subsections of the
> Linux kernel.
In bringing up git.kernel.org, I'm not referring to the project
workflow, just to the ability to freely create branches and/or
subsidiary repos, and easily browse them on the host. At least for
core devs, and in the case of Launchpad, I believe anyone with a
Launchpad user can create repos.
OTOH, any workflow changes can and IMO should be discussed and
implemented gradually.
> We have http://code.python.org/ for this. And yes, you kind of just
> have to know since any random branches that might be out there will
> not be in the branches/ directory like in svn. But honestly how often
> does anyone just browse the branches/ directory anyway?
I don't know about svn; I find it pretty painful to use for anything
but sequential tasking (update ... hack ... commit ... repeat). But
if you look at http://git.kernel.org/, you'll see a thicket of repos,
each of which probably contains a few to a few hundred[1] branches
(mostly merged to repo mainline or abandoned, of course). I hear
kernel devs *do* browse those to find out what each other are up to,
as do lkml wannabes. I know that even locally, I often abandon tasks
on XEmacs where I've bitten off more than I want to chew at the
moment. When I do free up some time, browsing my stale branches is a
common way to find a project.
Again, this possibility is not an imperative to "be like Linux
kernel", but it is an opportunity to improve the technology for
communication among developers.
Footnotes:
[1] Seriously. git had to develop a packed format for its list of
branches and tags because people use so many of them it was impacting
performance!
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
