Debian release team meeting minutes

Hi,

this are the release minutes of yesterdays release team meeting.


Cheers,
Andi

Release Team meeting minutes - 2005-06-18

Non-public part (from 18:00 UTC till 18:30 UTC)
Attendends: Steve (vorlon), Joey Hess (joeyh), Frank (djpig), Andi (aba);
Colin (Kamion) excused.

Discussion about bringing new people into the team for etch. We will ask
for volunteers via mail, and give them tasks (like Anthony did before
already). [Task: aba needs to write the mail]


Public part (after 18:30 UTC till 22:50 UTC):

further attendends:
Ryan (neuro), Joerg (Ganneff), Frans (djp), Matthias (doko), Jeroen (jvw)
and further.


What do we learn from sarge?
============================

- base freeze was too long

- "don't second-guess your own freeze guidelines and update gettext just
  because Santiago tells you it's safe, because then you'll be kicking
  yourself for making gcc-3.3 FTBFS."

- makeing the status more transparent: create an issue list like
  p.d.o/~aba/sarge.html within release.d.o, keep it current and announce
  it well. [Task: aba]

- d-r@l.d.o doesn't scale for freeze-exception requests - but this can
  be avoided to handle the more important ones via a better BTS, and
  reduce the number of requests.

- better tracking of missing RC bug fixes (will be solved with version tracking
  in the BTS)

- QA the CDs (and also all other parts of the release) before they're
  published

- checklist with dependencies for release stuff - don't process out of order
  [more input wanted, will be within release.d.o]
  - web site ready before actual release
  - working on documentation (packages, release notes) needs to be
    started before the actual full freeze

- make sure the CDs are hidden before we officially release

- build the CDs from the official final stuff - but that would mean no
  dinstall for 2+ days or so (in other words: do we really want it? -
  would make live easier though for all people working on the release)

- security infrastructure was out-of-order for 1 weeks after the release
  - can we fix that? (Or at least announce it better than with a
    uncertain blog entry.)

- we should have a pseudo-package for the release-notes ASAP, so people could
  file issues as soon as they see them
 
- should start working on the release notes about 6 weeks prior release;
  asking for contributions should be done in release updates



Release policy changes/more QA
==============================

some ideas are rather QA-ones, some are really meant for release policy.

- vorlon's library manifest stuff [QA; vorlon is on it]

- duplicate code / static libs [QA; aba will work on it]; however, doko
  notes that statically linking is sometimes required for performance,
  e.g. bash; that'll get better with libs using -fvisibility, but libs
  need to be prepared for that so it's not possible to just add that to
  the compiler command line.

- installability [release policy is already hard; djpig does QA work
  on it]

- reduce number of duplicate libs/packages [QA]

- forbid changing changelog and build-dependencies automatically:
  release policy change (automatically as in "happens during normal
  builds") [Task: text by aba]

- editorial change: non-us is removed from the release policy [Task: aba]

- LSB: probably go for version 3, perhaps even 4 or so?, co-ordination
  with Matt Taggart needed

- -fPIC will still be required on all archs - exceptions can be done
  like now (currently, there is one on i386)

- document in release policy that MTAs don't need -bs if they conflict
  with LSB (like currently nullmailer) [Task: aba]

- syncing policy and release policy should be done [Task: aba]

- python policy/implementation needs review - doko and aba will discuss
  that on debconf probably

- editorial: release policy might need reformating

- tell people more often to do checking before they upload to unstable
  (ok, no real release policy, but still sensible)



Timeline
========

We discussed what would be nice, and what are actual release blockers.
"What would be nice" can still become RC if enough of it is done in
time.

release blockers:
- toolchain transition
- xorg
- sorting out docs-in-main vs. the DFSG
- SCC; amd64 as an official arch
- sorting out non-free firmware
- secure apt


pet release goals (aka non-blockers):
- building everything with libselinux
- finishing /usr/doc
- pervasive LFS support
- symbol versioning in libraries where it's needed
- rethinking how we handle lib dependencies (see discussion on d-d@l.d.o)
- dependency-based init
- a true system locale that doesn't use the /etc/environment configfile.
  We can then localize the entire boot process.
- utf-8 default
- manifest-like binary: header in .dsc that's actually correct
- fixing udeb sync issues (afawui, fixed by britney after SCC)
- kernel: not more than 2 versions; 1 source package for all archs
- getting rid of circular deps (in the general case; there are corner
  cases in essential)
 
With these lists, a 15-18 months cycle seems sane.


Rough timeline is (with numbers being days; some minor adjusting might
be required):
N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
                        e.g. cdbs)
N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
N-45   = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i R
C]
N      = Mon  4 Dec 06: release [1.5 months for the general freeze]



Announcing mail
===============

Vorlon will munge his (not yet sent) "sarge is out"-mail with the "etch
started"-one.

We will announce that non-DFSG-free docs needs to be
relicensed/disappear, and file bug reports a month after that
[Task: djpig will work on bug reports] - bit depending of course on the
progress that the next GFDL makes.