Re: How to cope with patches sanely
Am Donnerstag, den 31.01.2008, 13:36 +0100 schrieb Pierre Habouzit:
> On Thu, Jan 31, 2008 at 12:08:24PM +0000, Daniel Leidert wrote:
> > Am Mittwoch, den 30.01.2008, 21:22 +0100 schrieb Pierre Habouzit:
[..]
> > > Well, the point is that your repository isn't self contained in that
> > > case.
> >
> > My VCS always contains a debian/watch file or a get-orig-source target.
> > So everything necessary is available.
>
> Nope, you don't have the merge capabilities of your $SCM to backport
> patches, and see them automagically go away when you package the next
> upstream release.
So you are referring to a patchless-maintenance (ditto for Colin Watsons
answer). I can imagine this has advantages if you maintain a package
alone. But it IMHO makes it harder to track changes in collaborative
maintenance and requires excellent merge qualities of the VCS, which
currently seems to guide to just one VCS: git. But especially the
possibility to use any (aka the preferred) VCS (at alioth.d.o) seems to
be one of the main advantages of the current approach for me.
> > > Thanks to my workflow and pristine-tar, my $SCM holds _everything_
> > > from what I need to regenerate the orig.tar.gz, to my packaging, my
> > > patches, and the upstream sources.
> >
> > Not different to mine, except one has to run uscan, apt-get source or
> > debian/rules get-orig-source.
>
> I only need one tool, $SCM.
Yes. But then we have the question, if separated patches or a large
patch are easier to understand. If you are the only maintainer of a
package, you made the changes and you should of course understand even a
large diff.gz. But if e.g. the QA team or a new maintainer has to take
over a package, it will be harder for him to understand your changes
(here I speak from my experiences taking over several docbook* packages
or xmlto). Then separated patches are much easier to understand.
> > Taking a look at the description of pristine-tar, I could of course
> > put the .tar.gz under version control (AFAIK several projects using
> > the mergeWithUpstream mode put the .orig.tar.gz under version
> > control).
>
> You're wrong, I don't store the whole orig.tar.gz, I keep its content,
> and the delta (often less than 2kb).
Then I seem to misunderstand you. What does "content" mean, if you do
not store the whole .orig.tar.gz? Do you just store the diffs between
upstream versions?
> Each new upstream release costs
> little extra size, and the more revisions there are, the less
> additionnal size I need (because there are already enough good files to
> make good deltas in the repository). The more a git repository grows,
> the slowest.
Can you show me a public example? To be honest, I have some problems to
understand your workflow.
> > To be honest: Why should I care about an upstream tarball, that is older
> > than everything in the Debian archive back to oldstable?
>
> I can see that you never packaged anything complicated, just by that
> assertion.
You shouldn't make assumptions you never tried to check.
> History is important, a full VCS history is even better,
> because you can tell when a change (think regression) occured, and
> understand why.
A regression made in a version older than the one in oldstable? Pierre,
are you kidding me? How often this will happen? Which package(s) are you
referring to?
> Of course, if you never look at your upstream code, I
> understand that you may not care.
Seems you never took a look at my work. If this is the kind of
discussion style you want to use, I'll better stop the discussion with
you. I can waste my time with more interesting things than getting
offended by stupid assumptions.
PS: Can you please stop CCing me? I read debian-devel and I do not need
any CCs nor did I request them.
Regards, Daniel
Reply to: