Re: How to cope with patches sanely
Pierre Habouzit <madcoder@debian.org> 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
Reply to: