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

Notes on IRC meeting


We had a short, rather spontaneous (arranged this afternoon) meeting in
#debian-release. Here are the notes, feel free to comment if anything
seems weird, plain wrong or otherwise makes you wish to say something:

Current transitions and things that need to be done in the near future:
 * imagemagick: 
   - Bugs filed (double-check), porters need to prodded, might be done
     in a week
   - adsb is tracking it
 * liblo: 
   - Hanging on sivp, bugs needs to be filed, might be solved by removing
   -  HE is tracking it
 * python2.6:
   - Phase 1: add support for 2.6 for multi-python-supporting packages
   - Phase 2: 
     + build packages for default version 2.6
     + Known open issues:
   - aba is tracking it 
 * mpi-default switch:
   - might lead to arch-specific problems
   - lucas will try a switch to mpich2 on amd64 to find possible
     problems, report to -release@
 * parted:
   - Colin sent mail to -release, detailing everything needed
   - phil is tracking it

Some other transitions we know about and have discussed in some detail:
 * eglibc:
   - waiting in experimental, waiting for hppa-specific fixes (#573991)
   - lucas will do a rebuild to identify possible breakage
   - looks complicated, need more information
   - HE is tracking it
 * ruby1.9 -> ruby1.9.1:
   - already ongoing (20 packages, half done)
   - needs to fix ruby1.9.1/sparc FTBFS (new kernel?)
   - HE is tracking it

Remaining transitions:
 * directfb
   - relatively small, but coupled to gtk/cairo (gtk will be decoupled
     once the g-i switch from directfb to X.org is done, pochu is
     going to upload the relevant packages)
 * icu
 * boost -> 1.42 switch
 * qt4.6
 * KDE 4.4
 * Gnome 2.30 things
 * icedove3
 * Smaller stuff with probably no impact on the rest of testing/unstable

 (1) We should finish at least imagemagick and liblo
 (2) We might be able to switch the python default to 2.6 after that,
     which will be a massive transition breaking anything in its path.
 (3) We can do directfb and icu at the same time (either after or before
 (4) boost, qt4.6 and kde4.4 touch the same packages and should not be
     done at the same time to avoid a horrible mess - seems reasonable to
     do boost before qt4.6 and kde4.4 last. Input from the KDE team would
     be nice.

 We calculated about a week to 10 days for (1). We might be a bit faster
 than that.

 (2), the python switch, will most probably take two to four weeks, if
 nothing horrible pops up. This involves a massive binNMU campaign of
 ~200 packages plus a number of sourceful uploads.

 This would imply that we can reasonably expect to be done with the
 python2.6 switch around end of april. Afterwards, we will need to get
 everything done that couldn't move due to python2.6. A freeze in late
 may/june seems to be possible, if people work hard on getting these
 transitions done.

Release Update:
  We want to write one till the end of the week. Topics:
   * Give an overview over the current release situation (transition
     status, bugginess, release goal status)
   * Discuss our plans for the future, including the timeline from above
     and any changes that may be discussed on -release in the meantime.
   * Point out when we want to freeze, and that this depends on the work
     of all developers. Give a short primer in "how to make Debian
      (1) fix your own bugs
      (2) fix someone elses bugs
      (3) fix your bugs that popped up during (2)
      (4) only upload stuff that you consider stable
      (5) go out and buy a party hat
      (6) celebrate the release
   * Warn that we will remove RC-buggy packages if there is no
     maintainer reaction. Explain that getting back in after you've
     fixed the bug is easy, so a removal is not as bad as people might
   * Call for help: We need more release people
     Use one of the planned transitions to explain what the usual work
     is (approximate impact, get as many bugs as possible fixed before
     starting the actual transition, prod buildds and maintainers to get
     all packages into the right state, shove it all into testing)
   * New RM:
     None, for now. All release team members have full authority on all

Fachbegriffe der Informatik - Einfach erklärt
119: Dateimanager
       cd, ls, cp, mv (Ulli Horlacher)

Reply to: