[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DEX update and next steps



= Launch and New Members =

The DEX announcement seems to have been very well received.  Thanks to
everyone who forwarded, mentioned, re-dented and otherwise shared the news.
We gained 10 new developers in the days following the launch!

Please welcome:
- Allison Randal
- Amaya Rodrigo Sastre
- Andrew Mitchell
- Andrew Starr-Bochicchio
- Bilal Akhtar
- David Paleino
- Jeremiah Foster
- Micah Gersten
- Nathan Handler
- Steve Langasek

= Ubuntu Ancient Patches Project =

Summary of current status:
http://dex.alioth.debian.org/ubuntu/ancient-patches/status/

The vast majority of these have been reviewed and confirmed to have been
merged or otherwise fixed in Debian.  Thanks to David Paleino, Colin Watson,
Nathan Handler and Steve Langasek for their contributions.

This leaves the non-trivial ones which may require some discussion about
what to do:

* http://people.ubuntu.com/patches/dhcp3.deroot-server.diff
  (Debian bug: http://bugs.debian.org/308832)

  This patch allows the DHCP server to run as non-root.  Someone asked about
  its status on the bug report on 2 Feb and didn't receive a response from
  the package maintainers.

  Ubuntu is still carrying this patch in isc-dhcp-server today, so there's
  an up-to-date version available which applies to 4.1.1-P1-15.

  It's marked forwarded, and there's a reference to upstream bug 17488, but
  I can't find the upstream bug tracker (maybe it's not public?).

  I think this patch would be beneficial to merge into the Debian package,
  and we can continue to try to get the code changes upstream.

  Suggested action: talk to one of the maintainers listed at
  http://alioth.debian.org/projects/pkg-dhcp (Andrew Pollock, Luk Claes,
  José L. Redrejo Rodríguez, Matt Kassawara or Per Carlson)

  Could someone take responsibility for this?

* http://people.ubuntu.com/patches/kernel-package.safe-initrd.diff

  This patch was intended to make initrd creation safer by writing it to a
  temporary file first and then renaming it, rather than overwriting it
  in-place.  The same problem may have been fixed in the Debian kernel
  packages, in kernel-package or in initramfs-tools.

  The Ubuntu kernel packages have since diverged and no longer use
  kernel-package, and I'm not familiar with how this works in Debian today.

  Suggested action: Examine the relevant packages and confirm that the
  problem has been fixed and initrd images are written safely in Debian.

* http://people.ubuntu.com/patches/kernel_udebs_from_kernel_source.diff
  (Discussion: http://lists.debian.org/debian-boot/2004/11/msg01446.html)

  This patch was submitted to the Debian kernel team, and there was some
  discussion about it, but the outcome was unclear.  Again, I'm not very
  familiar with how kernel package maintenance works in Debian today, so I'm
  not sure if this is still a relevant issue.

  The patch itself is almost certainly not useful at this point, but it
  would be useful to know whether Ubuntu and Debian still do this
  differently, and if so, if there are good reasons to maintain that
  difference.

  Is anyone here more knowledgeable about the Debian kernel?

* http://people.ubuntu.com/patches/pbbuttonsd.fixrunlevel.patch

  This patch seems to change the default runlevels and sequence number for
  pbbuttonsd, and adds postinst code to make the transition.  It seems to be
  still carried in Ubuntu today.

  Is anyone here more knowledgeable about pbbuttonsd?

* http://people.ubuntu.com/patches/sysklogd.no-root.diff
  (Debian bug: http://bugs.debian.org/35325)

  There's an open wishlist bug suggesting that syslogd could run as
  non-root, and this Ubuntu patch was submitted to it in 2004.  Ubuntu is
  still carrying this patch today, so there's an up-to-date version of it
  available.

  Meanwhile, both Debian and Ubuntu now use rsyslogd by default.  Should we:

  - Try to get this patch merged into Debian
  - Forget about it because sysklogd is no longer important enough

  Thoughts?

* http://people.ubuntu.com/patches/sysvinit-quietinit.patch
  (Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326677)

  This patch added a "quietinit" boot parameter which would suppress the
  "booting" message which was otherwise printed unconditionally.

  It was since dropped in Ubuntu because it's no longer necessary as
  the splash screen is started earlier.  Ubuntu subsequently switched to
  upstart, so it is doubly unnecessary in Ubuntu.

  It was filed in the Debian BTS by a Debian maintainer, and the bug is
  still open, but I think there's probably no point in merging it at this
  stage and it should be dropped.

  Would it be OK to simply close this bug and withdraw the patch, or should
  we have a discussion with the maintainers first?

= Next Steps =

I'd like to start compiling ideas for the next Ubuntu DEX project, once the
above tasks have been completed.  Here are some ideas:

- Big merges: Create a list of packages with large or problematic deltas,
  and try to rationalize them.  There are a relatively small number of
  packages which carry a lot of patches.  We should try to get them in sync,
  and also try to solve the underlying problem which caused the divergence
  so that it doesn't happen again.

- Patch sweep: Generate a list of outstanding Ubuntu patches in the Debian
  BTS (we have usertags for this) and help to get them all merged: work with
  the maintainers, rework patches as needed, make NMUs where the package is
  orphaned etc.

- New packages: Continue the Utnubu effort to identify packages which are
  new in Ubuntu and not in Debian yet, and try to get them into Debian (file
  WNPP bugs? upload orphaned packages? find maintainers? sponsor the Ubuntu
  maintainer?)

I'd appreciate your thoughts on these and suggestions for other projects.
I would prefer to work on projects which can have a defined end point, which
we can finish and move on, rather than open-ended projects like establishing
new procedures, mentoring, and so on.  Those are important too, but I think
at this point there is a lot of concrete work we could do which will make a
bigger difference in the short term, and help us learn more.

-- 
 - mdz


Reply to: