[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: