[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: