Re: How to cope with patches sanely
On Sat, 23 Feb 2008 16:58:01 +0100, Pierre Habouzit <madcoder@debian.org> said:
> On Sat, Feb 23, 2008 at 03:08:23PM +0000, Manoj Srivastava wrote:
>> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow
>> <dnusinow@speakeasy.net> said:
>>
>> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> >> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> >> <madduck@debian.org> said:
>> >> > That does not help me during an NMU from the source package.
>> >>
>> >> For an NMU of one of my source packages, if you can't deal with
>> >> the distributed SCM, then you need not worry about differentiating
>> >> the feature branches, fix the source conflicts, upload. I'll deal
>> >> with fallout. Comes with the territory.
>>
>> > If you're applying 10 to 20 different feature branches to your
>> > upstream, then that all comes to the NMU'er as one giant diff. This
>> > obviously sucks and it's what we've been complaining about Ubuntu
>> > doing to us for years. We can do better.
>>
>> I have hear you say this before, but I am not convinced that the
>> situations are really similar. You see, with Ubuntu, I do not see
>> any place they provide the information in a nice separate area, even
>> using their preferred SCM, bzr.
>>
>> That is not the case when using featrure branches, the NMUer can get
>> the information they need.
> Not really, he needs to grok your $SCM, and well, really, nobody but
> you (and his author maybe, and even that is unsure) grok baz. And not
> even everybody groks git that I'm so fond of.
If you want to NMU a package, and ituses CDBS, you need to
understand CDBS. If it uses dpatch, you need to understand dpatch.
Same with quilt.
You only need to understand tla and git if you need to keep
track of the independent features in the the package development; which
is an issue only for maintainers (not security NMUers, who are rightly
more concerned with fixing the security hole in a timely fashion).
> Having a clean exchange format where _anyone_ groking diff, ls,
> $EDITOR, their shell and some as basic tools is much much
> better. Nobody asks you to _work_ with those, it would be just plain
> great if you just could generate those instead of a big bloat of
> unreadable diff (maybe your packages don't have megabytes of diffs,
> but as soon as you relibtoolize a package, they do).
It is non-trivial to generate a linear series of patches from a
set of pure feature branches. If anyone thinks it is indeed trivial,
and they can implemet a general solution, I'd be happy to stand
corrected, and will use the tool. I don't think, with my experience of
pure feature branches, that it is as trivial as the people painting
this bikeshed think it is.
manoj
--
If your life was a horse, you'd have to shoot it.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: