Re: divergence from upstream as a bug
* Russ Allbery <rra@debian.org> [080518 16:50]:
> "Bernhard R. Link" <brlink@debian.org> writes:
> > 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.
My point was especially as having an interface to those files. Writing
automatic things to feed those in the BTS will surely be more work than
having a page just parsing those file directly.
Having the maintainer put things there means more work on the maintainer
to spread stuff to more places. This punishes maintainers doing a good
work (updating a description or refreshing a patch needs multiple
actions) and creates a danger of things getting out of sync.
> 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.
Useable code is almot always under-commented. When you force or educate
people to write comments, you regulary get comments worse than no
comments. It's just efford wasted in the wrong direction.
> 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.
As I said, comments are best when there are little. Not comments are
best when there are none.
> 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.
And I totaly agree. But it has nothing to with my point.
> 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).
Well, the only thing suggesting this that strictly is devref.
> > 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.
You have to download the tarball, then find out where the patches are,
and how they are stored in there, and then how they are applied.
It adds quite a bit of complexity to answering the question "what
exectly is modified here".
> 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 think to actually get this to work, and to get it to work in
non-trivial examples, you need quite a deep understanding of git.
At least I don't think that things like making one feature branch
depending on another after those already exist for some time sounds
that easy...
Hochachtungsvoll,
Bernhard R. Link
Reply to: