rethinking patch management with GIT / topgit

[Russ Allbery]

Manoj Srivastava <srivasta at ieee.org> writes:
> On Sat, Mar 27 2010, Enrico Weigelt wrote:

>> That is _NOT_ distro's business. If you want such things, do a clean
>> fork - w/ all implications. This creates a new/different package, out
>> of the original package's versioning line. (eg. ff vs. iceweasel).

>         I am glad you have an opinion. I do not share it. I have some
>  experience packaging software for a fairly mainstream distribution, and
>  I have long since come to the conclusion that the black and white line
>  you draw is suboptimal for my users.

This isn't just Manoj.  I can't think of a single significant software
package that I've packaged for Debian where I've not needed to carry local
modifications for at least some significant length of time.

The next major release of OpenAFS may no longer need any Debian-specific
patches.  It's only taken 5 years to get everything reimplemented in a
sufficiently general way that upstream can take it, and that's with me
also being one of the upstream core maintainers.  I've carried patches in
Debian for some time even for packages for which I'm the sole upstream
maintainer.

>         In response to your question in a related email, in my opinion,
>  this never-carry-patches-and-fork policy does not work for me. I think
>  rewriting history that other people see is a bad idea.

By and large, my upstreams don't want me to fork and would likely to be
fairly upset that I did just because I'm carrying some fixes and changes
that aren't sufficiently general to go upstream (at least yet).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>