Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-20 Thread Tom Albers
Op woensdag 20 februari 2008 05:13 schreef u:
> On Mon, Feb 18, 2008 at 03:47:30PM +0100, Dirk Mueller wrote:
> > On Wednesday 13 February 2008, Sebastian Kuegler wrote:
> > 
> > > My impression (and the one of other, I gathered that from past 
> > > discussions)
> > > is that two months to stabilise a 4.x release should really be enough. 
> > > More
> > > time in freeze is not a good thing.
> > 
> > I disagree. 2 months is not enough. you need one month alone to tell the 
> > developers that it is time to head up for a release and at least another 
> > month to iron out the bugs.
> > 
> >  But then again, I'm not the one who wants to release so early, I want to 
> > release at a later point anyway (to be in sync with other releases of big 
> > projects). 
> > 
> > Greetings,
> > Dirk
> > 
> 
> Just for the record, I actually prefer September myself, but I'm just
> the messenger in this case. If we can come to a different consensus on
> when we actually want to release, then I (or somebody else) can update
> the schedule.

No, we decided for July and announced that everywhere. The objections should 
have raised during that discussion. If you were on vacation, bad luck this time 
;-)

That does not mean we can not change anything in the future anymore. When we 
make the schedule for 4.2, we can shift two months /if/ there is concensus on 
that idea.

I do not see an urgent reason to change the schedule for 4.1 And, just for 
the record, I don't like the idea of making sure 4.1 slips two months to get to 
that schedule.
-- 
Tom Albers  
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-19 Thread Matt Rogers
On Mon, Feb 18, 2008 at 03:47:30PM +0100, Dirk Mueller wrote:
> On Wednesday 13 February 2008, Sebastian Kuegler wrote:
> 
> > My impression (and the one of other, I gathered that from past discussions)
> > is that two months to stabilise a 4.x release should really be enough. More
> > time in freeze is not a good thing.
> 
> I disagree. 2 months is not enough. you need one month alone to tell the 
> developers that it is time to head up for a release and at least another 
> month to iron out the bugs.
> 
>  But then again, I'm not the one who wants to release so early, I want to 
> release at a later point anyway (to be in sync with other releases of big 
> projects). 
> 
> Greetings,
> Dirk
> 

Just for the record, I actually prefer September myself, but I'm just
the messenger in this case. If we can come to a different consensus on
when we actually want to release, then I (or somebody else) can update
the schedule.

IOW, Don't shoot me! I'm just the messenger. :)
--
Matt

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-18 Thread Dirk Mueller
On Wednesday 13 February 2008, Sebastian Kuegler wrote:

> My impression (and the one of other, I gathered that from past discussions)
> is that two months to stabilise a 4.x release should really be enough. More
> time in freeze is not a good thing.

I disagree. 2 months is not enough. you need one month alone to tell the 
developers that it is time to head up for a release and at least another 
month to iron out the bugs.

 But then again, I'm not the one who wants to release so early, I want to 
release at a later point anyway (to be in sync with other releases of big 
projects). 

Greetings,
Dirk



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-14 Thread Torsten Rahn
> On Wednesday 13 February 2008 14:43:05 Torsten Rahn wrote:
> > I think that the points of times for freezes and their definitions as
> > suggested by Matt are quite good actually. I just feel that people won't
> > get into release mode this fast, so we need to have a "real" alpha
> > release in March first (and basically call your Alpha1 a Beta 1, etc.).
> My impression (and the one of other, I gathered that from past discussions)
> is that two months to stabilise a 4.x release should really be enough. More
> time in freeze is not a good thing.

Well, if you read my last mail closely you'll realize that I didn't suggest to 
change anything about the freeze milestones that Matt has suggested. However 
my suggestion was to have another release in March to get people into release 
mode early and to give users a chance to test new stuff early to be able to 
provide feedback and to give developers time to adjust to the feedback. With 
the current schedule I don't see this chance. 
Looking back it has always taken considerable time to get people to realize 
that now it's time to stop work on new stuff and to start work on bugfixing 
and polishing things. An early alpha would provide this clue.
While with the development of LiveCDs it's much easier for people to test and 
follow KDE's  progress it still takes a release to get the public's attention 
and the awareness of testers that "this development state" is supposed to be 
where the software is about to head and that the testers better give feedback 
now if they feel that stuff is wrong instead of hesitating.
Looking back at e.g. the KDE 2.1 schedule which worked really well I notice 
that the first Beta there happened exactly 2.5 months before the actual 
release (i.e. December 18th, Beta 2 was on January 31st and KDE  2.1 on 
February 26th. So far the KDE 2.1 has been the most fast tracked release in 
KDE's history and given that KDE has grown quite a bit I'd consider it a true 
challenge to release within such a short time frame again while still 
delivering a quality release.

-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-14 Thread Albert Astals Cid
A Dimecres 13 Febrer 2008, Dirk Mueller va escriure:
> On Saturday 26 January 2008, Matt Rogers wrote:
> > I've posted a new schedule on
> > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedu
> >le that should work as the nearly final release schedule.
> >
> > Feedback is appreciated.
>
> I have a couple of questions:
>
> a) "Binary compatibility is not required". what do you mean by that? you're
> saying that newly added features do not have to be binary compatible?
> you're saying that binary incompatible changes are allowed in kdelibs?

