track bugs in VCS, not the other way around (was: divergence from upstream as a bug)

[martin f krafft]

also sprach Joey Hess <joeyh at debian.org> [2008.05.17.2201 +0100]:
> 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..

I am not even going to try to read this thread, so please excuse if
I repeat what others have said. We should make it policy that the
original proponent of a discussion (Joey here) becomes the chair and
has to keep a summary of the discussion up to date on a wiki. I know
you'll hate me, Joey, but I think it would make sense.

Let me say up front, that I agree with the parallels between bugs
and divergence, since we want to minimise diffs and keep bug counts
low.

However, I think Joey's idea would be a step backwards. Let me
explain.

> 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.

I love debbugs, dearly! It fits nicely into my workflow, or maybe it
welded my workflow, I don't care -- I like it.

But it's awfully brittle and a giant pile of hack. If we didn't have
Don and the few others who aren't entirely confused by the code
base, we wouldn't have bugs.debian.org anymore.

I cringe every time we make an enhancement to debbugs, pictures of
band aids and superglue come into my mind, and I fear the day when
our (over-)reliance on debbugs is going to hurt us *bad*.

We have a lot of "integration" in place between debbugs and other
parts of the project, like the PTS, debian/changelog parsing, etc
etc etc. They work for the most part, but they're horribly brittle
I find. It seems to me that a lot of information is stored in more
than one place, creating redundancy which will cause problems, or if
not, then at least require massive amounts of extra work to keep it
in sync.

Atomicity does not exist.

What we're trying to do right now is more or less keep track of
patches in Debian packages. Joey proposes to use bug reports for
that. It *does* make some sense, but it's far-fetched. Very
far-fetched. Yes, we want to minimise bug count *and* diversion from
upstream, but does that mean we have to map one onto the other?

Let's assume for a minute that we accept that VCSs are the way
forward and start to consider how we could track bugs in the VCS,
alongside the code.

Start to think about it this way, and stuff suddenly neatly aligns,
at least in my world.

Suddenly you can commit a patch and mark the bug fixed atomically.

Suddenly, bug reports become commits in a branch, and keeping the
branch empty is your goal.

Divergence from upstream is represented in topic branches, and you
want to keep the number of those minimal to not go insane.

You also get all the benefits of a distributed system and if we find
ways to cooperate with other distros via one and the same repository
[0], bugs would be shared, but done right from the start [1].

0. http://vcs-pkg.org
1. http://madduck.net/blog/2008.05.06:how-launchpad-got-it-wrong

I have no details on this yet, but the general idea. Let's not
create more dependence on our aging BTS, please.

And yes, I will try to create a wiki page summarising this subthread
in the next few weeks, if the idea isn't completely unrealistic.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"and if the cloud bursts, thunder in your ear
 you shout and no one seems to hear
 and if the band you're in starts playing different tunes
 i'll see you on the dark side of the moon."
                                                   -- pink floyd, 1972
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20080521/7d267e7e/attachment.pgp