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

Release Team meeting minutes - 2005-06-18


this are the release minutes of yesterdays release team meeting.


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

- 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)


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

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
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

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: