Re: divergence from upstream as a bug
"Bernhard R. Link" <brlink@debian.org> writes:
> * Russ Allbery <rra@debian.org> [080518 15:28]:
>> 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.
Er, yes. However, what I was responding to was your feeling that these
aren't bugs in the Debian package. I think often they are, in that the
Debian-specific change is less than ideal (per Policy 4.3) and needs
additional work.
> 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.
Sure, I don't think anyone disagrees with that.
> 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.
Yup, and that's exactly the point of the discussion. Joey's proposal
about using the BTS is one set of tools that would generate such a web
site, using the web site generation and tracking logic already present in
the BTS to keep it maintained. There are other possible ways of
implementing such a web site, of course.
>>> 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.
Well, yes, obviously. But I almost never see this outside of discussions
like this where it's used as an example of what not to do. In practice,
nearly all code is under-commented and these sorts of problems are rare.
> 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.
This is kind of a digression, but.
Most code that's lived in the wild for a while will develop workarounds
and obscure fixes to problems that were not at all obvious when it was
originally written. The details of those workarounds and fixes *need* to
be written down, and as much as we might wish otherwise, there is no
programming language in existence that makes such problems so clear that
it can usually replace comments.
The general rule of thumb used in many parts of GCC is that if you had to
fix a bug in a piece of code, you probably should at least consider adding
a comment making it clear why the code needs to be written the new way,
since it's apparently not as obvious as you think (or the previous coder
wouldn't have gotten it wrong). That's correct more often than not in my
experience.
Yes, of course, you have to maintain the comments just like you have to
maintain all other documentation or they quickly become worse than
useless.
>> 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.
What does this have to do with your point? As you say, that's not a
modified version. I think it's messy too, but it's not like we're putting
Debian-specific modifications into the upstream *.orig.tar.gz (which as
far as I'm concerned would be a fairly serious bug).
> 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.
I'm a bit lost. Is this referring to the debate over handling DFSG
modifications to upstream tarballs that we had back when the GR passed?
> 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.
Oh, this is still quite common, but I don't think that's an example of
your point. I think it's an awkward way of laying out the package, but
usually the people who do this are even *more* careful about using
pristine upstream tarballs -- that's exactly why they use this layout,
which can do things like handle multiple upstream tarballs. The tradeoff
is that you have to unpack the *.orig.tar.gz to get the upstream tarball,
but it is there.
>> 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.
This isn't what I'm talking about. Git is quite good at presenting
*modifications* if you know how to use it. Diffing topic branches is as
easy and as reliable as looking at patches in debian/patches, and provides
better tools for manipulating the results. gitk shows a much better
picture of the relationship between branches than one can get from a quilt
series file, once you know what you're looking at.
The drawback is that you have to know how to use Git. I agree that this
is a drawback and that expecting all upstreams to know how to use Git
isn't reasonable.
> 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.
That's why my point was restricted to Git, not VCSes in general. (And Git
with a particular workflow, really.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: