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

Re: Debian decides to adopt time-based release freezes



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Debian decides to adopt time-based release freezes

No, the project DID NOT decide it, the release team did, and the
project has to accept it; there's a lot of difference.

> The Debian project has decided to adopt a new policy of time-based
> development freezes for future releases, on a two-year cycle. Freezes

and what are the real advantages of this? I saw none in this announce.

> will from now on happen in the December of every odd year, which means
> that releases will from now on happen sometime in the first half of every
> even year.  To that effect the next freeze will happen in December 2009,
> with a release expected in spring 2010. The project chose December as a
> suitable freeze date since spring releases proved successful for the
> releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux
> 5.0 ("Lenny").

if time-based is REALLY needed, why then not "freeze on even Dec and
release on Spring on odd years"? this will allow the current release
cycle to have enough time to achieve something, while letting
time-based proposers happy.

> Time-based freezes will allow the Debian Project to blend the
> predictability of time based releases with its well established policy of
> feature based releases. The new freeze policy will provide better
> predictability of releases for users of the Debian distribution, and also

bullshit! we are trading quality for what? We release when it's ready,
not when the clock ticks. it's completely a non-sense, and it's
generating only bad feelings in developers and users.

and predictability is the only advantage of this proposal? if so, then
simply let's drop it: pro and cons are damn wrong.

> allow Debian developers to do better long-term planning.  A two-year
> release cycle will give more time for disruptive changes, reducing

Not this time.

> inconveniences caused for users. Having predictable freezes should also
> reduce overall freeze time.

should we remember here that lenny freeze took +6 months?

> Since Debian's last release happened on Feb. 14th 2009, there will only
> be approximately a one year period until its next release, Debian
> GNU/Linux 6.0 (codenamed "Squeeze").  This will be a one-time exception
> to the two-year policy in order to get into the new time schedule. To

why on earth we need this exception? *we* are deciding (let's pretend
this) what will be our time schedule, so we can decide to have "freeze
on Dec even years, rel on Spring odd years" policy and we can save
squeeze as long as the next development cycles.

Or there's something else behind the curtains that it's not being said
(consciously), like ubuntu LTS?

> accommodate the needs of larger organisations and other users with a long
> upgrade process, the Debian project commits to provide the possibility to
> skip the upcoming release and do a skip-upgrade straight from Debian
> GNU/Linux 5.0 ("Lenny") to Debian GNU/Linux 7.0 (not yet codenamed).

so, what's the point in preparing squeeze? let's just skip it then

> Although the next freeze is only a short time away, the Debian project
> hopes to achieve several prominent goals with it. The most important are

Who is hoping this? we have still a colossal amount of work to do, and
we are just said "hey, we'll freeze in 5 months: get it done, fir RC
bugs and let's kick out squeeze). that's not encouraging.

Rel team needs commitment from developers to release, and this is not
the way to get it.

> multi-arch support, which will improve the installation of 32 bit
> packages on 64 bit machines, and an optimised boot process for better
> boot performance and reliability.
>
> The new freeze policy was proposed and agreed during the Debian Project's
> yearly conference, DebConf, which is currently taking place in Caceres,
> Spain. The idea was well received among the attending project members.

1. what about the developers that couldn't come to DC? don't we
deserve to be asked for our opinion? are we of a lower class? is this
a decision only made by a team and then you want to us to pretend the
whole project decided it?

2. it doesn't seem all the attendants agreed with it, given what
happened yesterday evening on #debian-release.

To conclude:

- - we are giving up our quality-based release for a time-based one
for no particular reason
- - there is a constant drift away from debian by our users, this
would be the killing shot
- - we didn't know this decision was being discussed
- - we received no alert with enough time to work on make squeeze
happen (and then we talk about time-based release, bah)
- - this is a change in our most important aspect of our work: the
release. How can I go now to my boss and propose to switch to debian
once this is happening?

Not to mention how many angry replies are coming, I feel the community
of debian developers is not accepting this decision silently.

- --
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iEYEARECAAYFAkpv3/wACgkQAukwV0RN2VA0hwCfXCMIt/1oskEz1melH91QNzXb
S9MAn2P1kxY16R2o6Ay53OUfyZEYh1si
=CgR9
-----END PGP SIGNATURE-----


Reply to: