also sprach Joey Hess <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> : :' : 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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)