Question about used Workflows.

Question about used Workflows.

[Valentin Haenel]

Dear Git developers and contributors,

I was wondering what kind of workflow the Git project itself uses. From
what I gather much of the development takes place using the list, and
patches sent by mail. Do any of the core contributers maintain public
developer repos? And how many developers on average have push privileges
to http://git.kernel.org/?p=git/git.git;a=summary?

thanks

Valentin

Re: Question about used Workflows.

[Andreas Ericsson]

On 03/15/2011 02:43 PM, Valentin Haenel wrote:
> Dear Git developers and contributors,
> 
> I was wondering what kind of workflow the Git project itself uses. From
> what I gather much of the development takes place using the list, and
> patches sent by mail.

That's correct.

> Do any of the core contributers maintain public
> developer repos?

Some do, although most contributions are still sent as patches for
public discussion and then taken from there by Junio who has some
nifty routine for that already.

Subpart maintainers, such as the gitk author Paul Mackerras (spelling?)
have repos of their own from which Junio pulls on request. Normally
that's in parts where Junio feels his knowledge lacking and he trusts
the subpart maintainer. From what I've gathered, Tcl isn't Junio's
strong point.

> And how many developers on average have push privileges
> to http://git.kernel.org/?p=git/git.git;a=summary?
> 

There's no "average" to it. Linus probably still has push access as
he's the founding father and first maintainer. Junio ofcourse has it
as the current maintainer. Shawn Pearce has taken over maintenance
a few times when Junio has been absent for one reason or another. I
doubt push privileges have been revoked in between absences. Oh, and
ofcourse the kernel.org admin team have more or less implicit access
to push, although the git community would certainly frown quite hard
if they ever (ab)used their admin powers to do that.

All that aside; By peer etiquette and for simplicity reasons, only
the current maintainer ever pushes anything to kernel.org. Noone
becomes maintainer (or kernel.org admin) without having invested a
lot of time and shown a lot of devotion to the project.

For some public credit, Junio's doing a great job both maintaining
and choosing interim maintainers. I've rarely seen an opensource
project where the maintainer so rarely (ever?) get annoyed at
anything and keeps everything running smoothly.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Question about used Workflows.

[Junio C Hamano]

Valentin Haenel <valentin@fsfe.org> writes:

> I was wondering what kind of workflow the Git project itself uses. From
> what I gather much of the development takes place using the list, and
> patches sent by mail. Do any of the core contributers maintain public
> developer repos? And how many developers on average have push privileges
> to http://git.kernel.org/?p=git/git.git;a=summary?

Only I push into that repository, but first of all, everybody should stop
thinking "push" as a privilege.  That repository is like "my" home, and
the statement "I have a privilege to enter my home" does not have much
meaning.  It may be technically correct, but other people have the same
privilege to enter their homes (i.e. have their own public repositories
that only they can push into, and others can pull their work from there),
so it is not noteworthy.

Changes are reviewed on the list in patch form, and most of the time I've
been applying these changes to my tree and pushing the results out to my
public repository, but from time to time, other people do give me a pull
request, and I pull from them to integrate their work. The result again is
published by pushing it out to my public repository.

In a distributed world, the "primary" repository exists only by social
convention. My repository happens to be the primary one for now, but if
somebody wants to fork git and starts making a lot of good changes at a
rapid pace that neither I nor the current list reviewers can keep up with,
the repository of that person may become a more popular source of the
cutting-edge version of git, and if that continues, it may become the
"primary" one, at which point the list (including me) may decide that it
is a good idea to turn the maintainership to that new person.

When I had to leave the net for extended period of time (which happened a
few times in the past), I don't give the key to my home ("push privilege")
to an interim maintainer. Instead, the interim maintainer keeps his own
public repository ("his home"), and pushes to that repository by playing
exactly the same role as I do, picking up well-reviewed patches from the
mailing list and responding to pull requests. In the meantime, people work
off of his repository. When I come back, I can pull from the interim
maintainer and the continuity of the end-result history is maintained.