rethinking patch management with GIT / topgit

[Russ Allbery]

Enrico Weigelt <weigelt at metux.de> writes:
> * Russ Allbery <rra at stanford.edu> schrieb:
>> Enrico Weigelt <weigelt at metux.de> writes:

>>> Please differenciate between people and roles. If you're in the role
>>> of a packager, your job is to create an automatically installable
>>> package for your distro, out of your upstream - nothing more, nothing
>>> less.

>> I completely disagree with this definition of the packaging role.

> Well, then you'll have to live w/ fundamentally problematic workflows,
> unnecessarily redundant work, etc. It's your choice.

All problems are simple if you define them out of existence.

The general discussion here, though, is about supporting packaging
workflow in the general case.  I encourage you to think about the hard
problems, not reduced and simplified cases.  If all one is doing is purely
packaging upstream releases without modification, or with only a few
patches pulled from upstream in some situations like security updates,
it's not clear to me why anyone would even bother to use a VCS for
anything other than the distribution-specific packaging files, let alone a
complicated tool like TopGit or similar approaches.

Those tools become useful when you're doing something more complex than
just wrapping some packaging around whatever upstream releases, and it's
those more complicated cases that (as I understand it) sparked this
mailing list in the first place.

Hence, I don't think it's useful to say "well, you shouldn't do anything
more complicated, then."  Doing something more than just wrapping upstream
binaries in a package is exactly the reason why I'm interested in working
in Debian.  It's the whole point.  If all I wanted to do was install
whatever upstream released, I can do that with ./configure && make && make
install.

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