On Thu, Feb 07, 2008 at 05:12:00AM +0000, Manoj Srivastava wrote: > On Tue, 5 Feb 2008 09:00:52 +0000, Matthew Johnson <[EMAIL PROTECTED]> said: > > > On Tue Feb 05 00:51, Manoj Srivastava wrote: > >> > If we can't figure out a good and clean way to keep a large stack > >> > of long-lived patches in the vcs then I firmly believe we should > >> > standardize on quilt. > >> > >> I think I have indeed solved the issue of long standing feature sets > >> using feature branches, integration branches, and sloppy branches > >> while upgrading, and would not want to be forced to regress to a > >> patch system. > >> > > I don't think anyone is talking about forcing DVCS users to regress to > > a patch system, merely to change the interchange format; which all > > DVCS-based maintenance methods can easily export to/import from. The > > only reason which you would have to interact with it would be a more > > standard interface for NMUs, which can only be a good thing. > > Why should I bring my feature branches into a patch system, when > there is no need to? As far as the end user or NMUer is ocnerned, they > do apt-get source foo, and they get the sources they may hack > on. Adding to the chaos by converting my nice, clean source format to > the blecherousness of a patch system does seem like regression to me.
That's not really about "bring your feature branches" into a patch system, but rather export them into something that looks like one so that the security team or the NMUer can have a good outlook of the modifications you apply to upstream. It sounds like a fair thing to me. You can't decently ask the security team to know every single $SCM out ther, and guess how $random_developer use it (especially, sorry but it's true, when it's a SCM as complicated as tla is). -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgp4RScm9eFKg.pgp
Description: PGP signature
