On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> Architectures
> =============
> As some of you might have noticed, we added the architectures
> kfreebsd-i386 and kfreebsd-amd64 to testing. [...]
> However, two architectures also have issues we need to bring to your
> attention: We sent mails to the porters of both alpha and hppa [...]

So, http://release.debian.org/squeeze/arch_qualify.html lists kfreebsd-*
and m68k as not release candidates, and arm, ia64, mips and powerpc as
"at risk" in addition to alpha and hppa. Only m68k is listed as having
RM concerns.  Is that page actually reflecting the release team's view
of architecture status at all, and could it be made to correspond a bit
more closely either way?

> About freeze timing we think that DebConf should definitely not fall
> into a freeze

Past freezes were:

    potato  2000/01 - 2000/08   (DebConf 0 was early 2000/07)
    woody   2001/07 - 2002/07   (DebConf 1 was immediately after the
                                 policy freeze started, DebConf 2 happened
                                 a week or two before woody released)
    sarge   2005/05 - 2005/06   (DebConf 5 was a month after release)
    etch    2006/12 - 2007/04   (DebConf 7 was three months after release)
    lenny   2008/07 - 2009/02   (DebConf 8 was in 2008/08, a month into the 
freeze)

How you relate DebConf 3 and DebConf 4 to sarge's "freeze" is up for
debate, I suppose; while sarge "officially" froze a month before release,
that's not necessarily "real".

I really don't see what the big deal with having debconf during a freeze
is though...

> and that we should leave time after DebConf to integrate
> the possibly disruptive changes we introduced by doing cool stuff at
> DebConf. 

Fixing RC bugs is pretty cool...

> We noticed that releases in the first quarter of the year
> worked out quite well in the past like both Etch and Lenny. Taking these
> into consideration we think it would be best to freeze in December.

Etch was intended to freeze in October, with a release in December; the freeze
was delayed because of a high bug count (250 RC bugs). I think there was pretty
heavy peer pressure to have any transitions and major uploads done well before
December for etch. And lenny, of course, was frozen in July...

> We'll be consulting all key teams within Debian to see how their plans
> and schedules can fit into a new timeline. Before the end of August we
> hope to have finished this process of consultation and be able to
> present the new plan to you.

Why not have a developer poll as to what month(s) would most suit
people for the freeze, rather than limiting it to "key teams"? Also, how
about soliciting input from our users, just in case they have something
interesting to add? Maybe LTS-syncing will turn out to be something users
really do/don't want, or maybe there are other priorities they have that
are worth considering.

Cheers,
aj

Attachment: signature.asc
Description: Digital signature

Reply via email to