* Joey Hess <[EMAIL PROTECTED]> [080517 23:01]:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite naturally..
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.
> For all the maintainers who already keep on top of forwarding their
> changes upstream, this won't be much of a burden; ideally you just CC
> the BTS and add some pseudoheaders.
Except that this hardly fits in reality. With active upstream you
usually have the discussion first, and decide to add the patch after
that and considering the impact on the code, the severity of the bug and
the perspective of upcoming upstream releases.
> For ones who can't, because they
> cannot communicate with upstream (for whatever reason), it gives them a
> way to communicate with other interested parties (users, other distros)
> and maybe resume communication with upstream in the future.
We have already such a place. It's called the .diff.gz. It's linked
everywhere, on every mirror in the same directory as the software.
This file is there to contain and show what is changed.
Admitted, the original one file diff is not perfect for multiple
patches, but for this adding additional patch files in there works
smootly.
This is were people look at and what I from looking for changes of other
distributions of packages I maintain often miss elsewhere: A complete,
current list of what is actually changed.
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.
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.
And when extending the source packaging format, do not throw away the good
properties lightly. Git for example is no format to present
modifications. It is one to present history (which is almost but not
quite something completely different).
Thanks in advance,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
