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..
The bug can be tracked, with a patch, in our BTS. The bug can be
forwarded upstream as the patch is sent upstream. A tag "divergence" can
be used to query for all such bugs, or to sort such bugs out of the way.
Other tags and BTS data can be used if desired. For example, "divergence
fixed-upstream", "divergence wontfix", "divergence help". Versioning
information can be used to track when an upstream version resolves the
divergence. Discussion and updated patches can be CCed to the bug log.
The BTS could be enhanced to allow opening a bug and forwarding it
upstream in a single message. (IIRC currently, it takes two). This would
allow a very simple workflow where a DD makes a change to a package,
generates a patch, and sends it upstream while also recording the
divergence in the BTS.
There would also be scope for other workflows, as well as automated
tools. If a package has a debian/patches, some of which have been
forwarded upstream and some not, then a tool could query the BTS (or
headers in the patches, whatever) to figure out which have yet to be
sent upstream, and send them. Tools could also do this for changes
recorded in a VCS.
For QA, a tool could compare the divergences recorded in the BTS with
the source of the package and warn developers about unrecorded
divergences, and divergences whose patch doesn't appear in the package's
source (due to the patch being accepted upstream, or being changed after
being sent to the BTS).
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. 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. Maintainers
who make more patches than they have time to send to upstream will have
a problem, and might get other people filing bugs against their package
about that, which actually helps them deal with the problem. It seems a
win-win all the way around.
Of course it means that every package is insta-buggy, but we can deal
with getting those bugs recorded piecemeil[2]. Looking over my packages, I
think I could get all their current divergences recorded in the BTS within
the week. (And if it would help to have a concrete example of this proposal,
I volenteer to do that.)
PS, I don't want to give the wrong impression: I don't think that this
would have avoided the openssl disaster, and this email is not a
reaction to that.
--
see shy jo
[1] Specifically, changes outside debian/, and changes inside debian/
that result in the upstream source being patched, or add stuff
like man pages that should really be added upstream.
[2] Or attempt to win Bubulle's contest by filing them all now, also
fine by me.
Attachment:
signature.asc
Description: Digital signature