[Abou Al Montacir, 2011-05-04]
> On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote:
>
> > On 2011-04-24, Stefano Zacchiroli 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
> > re
On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote:
> On 2011-04-24, Stefano Zacchiroli 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 wh
On 2011-04-24, Stefano Zacchiroli 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.or
[ 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.
> I would love if we can summarize the above part by
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
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 r
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
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
[ 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 ab
On 04/05/2011 06:55 PM, Martin Wuertele wrote:
> * Bernd Zeimetz [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 Wed, Apr 6, 2011 at 1:14 AM, Margarita Manterola
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
On Mon, Apr 4, 2011 at 3:38 AM, Carsten Hey 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
* Bernd Zeimetz [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
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 ev
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
"Adam D. Barratt" 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
>comment
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 hav
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]
>
>
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 de
[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
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. (O
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 tas
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 tha
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 advanc
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
heteroge
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 thre
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
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 re
28 matches
Mail list logo
