Question about used Workflows.

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

On 03/15/2011 02:43 PM, Valentin Haenel wrote:

That's correct.

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.

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.

Valentin Haenel <valentin@fsfe.org> writes:

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.