Re: time based freezes
On 04/03/2011 06:15 PM, Stefano Zacchiroli wrote:
> On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
>> Time based freezes
I very much agree that with an increasing complexity
of our distribution that goes together with an increasing
heterogeneity of tools and teams, there will always be
some waiting for something to get fixed/improved. A
particular time to freeze, if one does not freeze too often,
seems like a very good idea, then.
The time-based freeze should be decided together (if
possible) with accepting a constantly usable testing .
This way, the release team and the commnity may have
some better understanding what exactly it is freezing.
> Road maps
To me, it would be interesting to have releases to be
associated with particular new features that are not too
likely to be backported. When there is no such unique
feature, one should not freeze but just continue updating
CUT and help backports where appropriate.
We should all be waiting for those new features to become
functional and stable in Debian, not for the release team
to make a particular decision - even though this effectively
may be the very same thing.
> Freezing what?
When backports are integrated very closely with the
main distribution, the question what or when to freeze is not
really a question any more, I tend to think.
We do have quite a number of packages, especially in the
scientific world, for which the versioning is very important.
Different users, or even different projects for the same user,
may require different versions. To have snapshot.debian.org
and backports, together with good support for chroots and
virtualisation, which we have, shall be considered more
important for many than the question when and what to freeze.