Planning Dapper+1

Raphael Hertzog hertzog at
Thu Apr 20 10:01:25 BST 2006

Le mercredi 19 avril 2006, Mark Shuttleworth a écrit :
> core Canonical team. I'm promising to impose (almost ;-) zero from-the-top
> requirements for Edgy, this release is entirely up the to development
> team to envision and implement. Of course, feature proposals need to
> go through a review and approval process, and we'll make sure everyone
> has enough on their plate to keep busy during the cycle, but almost 
> everything that lands in Edgy will be driven from the development team, 
> who get to play with whatever new technologies they fancy along the way. 
> So that should give us a nice big bump in infrastructure and bling.

I like this idea! Since I've been unable to convince Mark or Matt to get
some Ubuntu developers work on a Debian-Ubuntu collaboration infrastructure,
I would hope that some Ubuntu developers from the core team would be
interested to make use of this liberty to:
- at the very least, fix scott's patch repository so that it keeps the
  Debian source package used as a basis for the Ubuntu package (so that it
  can always generate useful diffs)
- send information about the updated diffs to the PTS (this is currently
  done in the Utnubu side, but it seems more logical to integrate it where
  the patches get created)
- work on something more elaborate:

Paving the way for a new serie of successful Ubuntu releases also comes
down to integrating more of your work into Debian. Less merges
in dapper+2 means more time for trying out new technologies...

BTW, the spec above has been mentionned in Linux Weekly News[1]. It shows at
least that this is something that looks sensible to a big part of the free
software community.

I do have ideas of what kind of infrastructure the Utnubu team needs to be
more effective, I have no formal spec yet, but I proposed my idea for
Google's Summer of Code[2] and maybe we'll manage to set it up that way but
otherwise I would welcome any help. The idea is to have a tool where
we can feed list of packages affected by a large-scale change and where we
can follow (step by step) the progress of that "change/migration". With
some good documentation, it can be very effective to get new contributors
help on migration involving lots of small changes (example: integration of
all Ubuntu modifications to have init scripts use LSB functions, thus
enabling good integration with usplash/whatever).

Please use this opportunity to help me foster a better Debian-Ubuntu


[1] (probably subscribers only until next
[2] See the "Migration Tracking" idea:
Raphaël Hertzog -+-

Freexian : des développeurs Debian au service des entreprises

More information about the ubuntu-devel mailing list