rethinking patch management with GIT / topgit

[Enrico Weigelt]

* Manoj Srivastava <srivasta at acm.org> schrieb:

>         This is not how I define a Debian developer. We are not Debian
>  Pacakgers -- and we do much more than just pull things into a
>  tarball. 

Exactly that's the problem (and that's also the reason why certain 
other distros have the big "we're not Debian"-paradigm ;-o).

> Debian *DEVELOPERS* are just that -- a full member of the community, 
> helping develop software, including features that might only
> be possible for Debian, because of polices that one may rely on in
> Debian.

Yeah, perhaps such great innovations like the libdnet package, that 
does _not_ contain libdnet, but some DECnet client library, which
starts some deamon in the postinstall script that plays around
w/ your network devices and shoots you off the net (especially 
charming for remote boxes / servers) ;-o

>         Trying to separate out hats at this stage is more work than is
>  worth the effort. 

Yes, and professional IT companies have process management
w/ separate rules, release engineering, etc, etc just for fun ? ;-o

> And thus I carry feature branches until upstream takes them, or, 
> forever, if the feature takes advantage of Debian specific attributes.

Perhaps you could give some concrete examples for really Debian
specific features (which so aren't interesting for upstream or
maybe a cleanly forked one), which have to happen directly inside
a standard package ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------