Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Theodore Tso <tytso@MIT.EDU>]

On Fri, Feb 29, 2008 at 12:40:55PM +0000, Colin Watson wrote:
> > That's why you should avoid using the branch as basis to others until
> > it's clean and also avoid to make it public (without a reason) too.
> 
> This makes it more difficult to ask for review while the branch is in
> progress, which is a valuable property. It is ridiculous to artificially
> avoid making branches public; a branch is a useful means of
> collaboration and we should take advantage of it as such.

It's a bad idea to base work on a feature where the code is still
being under review.  Even if you keep all of the historical crap on
the branch, to be preserved for ever, it's going to cause merge
difficulties for people who base branches based on that patch which is
under review.  So you really, REALLY, don't want people basing work on
code which is still being developed, since it may be that the review
may include, "why don't you totally refactoring the code *THIS* way",
which will end up breaking everyone who depends on your new function
interface anyway.

So how to solve this problem?

(a) Send patches via e-mail for review.  This actually works better,
because people can respond via e-mail much more easily than if it just
shows up in a git repository.  You can also send an explicit request
for people to review the patch when it is sent via e-mail.

(b) Put the patches on a git branch which is *guaranteed* to be
constantly rewound, and is not to be used as a base for derived
patches.  By convention the 'pu' branch in the git (and e2fsprogs)
source repository is declared to be one which is used only for people
who want to test the latest bleeding edge code, but it should not be
used as the basis of any derived or child branches.

> I have never once run into this problem with other revision control
> systems in which branching and merging are common. Somehow it just never
> seems to be a real issue. I contend that dpkg is not big enough for it
> to become a real issue.

It's not a fatal issue, but in the long run, the code is more
maintainable if the code revision history is clean.  It's like having
a few goto's in the code.  Does that make the code unmaintainable?
No.  But it does make it worse.  Or think about how much effort some
of us spend to make the code gcc -Wall free of warnings.  Does not
doing it make the code fundamentally bad?  No.  Is it still worth
doing?  Many of us believe that it is worth doing, nevertheless.

	     	   	   	      	    - Ted