For me it means, it is not required to maintain binary compatibility of new 
classes added in the 4.0->4.1 timeframe.

Albert

>
> b) Why a hard feature freeze for alpha1, e.g. before any user announced
> release? that doesn't make sense. we should have alpha releases that
> attract user attention and be able to react to the feedback, which often
> means changing or implementing new features. imho the feature freeze
> shouldn't be before beta1 or beta2.
>
> c) Why a message freeze before beta1? bugfixes often require message
> changes.

And translators often need time to translate things. And we are quite kind 
guaranteeing exceptions.

Albert

>
> d) it is still a mis-aligned schedule, however I'm not going to complai too
> loudly about it given that it might slip by one month and then be aligned
> :)
>
> e) I like the no-new-artwork freeze.
>
> Greetings,
> Dirk
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-13 Thread Sebastian Kuegler
On Wednesday 13 February 2008 14:43:05 Torsten Rahn wrote:
> I mostly agree with Dirk.
>
> Personally I think that the current proposed schedule is unrealistic in
> terms of timescales. Having 2.5 months between an Alpha Release and a Final
> Release simply won't work.
>
> I'd suggest to have an Alpha Release  in March, the first Beta at the end
> of April, the second Beta at the end of May and the Release Candidate at
> the end of June / begin of July. This would make sure that people get into
> release mode early again (otherwise we'll have too many construction sites
> still two months before the actual release).
>
> I think that the points of times for freezes and their definitions as
> suggested by Matt are quite good actually. I just feel that people won't
> get into release mode this fast, so we need to have a "real" alpha release
> in March first (and basically call your Alpha1 a Beta 1, etc.).

My impression (and the one of other, I gathered that from past discussions) is 
that two months to stabilise a 4.x release should really be enough. More time 
in freeze is not a good thing.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-13 Thread Torsten Rahn

Hi,

I mostly agree with Dirk. 

Personally I think that the current proposed schedule is unrealistic in terms 
of timescales. Having 2.5 months between an Alpha Release and a Final Release 
simply won't work.

I'd suggest to have an Alpha Release  in March, the first Beta at the end of 
April, the second Beta at the end of May and the Release Candidate at the end 
of June / begin of July. This would make sure that people get into release 
mode early again (otherwise we'll have too many construction sites still two 
months before the actual release).

I think that the points of times for freezes and their definitions as 
suggested by Matt are quite good actually. I just feel that people won't get 
into release mode this fast, so we need to have a "real" alpha release in 
March first (and basically call your Alpha1 a Beta 1, etc.).  

Regards,

Torsten


> On Tuesday 12 February 2008 19:01:10 you wrote:
> > On Saturday 26 January 2008, Matt Rogers wrote:
> > > I've posted a new schedule on
> > > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Sche
> > >du le that should work as the nearly final release schedule.
> > >
> > > Feedback is appreciated.
> >
> > I have a couple of questions:
> >
> > a) "Binary compatibility is not required". what do you mean by that?
> > you're saying that newly added features do not have to be binary
> > compatible? you're saying that binary incompatible changes are allowed in
> > kdelibs?
>
> That was something I ripped from the 3.5.x release schedule. It's intent is
> to say that BC will not be guaranteed for new API.
>
> > b) Why a hard feature freeze for alpha1, e.g. before any user announced
> > release? that doesn't make sense. we should have alpha releases that
> > attract user attention and be able to react to the feedback, which often
> > means changing or implementing new features. imho the feature freeze
> > shouldn't be before beta1 or beta2.
>
> This is, again, something I did based on the 3.5 schedule. We can push the
> feature freeze off until later. No problems for me.
>
> > c) Why a message freeze before beta1? bugfixes often require message
> > changes.
>
> hehe, ok, so maybe basing my wording on the 3.5.x release schedule wording
> wasn't such a good idea. When do you think it would be a good idea to put a
> message freeze in place? RC 1? I don't particularly have a preference.
>
> > d) it is still a mis-aligned schedule, however I'm not going to complai
> > too loudly about it given that it might slip by one month and then be
> > aligned
> >
> > :)
> >
> > e) I like the no-new-artwork freeze.
> >
> > Greetings,
> > Dirk
>
> Thanks for the feedback. I'll work on making the changes. Should be done by
> the end of the week.

