Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Thu, Feb 07, 2008 at 05:12:00AM +0000, Manoj Srivastava wrote: > > 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.
In the scenario Manoj presents above, the modifications applied to upstream are easily available all in one place: the foo.diff.gz. > 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). In the scenario Manoj presents above, no-one in the security team needs to know how to do anything but get the source package, since that gets the complete original source and a foo.diff.gz showing exactly what changes are applied. With 'debcheckout' even knowing what VCS is used will be unnecessary. Whereas with a patch bundle system, the security team needs to know *every* patch bundle system in use and how to use it, just to have a chance of operating on arbitrary Debian source packages. -- \ “It is far better to grasp the universe as it really is than to | `\ persist in delusion, however satisfying and reassuring.” | _o__) —Carl Sagan | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
