Re: divergence from upstream as a bug
* Russ Allbery <rra@debian.org> [080518 15:28]:
> > Except that it has an important scope problem. Divergences with the
> > Debian package are not open bugs in Debian, they are open bugs in
> > upstream that are localy fixed within Debian.
>
> I don't think this is as universally true as it looks on first glance.
> Often the reason why the divergence remains a divergence is because it's a
> quick hack that only works on (for example) Linux systems or glibc systems
> and upstream would accept it if it were better-implemented.
This is an orthogonal issue. That explains why some patches are not yet
incorporated upstream. It does not explain why the patch is necessary.
> Except from upstream's perspective, it's a mess, and not necessarily worth
> their time to bother to read. All the debian directory stuff is mixed in
> with Autoconf noise, config.* updates, and actual changes they might care
> about. Even if the patches are broken out into separate files in
> debian/patches, they now have to download the diff and apply it to
> something to get readable patches. And after they go to all that work,
> they may discover there's no meaningful divergence at all; there's no
> warning in advance of whether that's the case.
It may be a mess, but it is there. And it is always current.
Not having or knowing all things like diffstat and co make it hard to
read, but it is a place and format everyone can find and everyone can
look at.
I think adding a website which nicely formats those files (with
diffstats, and properly showing included patch files) would be a thing
that really helps all involved people. Not only upstreams forgotten
or vanished and reappeared. Not just other upstreams of forks. But also
our users to see at once what is changed.
And with no additional impact for maintainers than to look at using
proper formats, adding description to the patches and stuff like that.
> > 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.
>
> Hm, you and I may have very, *very* different ideas of what
> well-maintained code looks like. :)
Things like
/* add 1 to where p points at */
*p++;
are not helpful. If types and variable do not speak or even only indenting
is incomprehensible, comments can not help. A comment stating what one
can see with one look at once glare do not help but are annoying once
no longer in sync. Prose being so long one cannot see the code and the
types of the local variables on the same screen is also most likely
causing more problems then helping. Good code with comments helping
with the things not codified (which should be little, or the
code cannot really be called good) is good. Bad code will hardly get
better and not really much more maintainable with more comments.
> > 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.
>
> Isn't this already the case in practice? Do you really see many Debian
> packages that have modified *.orig.tar.gz tarballs? And if so, have you
> filed bugs?
They may not be so many, but there are. FTPmasters consider .orig.tar.gz
repackaged (though without modification) so minor they just accept them.
Our secretary tells people devref is not even worth looking at because
that says different things in that regard than he likes to do himself.
And packages having a .tar.gz containing the real tar files and
sometimes even patches may be seldom and declining but to be stumbled
over regulary.
> Git is quite good at presenting modifications if you know how to use it.
Git is good at representing history. It might be nice for a maintainer
to see that line X was once changed and then changed again later, or
rather not really changed but only merged with the new upstream. And
then some years later the variable accessed here was renamed thus the
line had to be changed again.
I've from time to time tried to look at other people's modifications to
packages I maintain. And especially the BSDs tend to always have had all
stuff in VCSes. I'd rather have a large .diff.gz without any other
smaller files than to have to wade to history. (In the former it are at
least other changes, which sometimes might be related to what I look at,
the history is almost never intresting[1]).
Hochachtungsvoll,
Bernhard R. Link
[1] That does not claim that it is never or not very valuable then. But
for the common case it is so much littering, that if it somewhere, then
that should be somewhere else.
Reply to: