2833
Comment:
|
← Revision 25 as of 2009-03-16 03:31:12 ⇥
2467
converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
#language en | |
Line 3: | Line 4: |
As many of you know, I am conducting research on Debian, | As many of you know, I am [[http://martin-krafft.net/phd/|conducting research on Debian]], |
Line 16: | Line 17: |
I will be blogging about recent developments some time soon, specifically about the change in direction of my research, so watch [http://blog.madduck.net/phd this space] or just read [http://planet.debian.org the planet] if you are interested. |
|
Line 22: | Line 19: |
* cdbs * debhelper * alioth * devscripts (dch, nmudiff, tagpending) * arch/tla-buildpackage * svn-buildpackage * cvs-buildpackage * darcs-buildpackage * quilt * dpatch * dbs * planet * lintian * linda * piuparts * pbuilder * reportbug |
What comes to mind when you think about these tools (feel free to add new ones). * Have they been widely adopted? * What may be reasons for this wide adoption? * If they haven't been widely adopted, can you think why? ---- At Stefano's suggestion, I am categorising the tools: * [[/PackagingHelpers|Packaging helpers]]: debhelper, cdbs, pbuilder, sbuild, ... * [[/GeneralHelpers|General development helpers]]: devscripts, schroot, PTS, ddpo, snapshot.d.n, ... * [[/BugTracking|Bug tracking]]: debbugs, reportbug, CIA, user tags, ... * [[/Collaboration|Collaboration]]: alioth, *-buildpackage, ... * [[/PatchManagement|Patch management]]: dpatch, quilt, dbs, ... * [[/PackageCheckers|Package checkers]]: lintian, piuparts, ... * [[/APTArchiveManagement|APT archive management]]: debarchiver, apt-ftparchive, mini-dinstall, ... * [[/Policy|Policy]]: Debian policy, other policies, ... * [[/Misc|Misc]]: dbconfig-common, debconf, planet, ... |
Line 42: | Line 42: |
This is stuff I need to process at one point... ---- |
|
Line 43: | Line 47: |
{{{ | |
Line 47: | Line 50: |
- new maintainers guide, very strong influence (debhelper, lintian) - tools used by the sponsor (pbuilder, piuparts, linda, ...) - reference guide and policy guide |
- new maintainers guide, very strong influence (debhelper, lintian) - tools used by the sponsor (pbuilder, piuparts, ...) - reference guide and policy guide |
Line 56: | Line 60: |
}}} Alastair McKinstry: {{{ I've always wondered about the lack of "regression testing" tools in Debian: it seems suprising that we haven't integrated some measure of automation into checking what breaks when a new package is uploaded, eg. running regression tests on all registered users of a library when a new library release is uploaded. debian-test looks to have been a stalled attempt at that, one I may restart. }}} Marco d'Itri: {{{ I also think it could be interesting to notice how new features in dch are reflected in the actual changelogs. }}} Michael Banck: {{{ cdbs was successful, just ask gnome-debian. Sure, it wasn't always without problems... }}} Steinar H. Gunderson {{{ * planetplanet: the jury is still out on that. planet.d.o would be a lot more useful if I didn't have to wade through mile-long, completely non-technical posts from people I don't know. :-) }}} |
Introduction
As many of you know, I am conducting research on Debian, specifically on how Debian developers adopt or reject new methods of package maintenance. I would like to get a broad collection of data for the first part of my research, which is the study of tools that have been successfully adopted or which have been rejected (so to speak) by the developer crowd.
While I already have a good selection, I am on the look for more. Do you know of a good example of a tool that has successfully shaped Debian development for a large number of people? Or do you remember a tool that tried but horribly failed? Those are much harder to find.
The tools
What comes to mind when you think about these tools (feel free to add new ones).
- Have they been widely adopted?
- What may be reasons for this wide adoption?
- If they haven't been widely adopted, can you think why?
At Stefano's suggestion, I am categorising the tools:
Packaging helpers: debhelper, cdbs, pbuilder, sbuild, ...
General development helpers: devscripts, schroot, PTS, ddpo, snapshot.d.n, ...
Bug tracking: debbugs, reportbug, CIA, user tags, ...
Collaboration: alioth, *-buildpackage, ...
Patch management: dpatch, quilt, dbs, ...
Package checkers: lintian, piuparts, ...
APT archive management: debarchiver, apt-ftparchive, mini-dinstall, ...
Policy: Debian policy, other policies, ...
Misc: dbconfig-common, debconf, planet, ...
Notes from the emails
This is stuff I need to process at one point...
Bart Martens: I believe that these sources of knowledge about such development tools influenced me to accept or reject the tools, in descending order of importance to me.
- - new maintainers guide, very strong influence (debhelper, lintian) - tools used by the sponsor (pbuilder, piuparts, ...) - reference guide and policy guide
Suggestions to use group maintenance tools, like "please coordinate with the Debian Perl Team if you want to adopt this package" or "you might want to consider joining the debian-ocaml-maint team and use our svn repository" don't convince me and feel like a waste of time, although I know that people really mean well.