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
[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
[ 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
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
[ 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
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
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.
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
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
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)
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
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
* 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
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
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
+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
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
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
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
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
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
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
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
[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
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
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
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
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
On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
Time based freezes
--
We're aware that there is an outstanding discussion to be had about time
based freezes (note: _not_ time based releases).
The beginning of a release cycle seems the ideal time
29 matches
Mail list logo
