Re: track bugs in VCS, not the other way around
martin f krafft wrote: 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. Martin, I think this is an extremely sensible plan. IME all bug trackers ever do is fill with old stale rubbish. I would also add, that a certain number of best practices be adopted; this will assist in upstream maintainers reviewing and adopting patches, no matter what VCS or system of development they use: - all patches should be clearly described by: - a one-line subject description of the change - an introduction to the patch; why it is necessary, what the code base did before it was introduced, and an outline of the approach to be taken. For trivial changes, this might be one sentence. - authorship and reviewer information (From, Signed-off by, Acked-by lines or even Cc in some cases) - no reference should be made in the patch introcuction to things which become useless after the patch is applied, such as which version it is for. - optionally, a comment about this revision of the patch, information that will not be useful to a maintainer of the patch, clearly delineated from the long-term description of the patch. - no changes that are not a part of the description are allowed. - Patches that require further minor changes later for acceptance should be rolled together, so that the upstream has less work to review and you don't get this patch fixes that patch etc. The question about what to do with revised/dropped patches would likely be solved on a per-VCS basis - Ideally, no single patch should break the product's test suite. Individual projects may be more lax about this requirement when applied to patch series. - Where the upstream source control provides an easy way to do so - such as repositories hosted in repo.or.cz, github, etc - a new branch should be created which contains the above patches, so that people visiting the source control of the product can see the outstanding changes requested by the debian project as an explicit fork. - Patches may simply update an ERRATA file, if they are a simple confirmed bug report. Note that many of these are really just a restatement of best common practices since people started sending patches to mailing lists in the mid-80's. They have since been explicitly codified and rigidly enforced in the Git community, so people will see that these are essentially the Linux Kernel Development guidelines, just without any specification of the exact format of the patch. While it is tempting to standardise on git-format-patch format, I don't think it is productive to bring that detail in right now. Yes, I realise that those who are frequently cross-merging will have a hard time turning their feature branches into this form. However, the patches do not necessarily have to be applicable to the head version, as long as the above requirements are met. Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: track bugs in VCS, not the other way around
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, martin f krafft wrote: [...] 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. Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a distributed bug tracker that stores bug information as metadata in VCS branches. I don't think it's exactly what you're talking about but it may be a source of inspiration. Cheers, Jelmer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDQysgy0JeEGD2blAQJl2gP+N5bEFaZspXP/3ELAOL37dkCeU3mbzmAO 4S5glbsDXqSnesvxCqY9ZULAPPatkSOYFcFMnkbC4YN+AwXE4S6xx4RQBcUZcdeK 0oMobJp6k3JzwNmuFGCX/usF1lRvs1+sXnPLsAh+2FAamM7iuKcEZ8O7mkUyuJtQ YsmfP5nmtbU= =pjNx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: track bugs in VCS, not the other way around
also sprach Jelmer Vernooij [EMAIL PROTECTED] [2008.05.21.1633 +0200]: Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a distributed bug tracker that stores bug information as metadata in VCS branches. Yes, but I didn't remember the name on the plane. :) -- .''`. 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 perl -e 'print The earth is a disk!\n if ( a == b );' (dedicated to nori) digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: track bugs in VCS, not the other way around
Jelmer Vernooij [EMAIL PROTECTED] writes: Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a distributed bug tracker that stores bug information as metadata in VCS branches. I'm currently working on URL:http://bugs.debian.org/477125 a Debian package for Bugs Everywhere URL:http://bzr.debian.org/bzr/collab-maint/bugs-everywhere/. I don't think it's exactly what you're talking about but it may be a source of inspiration. Bugs Everywhere is a simple idea that is a good way to have a BTS for people whose main mode of collaborating is via a DVCS, and won't or can't set up a central bug tracker. This fits enough projects that I'm on that I was motivated to package it in Debian. However, I think that for people who have 'debbugs' to work with (i.e. the Debian project), Bugs Everywhere might actually be a step *backward* from 'debbugs'. Currently, a Bugs Everywhere database is visible only to those who use the VCS to get a copy of the branch, and use the Bugs Everywhere command-line tool to query the database. The 'debbugs' available to Debian developers has a web interface that over the last few years provides comprehensive order out of the chaos of our bug database. Currently, a Bugs Everywhere database can be manipulated only be people who will use the VCS to get a branch, use the command-line tool to manipulate bugs, and use the VCS again to propagate their changes to others. Using 'debbugs' requires only that one know how to send email. These interface issues alone are enough to disqualify something like Bugs Everywhere from being proposed as a serious alternative to Debian's 'debbugs' instance. Likely a quick look at the actual features of Bugs Everywhere would easily come up with other shortcomings compared to 'debbugs', but I won't. -- \ “I think there is a world market for maybe five computers.” | `\ —Thomas Watson, chairman of IBM, 1943 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