-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-12 Thread Matt Rogers
On Tuesday 12 February 2008 19:01:10 you wrote:
> On Saturday 26 January 2008, Matt Rogers wrote:
> > I've posted a new schedule on
> > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedu
> >le that should work as the nearly final release schedule.
> >
> > Feedback is appreciated.
>
> I have a couple of questions:
>
> a) "Binary compatibility is not required". what do you mean by that? you're
> saying that newly added features do not have to be binary compatible?
> you're saying that binary incompatible changes are allowed in kdelibs?
>

That was something I ripped from the 3.5.x release schedule. It's intent is to 
say that BC will not be guaranteed for new API. 

> b) Why a hard feature freeze for alpha1, e.g. before any user announced
> release? that doesn't make sense. we should have alpha releases that
> attract user attention and be able to react to the feedback, which often
> means changing or implementing new features. imho the feature freeze
> shouldn't be before beta1 or beta2.
>

This is, again, something I did based on the 3.5 schedule. We can push the 
feature freeze off until later. No problems for me.

> c) Why a message freeze before beta1? bugfixes often require message
> changes.
>

hehe, ok, so maybe basing my wording on the 3.5.x release schedule wording 
wasn't such a good idea. When do you think it would be a good idea to put a 
message freeze in place? RC 1? I don't particularly have a preference.

> d) it is still a mis-aligned schedule, however I'm not going to complai too
> loudly about it given that it might slip by one month and then be aligned
> :)
>

> e) I like the no-new-artwork freeze.
>
> Greetings,
> Dirk

Thanks for the feedback. I'll work on making the changes. Should be done by 
the end of the week.
--
Matt
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-02-12 Thread Dirk Mueller
On Saturday 26 January 2008, Matt Rogers wrote:

> I've posted a new schedule on
> http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedule
> that should work as the nearly final release schedule.
>
> Feedback is appreciated.

I have a couple of questions: 

a) "Binary compatibility is not required". what do you mean by that? you're 
saying that newly added features do not have to be binary compatible? you're 
saying that binary incompatible changes are allowed in kdelibs?

b) Why a hard feature freeze for alpha1, e.g. before any user announced 
release? that doesn't make sense. we should have alpha releases that attract 
user attention and be able to react to the feedback, which often means 
changing or implementing new features. imho the feature freeze shouldn't be 
before beta1 or beta2. 

c) Why a message freeze before beta1? bugfixes often require message changes. 

d) it is still a mis-aligned schedule, however I'm not going to complai too 
loudly about it given that it might slip by one month and then be aligned :)

e) I like the no-new-artwork freeze. 

Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-01-26 Thread Matt Rogers
On Saturday 26 January 2008 06:52:14 Allen Winter wrote:
> On Friday 25 January 2008 23:28:37 Matt Rogers wrote:
> > Hi,
> >
> > Taking into account the feedback received in the previous release
> > schedule, I've posted a new schedule on
> > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedu
> >le that should work as the nearly final release schedule.
> >
> > Feedback is appreciated.
>
> Excellent.
>
> Yikes! We need a Planned Features doc.
> How? Wiki, XML??
>

I thought there was a wikipedia plugin that took our normal xml and converted 
it to wiki format, so that might work. Otherwise, wiki sounds ok to me.
--
Matt

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Initial revision of KDE 4.1 schedule available on Techbase

2008-01-26 Thread Allen Winter
On Friday 25 January 2008 23:28:37 Matt Rogers wrote:
> Hi,
>
> Taking into account the feedback received in the previous release schedule,
> I've posted a new schedule on
> http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedule
> that should work as the nearly final release schedule.
>
> Feedback is appreciated.
>
Excellent.

Yikes! We need a Planned Features doc.
How? Wiki, XML??



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Initial revision of KDE 4.1 schedule available on Techbase

2008-01-25 Thread Matt Rogers
Hi,

Taking into account the feedback received in the previous release schedule, 
I've posted a new schedule on  
http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Schedule 
that should work as the nearly final release schedule.

Feedback is appreciated.

Thanks
--
Matt


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team