Differences between revisions 1 and 25 (spanning 24 versions)
Revision 1 as of 2006-07-31 11:06:37
Size: 2833
Editor: madduck
Comment:
Revision 25 as of 2009-03-16 03:31:12
Size: 2467
Editor: anonymous
Comment: 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:

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.