Re: divergence from upstream as a bug
* Goswin von Brederlow <goswin-v-b@web.de> [080518 16:09]:
> The diff.gz contains all the changes including the debian dir. It is
> by no means obvious if there are patches in there or not.
The limit to a single file is a real problem. But at least the
information has to be in there, and a .diff is usually tried to be
reasonably small.
Compared with some vcs information, where one has to first learn the
layout of that vcs, how branches are accessed via some webinterface
or (even harder) the actual tool. And so on...
> > Everything else is just overhead, as with comments in source
> > code: they are nice to have as long there little, but if there are too
> > many they are most of the time outdated, wrong or distracting.
>
> I find the why and how a patch came together important
> information. You compare this idea to comments in source code. I find
> those invaluable in understanding sources. So you actually made a
> point for the idea imho.
A comment in code that describes how something was implemented is not
really what you want. What you want is information about the current
code: How it works, what is important, what possible pitfalls there are.
Sometimes history can substitute for a bit of that information ("A
changed this in May 1998 to foo, B changed it back one week later because
that causes problems elsewhere" can subsitute for "note that this and
that other code needs this and that here").
Sometimes history is even part of this information (a la "This was once
so and so, be prepared that old data can have this").
History can be valuable information to track down when and how some problem
was introduced, but it is simply so much more information that one needs
an additional view for the important stuff.
> > Instead of adding new stuff, why not actually enforce and improve what
> > we have:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> Say goodby to all packages with +dfsg tarballs. This is just not practical.
Hey, I said "or pure subsets of those". For this the devref "suggests":
"should not contain any file that does not come from the upstream
author(s), or whose contents has been changed by you."
> The quilt extension is certainly a big improvement and will hopefully
> unify a lot of patch system using packages after lenny.
Though I guess there still needs to be a way to get such a patchset
constructed from non-quilt based work models, especially with things
centered on history. For example something to tag commits to git
repository, so some package creating tool can put changes belonging
together (like a modification and its updates for newer upstreams)
into a single .diff of such a series. (be that meta-tags in the
description, automatic utilisation of feature branches, extending the
git format or whatever git experts can think of or consider worthwile)
(or perhaps I'm just too stupid to find branch-hopping and manual
merging manually convenient enough to actually do).
Hochachtungsvoll,
Bernhard R. Link
Reply to: