Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Henrique de Moraes Holschuh writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)"):
> Given that many of us work on the kernel, some of us are both upstream and
> downstream in git, and therefore know *both* sides of the troubles and
> advantages of git rebase quite well... I can see why you'd have a tough
> time convincing anyone to change his mind about it. We will have lived it
> ourselves and made up our minds about it a long time ago, already...
dpkg is not the Linux kernel.
Linux dpkg
Number of different people
regularly contributing hundreds or three or
significant changes thousands four
Size of source (.tar.gz) 59 Mby 6.3 Mby
Current gatekeepers Original author Developers who
and hand-picked happened along
lieutenants at the right time
Organisational relationship None / Members of original
between main contributors commercial project, under
competition unified governance
Linux has some very severe management problems to solve: its large
size, its position right at the centre, and so forth. To deal with
these problems, very heavyweight processes have evolved to ensure that
the load on the small number of central gatekeepers is absolutely
minimised. An underlying assumption is that in order to save a minute
of work for Linus, it is worthwhile to impose tens of minutes, or even
hours, of work on submitters.
The gatekeepers in Linux can only delegate with extreme care because
the code is too big for effective ongoing review, and because many
contributors' motives are often specifically aligned with a desire to
get a patch accepted - often with substantial financial implications.
If you try to apply the same processes to dpkg, or to even smaller and
less important projects, you're introducing a very cumbersome burden
for very little good effect.
It is very unfortunate for git that most of its advocates want to
adopt these almost unmanageable development practices along with the
revision control software.
Ian.
Reply to: