Why I don’t like git for team-maintained packaging...

For some time now I have been thinking about writing on using git for maintaining debian package in teams. I do not intent this as a way of trolling or flaming, but I would like to express my opinion on this topic.

First, I do not intent to criticize the technical aspects of git, which have been covered with enough details and comparisons. I prefer to stick on the collaborative aspect of git when working in teams.

Although git is a distributed source version manager, it does not mean that the whole developpement itself can be distributed. In fact, it distributes the collaborations, but puts the centralization in the hands of the developpement process. Mostly, it consists in some sort of project leader, which gathers the various contributions and merge them. That’s in particular how the linux kernel is developped, but with intermediate levels of synchronisation too (sub-system maintainers).

In the context of debian package mainenance, however, this has little interest. At least for me, when I put a package in a team, I still consider myself as the main responsible for the package, but I also accept contributions from members of the team. This is in particular helpful when dealing with large transitions.

Hence, there is no such team leader that handles all uploads and, as such, would merge contributions from various developpers and release a new package. There are leaders for each packages, and occasional contributors.

Linked to that remark comes the fact that git does not help making sure that all changes from occasional contributors are pulled before preparing an upload. Nothing in the workflow prevents you from commiting and even pushing you changes, but missing other changes.

Even worse, usual team practices for maintaining sets of packages are to prepare a different git repository for each package. That is very unfortunate since it discards completely the nice global view that svn centralized maintenance allowed. For instance, commiting the same change in all team-maintained packages, say a cdbs include, now needs the same number of checkout, commit, pull and etc..

This is also true for gathering informations about the global state of the packaging, for instance which packages have a stable branch, are in unstable and etc..

In conclusion, my feeling is that git is a great tool for big software projects, with several important contributors handled by some team-synchronisation.

In the case of debian packaging, however, the granularity is the debian package, which to me does not fit the purpose of distributed maintenance, since each unit (a package maintainer and occasional contributors) is too small to benefit from its advantages.

Clearly, this is should not be true for big packages, say KDE or GNOME, but that is not the general case.

And, yes, I still believe there was some sort of trend that pushed for this change probably too quickly.. :-)