Release Team meeting minutes - 2005-06-18
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.
Reply to: