Re: time based freezes
On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote: On 2011-04-24, Stefano Zacchiroli lea...@debian.org wrote: Dear Release Team ... good luck in proposing a freeze month now :-) I would propose mid september or mid-march. That's just after 2nd patch release of new set of releases by KDE. And why not new gnome release, or maybe new kernel version or even any other program packaged I think that, the best choice is to follow a time based release content definition which may be described by the following procedure. 1) Release team calls for a release content with a target date +/- 3 month. 2) DD answer each with his road map (bugs, new upstream releases, ...) which should fit in for the date, within a month from the call date. 3) Release team, compiling the information, fills bugs for new feature and tag bugs for the next release. 4) DD confirm/infirm the tags within 1 month 5) Release team fixes the freeze date BTW, if the freeze happens on a separate copy of testing (let's say frozen), it will be great. Uploads should target frozen, be built into it (not into unstable). Only bug fixes are allowed on it. Cheers, signature.asc Description: This is a digitally signed message part
Re: time based freezes
[Abou Al Montacir, 2011-05-04] On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote: On 2011-04-24, Stefano Zacchiroli lea...@debian.org wrote: Dear Release Team ... good luck in proposing a freeze month now :-) I would propose mid september or mid-march. That's just after 2nd patch release of new set of releases by KDE. And why not new gnome release, or maybe new kernel version or even any other program packaged because I'm too lazy to send 42 mails¹ every 2 years, specially when some of recipients might start ignoring them after receiving two with different dates and most other upstreams will not get such mails at all. You can pick the release date of your favourite $foo package with popcon=0, I really don't care as long as we can put Debian freezes on $month every $parity year on http://www.debian.org/ and not change it for next decade or so. Upstream authors that care about Debian, will try to release new stable version on time, the ones that don't will just do what they do now and we'll deal with it the same way we handle it now. [¹] even if created as 1 mail with 41 addresses in CC ;-P -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504131453.gl17...@piotro.eu
Re: time based freezes
[ M-F-T to -devel ]
On Thu, Apr 07, 2011 at 06:00:09PM +0200, Stefano Zacchiroli wrote:
Another thread, another thread summary! Here is a summary about where we
are on this discussion, at least as far as I can tell.
Lather, rinse, repeat.
snip
I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.
This seems to be uncontroversial; modulo the fact that *if* the freeze
month is not absolute but relative (to the start of the cycle), people
might want to have a round of consultations with the release team before
a proposal is made. [1]
- On the other hand, a wide open front of the discussion is *when* to
freeze, with various people arguing in favor of having a specific
period, such as we freeze on $month every even/odd year.
Also considering the potential problems discussed, no objections have
been raised to such a scheme either. It seems this is something we might
want to try out.
Independently of the above, I've also received a few comments in private
mails on the risks that announcing a precise freeze day in advance
(i.e. close to the freeze month, according to the discussed scheme)
might be prone to last-minute uploads issues. While I understand the
problem, it seems to me that the alternative option of impromptu freeze
announces has its own set of problems (reducing the ability to plan in
advance and upsetting developers) which I believe outweighs the
advantages. All in all, this specific choice seems to be independent of
the general scheme of deciding a freeze month and stick to it.
Dear Release Team ... good luck in proposing a freeze month now :-)
Cheers.
[1] In my opinion, this is another argument in favor of absolute freeze
months, as it would make the whole cycle more resilient to
communication inertia (something we are trying to fight in general,
in several project areas), but I cannot claim this is part of
consensus as I'm introducing it only now.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: time based freezes
On 2011-04-24, Stefano Zacchiroli lea...@debian.org wrote: Dear Release Team ... good luck in proposing a freeze month now :-) I would propose mid september or mid-march. That's just after 2nd patch release of new set of releases by KDE. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnir90aa.p7v.nos...@sshway.ssh.pusling.com
Re: time based freezes
[ Bcc:-ing release team ]
On Sun, Apr 03, 2011 at 06:15:52PM +0200, Stefano Zacchiroli wrote:
Since other follow-ups have avoided this topic up to now, let me be the
reckless guy who jumps into it with both feet: time based freezes!
Another thread, another thread summary! Here is a summary about where we
are on this discussion, at least as far as I can tell.
- The general of concept of time-based freeze seems to be
uncontroversial. Apparently (and unsurprisingly, if I may) people
would love to have a date early on to base their roadmaps upon.
- The choice of having a specific date seems to be more controversial
(although honestly I don't see how it could do any harm). Anyhow, it
seems noone would object to have a target freeze month at the
beginning of a release cycle, seeing it refined later on. Various
people have argued that the target freeze month shouldn't be larger
than one month, and I personally agree with that: having a larger
period has IMHO the potential to introduce back some of the planning
issues we have seen during the Squeeze cycle.
I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.
Regarding a more precise definition of later on, I agree that for DDs
it wouldn't make much of a difference, but things might be different
from usptream, on which we have way less control. As a rule of thumb, I
believe it would be useful to put a limit like the following: the exact
freeze date will be announced 6 months before the freeze, the
latest. That would IMHO enable those upstream who care about Debian to
reliably plan their releases in order to better collaborate with us.
- The question of what to freeze seems to be uncontroversial as well,
the scheme of pre-approving packages used for the Squeeze freeze
(which I overlooked in my kickstart mail) seems to be appreciated.
- On the other hand, a wide open front of the discussion is *when* to
freeze, with various people arguing in favor of having a specific
period, such as we freeze on $month every even/odd year.
I've sympathies for such a schemes myself, if only for the simplicity
to grasp and remember it by heart. Let's look at some data about
that. I observe that Debian has released every 24 months (+/-2) since
the days of Etch in 2007. Even if we include Sarge, which has had a
particularly long release cycle, the average is still around 25
months. Freezing every 24 months will be compatible with such a trend
(assuming it will continue, see below for a related question). If for
instance we say we freeze in August (or pick your month) every
even/odd year, that would allow us to release in February, in case RC
squashing would proceed as it did for Squeeze.
No objections have been raised to such a scheme up to now and I would
welcome it as well, as it could bring roadmap advantages for both DDs
and upstreams. The only problem is ...
- ... what to do if a development cycle (i.e. the period from the
previous release to the next freeze date) would turn out to be too
short? That could happen when the previous release takes more than 6
month to stabilize and to get RC bug cleaned. I believe the figures we
are talking about give enough margin not to worry too much about it.
Let's assume for example that Wheezy would freeze (as an entirely
hypothetical scenario) on August 2012 and that it would take a whole
year to stabilize and release it on August 2013. That would reduce by
6 months the release cycle of Wheezy + 1, but still leave 1 full year
of development from August 2013 to August 2014, the standard freeze
date. Considering that 1 full year for stabilize a release should lead
us to worry in general about the well-being of our project (or about
the specific software choices we made in that cycle) and that even in
that case there will be 1 full year of development to catch up, I
think such a scheme would be a reasonably safe bet.
I do think it's worth going there (freeze every 24 months on a
specific month), but I wanted to mention the above risk nonetheless,
as it is an important one to keep in mind.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: time based freezes
Hi Carsten, just a few more comments on your mail which I haven't
covered in the separate summary mail I've just sent.
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote:
We are in the good position to have a very experienced release team that
is be able to decide whether testing is in a good condition to be
frozen. It should also have option to adapt their time planing to the
team's responses to what are your plans for stable+1? mails or to
events that can't be known a few weeks after the prior stable release
has happened.
I couldn't agree more, but TBH in setting a release scheme for the
future, I don't think we should make any assumption on the experience of
the release time. I believe the scheme should have its own merit, no
matter who will be called to put it into use. That would also have the
additional advantage of putting a bit less responsibility on the release
team (OK, just a little bit less, but it could make a difference on
whose who need to explicitly volunteer to take on their shoulders a
highly sensitive task).
That's also part of the reason why I don't think we should rely *only*
on what are your plans for stable+1 mails. Those are of course very
good and I'm sure answers to those questions would help a lot the
release team anyhow. But at the same time if we could find a scheme
where a release period precise enough to enable DDs to define their own
roadmaps work by default, without having to wait for specific human
intervention, I believe it would be better. Of course nothing will stop
the release team to make exceptions on the basis of those answers or on
the basis on any other factor they see fit, but seeing them as
exceptions would hopefully induce them, and the project as a whole, to
think twice about the consequences.
This time frame could be rather imprecise at first and narrowed over
time.
Fair enough, I've integrated this comment in an updated proposal.
(Although I've taken into account there several other comments of people
who proposed a specific threshold of 1 month to the imprecision.)
This seems to be suboptimal (probably it's just your wording). The
following quote from a mail sent by the release team in 2008 describes
how it also has been handled for Squeeze:
| Packages that are present in unstable the day we freeze will be
| automatically allowed into testing, that is, the freeze date ... does
| not mean your package should be in testing by then, but only in
| unstable.
ACK-ed as well in my other mail, thanks to yours and other comments.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: time based freezes
On Thu, Apr 07, 2011 at 06:00:09PM +0200, Stefano Zacchiroli wrote: [ Bcc:-ing release team ] Why Bcc?! [...] I would love if we can summarize the above part by saying that we have consensus on: 1) announcing at the beginning of a release cycle a target freeze month, 2) refining it later on. I think you're missing step 0: the release team consults with the whole body of developers, presumably with a suggested freeze date/month as a starting point. This would also mean step 1 would be delayed slightly. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407164248.gz2...@decadent.org.uk
Re: time based freezes
On Thu, Apr 07, 2011 at 05:42:48PM +0100, Ben Hutchings wrote:
I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.
I think you're missing step 0: the release team consults with the whole
body of developers, presumably with a suggested freeze date/month as a
starting point. This would also mean step 1 would be delayed slightly.
Well, it depends. If for instance we go for the fixed-period scheme
(proposed in this thread and discussed in the latter part of my mail)
the specific freeze month is fixed in advance. I agree that the
decision of that specific month should go through a we propose this
first, but it will happens once and for all (barring the need of
reviewing it which of course might arise in the future).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: time based freezes
On Thu, 07 Apr 2011 18:00:09 +0200, Stefano Zacchiroli wrote: - On the other hand, a wide open front of the discussion is *when* to freeze, with various people arguing in favor of having a specific period, such as we freeze on $month every even/odd year. Count me in. - ... what to do if a development cycle (i.e. the period from the previous release to the next freeze date) would turn out to be too short? Or too long, if we manage to make the freeze shorter ... that even in that case there will be 1 full year of development to catch up, I think such a scheme would be a reasonably safe bet. Me too. And in the opposite case we have a bit more time; that might even be an incentive to fix more RC bugs during the freeze :) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Sting: Fields Of Gold signature.asc Description: Digital signature
Re: time based freezes
On 04/05/2011 06:55 PM, Martin Wuertele wrote: * Bernd Zeimetz be...@bzed.de [2011-04-05 15:04]: On 04/04/2011 01:15 PM, Piotr Ożarowski wrote: most of the work is done by our upstreams, and by simply telling them we'll freeze PICK_YOUR_MONTH every even/odd year will (in the long term) improve quality of Debian *a lot* more than choosing a random^Wperfect (and different) date for every release cycle (and not announcing it to upstream authors *at all*), IMHO Ack! We need to be able to give our upstreams a fixed release date so they can plan ahead to have their release ready in time. If they don't manage to do so it is not our fault anymore at least. s/release date/freeze date/ and I agree. Erm yes, that is what I thought but my fingers did not type. fixed freeze date, of course. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9c55f9.90...@bzed.de
Re: time based freezes
On Mon, Apr 04, 2011 at 12:12:09PM -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: One thing that the release team already is improving is communication, [snip] The other thing that has potential to be improved is the freezing. [snip] I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? It would be, but I started it on d-d-a :) Neil -- I think it's your point of view and I don't agree with you here. I have a good relation with the upstream author and don't think it is necessary for me to understand the code. - Request for a freeze exception -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404201136.gb46...@feta.halon.org.uk
Re: time based freezes
On 04/04/2011 01:15 PM, Piotr Ożarowski wrote: most of the work is done by our upstreams, and by simply telling them we'll freeze PICK_YOUR_MONTH every even/odd year will (in the long term) improve quality of Debian *a lot* more than choosing a random^Wperfect (and different) date for every release cycle (and not announcing it to upstream authors *at all*), IMHO Ack! We need to be able to give our upstreams a fixed release date so they can plan ahead to have their release ready in time. If they don't manage to do so it is not our fault anymore at least. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9b134f.8050...@bzed.de
Re: time based freezes
* Bernd Zeimetz be...@bzed.de [2011-04-05 15:04]: On 04/04/2011 01:15 PM, Piotr Ożarowski wrote: most of the work is done by our upstreams, and by simply telling them we'll freeze PICK_YOUR_MONTH every even/odd year will (in the long term) improve quality of Debian *a lot* more than choosing a random^Wperfect (and different) date for every release cycle (and not announcing it to upstream authors *at all*), IMHO Ack! We need to be able to give our upstreams a fixed release date so they can plan ahead to have their release ready in time. If they don't manage to do so it is not our fault anymore at least. s/release date/freeze date/ and I agree. yours, Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405165549.gf16...@anguilla.debian.or.at
Re: time based freezes
On Mon, Apr 4, 2011 at 3:38 AM, Carsten Hey cars...@debian.org wrote: We released in February 2011 and we want about one and a half year between a releases and the following freeze, so we freeze in fall 2012. Please, *NEVER* do fall or summer or winter. Remember that Debian is developed all around the world, and half the world has the opposite seasons that you have. You can say December and you have a month of leeway to then decide, or November-December to have two months. But please, please, please, no seasonal releases. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=v7u0cjgna7qygbjkajebx-ws...@mail.gmail.com
Re: time based freezes
On Wed, Apr 6, 2011 at 1:14 AM, Margarita Manterola margamanter...@gmail.com wrote: Please, *NEVER* do fall or summer or winter. Remember that Debian is developed all around the world, and half the world has the opposite seasons that you have. You can say December and you have a month of leeway to then decide, or November-December to have two months. But please, please, please, no seasonal releases. Indeed. Also, the word fall is not universally known around the world so using it makes the freeze time even less intelligible. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTin=ubHCs�x88gqjnimyeovs-...@mail.gmail.com
Re: time based freezes
The release team did again a great job the past release cycle and managed to release again a version Debian can be proud of :) There were of course things that could be done even better next time, but handling such a enormous task without such issues seems to be impossible. One thing that the release team already is improving is communication, for example, they did ask for feedback and welcomed comments in their mail to debian-devel-announce. One example of less outstanding communication that happened during the past freeze is that squeeze-updates has been announced without any prior discussion. Important aspects of proper communication include comprehensible justification of decisions and also predictability. As part of an explanation they once wrote DebConf should definitely not fall into a freeze and that we should leave time after DebConf to ... in an announcement. A year later they did the opposite and froze at the end of DebConf. Other reasons that were considered internally like synchronisation with other distributions were missing in this first mentioned announcement. The other thing that has potential to be improved is the freezing. The relevant part of freeze history is in my opinion: * There were two mails from the release team regarding uploads on d-d-a in the week before Lenny was frozen. * Contrary to what was communicated earlier, Squeeze was frozen weeks before most people expected it and before the announced Perl transition has happened. If the release team would skip those we freeze next week mails, there wouldn't be such a flood of uploads just before the freeze. If they would additionally stick with what they announce, nobody would complain that a freeze would have happened unexpected. * Stefano Zacchiroli [2011-04-03 18:15 +0200]: On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote: Time based freezes -- Road maps - I believe we need time based freezes. Even more radically, I believe we need to know the freeze date as soon as possible, e.g. no later than a couple of weeks after the preceding release. (Obviously, transitioning to time based freezes warrant exceptions to the rule.) I believe we need to know a vague time frame for freezing instead. With your proposal the release team might announce: We released on the 7th of February 2011 and freeze Wheezy one and a half year later on the 7th of October 2012. With mine they could announce: We released in February 2011 and we want about one and a half year between a releases and the following freeze, so we freeze in fall 2012. My rationale for the above is simple: *road maps*. Each team and individual developer should be able to define their own road maps very early in a release cycle. Doing so will help teams in planning and splitting work. Both would address the roadmap issue. I believe it will also help maintainers in negotiating release dates with upstreams which are sensible to distribution needs. Deciding whether this would be a good thing could be highly controversial. Strict date --- The difficult part in moving to such a scheme is that the freeze date must be strict. We are in the good position to have a very experienced release team that is be able to decide whether testing is in a good condition to be frozen. It should also have option to adapt their time planing to the team's responses to what are your plans for stable+1? mails or to events that can't be known a few weeks after the prior stable release has happened. That is the case because, as history has taught us, announcing a freeze date and not respecting it Avoiding not respecting announced time frames or dates should not be that hard. ---or, equivalently, have announced freeze dates which are generally believed to be only indications---will spread frustration among developers. This time frame could be rather imprecise at first and narrowed over time. Freezing what? -- The next question is then what does freeze means. Does it mean that automatic transition to testing stops automatically at freeze date, This seems to be suboptimal (probably it's just your wording). The following quote from a mail sent by the release team in 2008 describes how it also has been handled for Squeeze: | Packages that are present in unstable the day we freeze will be | automatically allowed into testing, that is, the freeze date ... does | not mean your package should be in testing by then, but only in | unstable. All in all, I quite like the idea of a strict freeze date + a flexible period during which exceptions are granted in a more liberal manner, as it has happened for the first weeks after the Squeeze freeze. The basic idea of a more flexible period is great, but it was not properly communicated via debian-announce. Freezing when? -- A scheme that could work is deciding that we'll have a development period of a specific
Re: time based freezes
On Mon, 04 Apr 2011, Carsten Hey wrote: I believe we need to know a vague time frame for freezing instead. With your proposal the release team might announce: We released on the 7th of February 2011 and freeze Wheezy one and a half year later on the 7th of October 2012. With mine they could announce: We released in February 2011 and we want about one and a half year between a releases and the following freeze, so we freeze in fall 2012. My rationale for the above is simple: *road maps*. Each team and individual developer should be able to define their own road maps very early in a release cycle. Doing so will help teams in planning and splitting work. Both would address the roadmap issue. I don't agree with this. You can do _a lot_ in 3 months. So saying fall leaves a big uncertainty in terms of roadmap. Also when you consider a kernel that comes out every 3-4 months, it means you might target an older version than what you really need due to this uncertainty. We don't need a firm date but the uncertainty should not be bigger than a month IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404070550.gl21...@rivendell.home.ouaza.com
Re: time based freezes
On Mon, Apr 4, 2011 at 09:05:50 +0200, Raphael Hertzog wrote: I don't agree with this. You can do _a lot_ in 3 months. So saying fall leaves a big uncertainty in terms of roadmap. And you know two years in advance exactly what you'll have done and what you'll want to do for the next three months? I somehow doubt that. And if I'm wrong, you can use the three months you have on your hands to polish your packages (and everybody else's). Maybe that way the freeze can be less than 6 months. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404081507.gc3...@radis.liafa.jussieu.fr
Re: time based freezes
Hello, 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 [1]. 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. Many greetings Steffen [1] http://cut.debian.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9988af.9020...@gmx.de
Re: time based freezes
On Mon, Apr 04, 2011 at 10:15:07AM +0200, Julien Cristau wrote: On Mon, Apr 4, 2011 at 09:05:50 +0200, Raphael Hertzog wrote: I don't agree with this. You can do _a lot_ in 3 months. So saying fall leaves a big uncertainty in terms of roadmap. And you know two years in advance exactly what you'll have done and what you'll want to do for the next three months? I somehow doubt that. And if I'm wrong, you can use the three months you have on your hands to polish your packages (and everybody else's). Maybe that way the freeze can be less than 6 months. Some people work to a plan from one release to the next (and I congratulate them for managing!) but I think a *lot* of the minor work and QA work that goes on is less coordinated or organised than that, with sporadic bits of work towards a goal in fits and starts as people work around real life commitments, followed by a short-term coordinated push to finish off work before a concrete freeze date, nearer the time. A worked example: I might have some vague goals as to what I would like to achieve in Debian for the next release, immediately following the previous release (i.e., now). But I have no idea when the release will happen, nor what else will happen in my life over the next 2+ years. So, we make some loose commitments and begin work on things. At some point after that, I'll get a mail telling me we're freezing in a month, or two months (or whatever), on date X. At this point, the release is concrete, my goals are either plausible or not, and I will be much more organised in setting aside time for Debian and polishing off my packages and ambitions for the release. (and thus I was totally scuppered for Squeeze). So if a vague freeze date (such as Fall 2011) is all we get now, we still need a firmer *future* date, nearer the time (e.g., Freeze on Halloween, announced late August), to allow this sort of work cycle to happen. Of course, if we had more predictable freeze or release cycles from the beginning, my work patterns might be different. It's a chaotic system, with each of us adapting to the current environment :-) -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404094225.gb14...@deckard.alcopop.org
Re: time based freezes
On Mon, Apr 4, 2011 at 10:42:25 +0100, Jon Dowland wrote: So if a vague freeze date (such as Fall 2011) is all we get now, we still need a firmer *future* date, nearer the time (e.g., Freeze on Halloween, announced late August), to allow this sort of work cycle to happen. I think that was part of what Carsten was saying. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404100101.gl3...@radis.liafa.jussieu.fr
Re: time based freezes
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: The release team did again a great job the past release cycle and managed to release again a version Debian can be proud of :) There were of course things that could be done even better next time, but handling such a enormous task without such issues seems to be impossible. The release team has done good work during the freeze. However, I cannot agree with the overall assessment of this release cycle. The announcement of time-based freezes, followed by the rapid retraction and further discussion, was farcical. The apparent result was that no-one really believed in any stated freeze date, and many packages were unready when the freeze really did begin. One thing that the release team already is improving is communication, [...] I do agree with this. I have no complaints about communication during the freeze. By the way, as a member of the kernel team I was consulted directly by the release team regarding readiness of the Linux kernel packages before some of the release decisions. I appreciate that but I believe that consultation should be opened to the entire developer base before any final decisions. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105048.gg2...@decadent.org.uk
Re: time based freezes
I agree with Stefano, pretty much... On Sun, 03 Apr 2011 at 18:15:52 +0200, Stefano Zacchiroli wrote: I believe we need time based freezes. Even more radically, I believe we need to know the freeze date as soon as possible, e.g. no later than a couple of weeks after the preceding release. (Obviously, transitioning to time based freezes warrant exceptions to the rule.) Telepathy does a stable-branch of each major component not long before each GNOME release, so every 6 months. In the absence of a preannounced freeze date, we basically need to only release stable-branch versions to unstable (with development versions in experimental), which reduces the ability to get real-world testing on the features added by the development branch, and find/fix the bugs before declaring it stable; chicken/egg? With a preannounced freeze date, we'd be able to push many of our development versions into unstable/testing (reserving experimental for only riskier changes), and become more cautious when we get within 6 months of the freeze date. It'd be tempting to say early testing? That's what (Fedora|Gentoo|Arch) users are for, but I don't think that's a sustainable approach; finding bugs is one of the ways in which we (should) help our upstreams. (When I say development versions, I mean upstream release with new features rather than random snapshot which might even work, obviously.) The next question is then what does freeze means. Does it mean that automatic transition to testing stops automatically at freeze date, or rather that no new transitions are accepted anymore (which IIRC has been proposed before). For the squeeze freeze, all packages that were in unstable on freeze day were pre-approved for the usual time-based migration (by the RT adding a large initial number of hints), and the RT had a relaxed policy for freeze-exception requests for a while. If that's not too much work to do again, it seems a good compromise? S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404110342.gb11...@reptile.pseudorandom.co.uk
Re: time based freezes
[Stefano Zacchiroli, 2011-04-03] Road maps +1 no, I cannot fix upload (without waiting for sponsoree who has a list of things to learn/fix) 10+ RFS packages (postponed mostly due to packaging bugs), deal with increased number of normal RFS mails (I was working on improving the package for last few weeks, please upload it now because the freeze will happen this week), scan thru 500+ team packages (to check if every transition is done or to upload new upstream version that fixes annoying bugs or simply to clear team's RFS list / upload UNRELEASED fixes), complete transitions (which can take some time, even for small packages like sqlalchemy¹, not even mentioning PITA python-defaults transitions²)... in one day/week/month (even with soft freeze for the next month) [¹] which never were announced to release managers (and never will most probably) [²] hint: python2.5 in Squeeze Strict date +1 most of the work is done by our upstreams, and by simply telling them we'll freeze PICK_YOUR_MONTH every even/odd year will (in the long term) improve quality of Debian *a lot* more than choosing a random^Wperfect (and different) date for every release cycle (and not announcing it to upstream authors *at all*), IMHO -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404111533.gc28...@piotro.eu
Re: time based freezes
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: One thing that the release team already is improving is communication, [snip] The other thing that has potential to be improved is the freezing. [snip] I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. Cheers, Neil -- Maulkin Damned Inselaffen. Oh, wait, that's me. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404160509.ga46...@feta.halon.org.uk
Re: time based freezes
On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: One thing that the release team already is improving is communication, [snip] The other thing that has potential to be improved is the freezing. [snip] I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104041212.10313.deb...@kitterman.com
Re: time based freezes
On Mon, 2011-04-04 at 12:12 -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Unless you're counting the d-d-a mail, Neil didn't start the thread; in fact, as far as I can see, it's his first post to it - the time based freezes thread in reply to the d-d-a mail was started by Zack. fwiw, the d-d-a mail said: The beginning of a release cycle seems the ideal time for that discussion and we hope to be in a position to start it after processing the results of the retrospective. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301949141.23878.263.ca...@hathi.jungle.funky-badger.org
Re: time based freezes
Adam D. Barratt a...@adam-barratt.org.uk wrote: On Mon, 2011-04-04 at 12:12 -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Unless you're counting the d-d-a mail, Neil didn't start the thread; in fact, as far as I can see, it's his first post to it - the time based freezes thread in reply to the d-d-a mail was started by Zack. fwiw, the d-d-a mail said: The beginning of a release cycle seems the ideal time for that discussion and we hope to be in a position to start it after processing the results of the retrospective. Debian-devel seems like a reasonable place to be discussing how Debian development should be structured. Yes, that is the message to which I referred. It seems equally reasonable to me for follow-up discussion of a message to debian-devel-announce would occur on debian-devel, particularly when the message doesn't specify an alternate venue. So I still find that on odd reply to the thread. It doesn't seem particularly consistent with the improved communication I've heard the release team is doing these days. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/28670ab5-28a8-4211-9b69-abcfbbdd8...@email.android.com
