On Wed Jul 29 09:59, Sandro Tosi wrote: > of course, if we have to take formal steps for everything, we'll do a > >> > 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. > > > > freeze != release, I'm not happy with the way the decision was > > communicated. I beg you to mind your wording tough. > > I know it was unpolite, but it's the only way I can express my > feelings right now. The tone aside, I think it is important to note the difference between freezing on time and releasing on time. The freeze date is a cut-off for new upstream releases, feature development etc. Having a well-known in advance date by which people need to complete their feature development, particularly one which we know is hard and not (as we've had recently) liable to slip will give developers the ability to plan better. I know that in the last release I was holding off from uploading things which I could have done because I thought we were about to freeze and wanted to allow things to move to testing, but we didn't freeze, at least partly because other developers hadn't planned well enough to time their uploads with the announced freeze date. The release, however, will be when it's ready. We have said nothing about how long the freeze will be. I'm hopeful that the scheduled freezes will allow us to reduce the freeze time. -- Matthew Johnson
Attachment:
signature.asc
Description: Digital signature