Dirk Mueller | 1 Sep 02:31
Picon
Favicon

Re: Release dates/nomenclature

On Friday, 31. August 2007, Allen Winter wrote:

> > OK, I'll do some date-squeezing and move things back two weeks.
> > How does December 12th sound?
> Countering my proprosal, how about Dec 6?
> We can make the Beta4 only 2 weeks long.

what is part of the December release (12th or 6th doesn't count)?

I think if we delay the KDE "desktop" release into december (which I agree 
with), then we should release libs earlier. I think it is possible to release 
the libs by the end of october like planned. 

Releasing the libs earlier has two advantages: 

a) it is possible to add new features needed for apps without risking binary 
compatibility burdens becase we do a mistake last minute

b) we somehow meet our deadline. We're slipping already bad, and slipping has 
to stop. 

c) 3rd party applications who have already ported (digikam, amarok, ktorrent, 
there are probably many others) have something to require and build on. it 
wouldn't be bad for apps to be available before the desktop release either. 

Release date juggling aside, I'm quite concerned about the recent trend of 
blogging how bad KDE4 is. It is time to advertise that we have to eat our own 
dogfood, and that KDE4 will stay a vision forever if developers don't start 
to use it and fix the glaring bugs. I know that part of the pain is that 
there is no stable mail client for KDE4, and no IRC client at all. These are 
(Continue reading)

Sebastian Kügler | 1 Sep 02:49
Picon
Favicon
Gravatar

Re: Release dates/nomenclature

On Saturday 01 September 2007 02:31:56 Dirk Mueller wrote:
> On Friday, 31. August 2007, Allen Winter wrote:
> > > OK, I'll do some date-squeezing and move things back two weeks.
> > > How does December 12th sound?
> >
> > Countering my proprosal, how about Dec 6?
> > We can make the Beta4 only 2 weeks long.
>
> what is part of the December release (12th or 6th doesn't count)?
>
> I think if we delay the KDE "desktop" release into december (which I agree
> with), then we should release libs earlier. I think it is possible to
> release the libs by the end of october like planned.

+1. Sounds very good, also from my POV. I do not have much insight how 
realistic this is for kdelibs, I'll leave that to you.

> This is a much more important topic than juggling tagging dates around. If
> we continue like that, we loose the bugfixers because there is no point in
> fixing KDE3.x bugs anymore, and we loose the app code monkeys, because
> there is no foundation they could base their work on.

We should also have a collection of things we need fixed before the release, 
that makes it easier for people to pick something up and it gives a better 
idea of our progress. I think Allen has such a list for PIM, that'd be a good 
start, Dirk's "fix kmail and konversation" are another two points. A "KDE 4.0 
showstopper list on bugzilla would already do, or maybe a collection on 
techbase. There is also the todo file on developer.kde.org (which should 
probably move to techbase anyway). 

(Continue reading)

Kevin Ottens | 1 Sep 12:28
Picon
Favicon

Re: Release dates/nomenclature

Le samedi 01 septembre 2007, Sebastian Kügler a écrit :
> On Friday 31 August 2007 19:17:31 Allen Winter wrote:
> > Countering my proprosal, how about Dec 6?
> > We can make the Beta4 only 2 weeks long.
>
> That makes it possible to release before the christmas vacation of others
> as well. End of December is about the worst release date I could think of,
> so I'm glad Dirk is not available then. :-)
>
> So let's aim for a release on my mother's birthday, 13th December.

I vote for 6th December, it's my father birthday.

Sorry... couldn't resist.

Regards.
--

-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
Sebastian Kügler | 1 Sep 15:57
Picon
Favicon
Gravatar

Re: Release dates/nomenclature -- Revised proposal

On Saturday 01 September 2007 12:28:31 Kevin Ottens wrote:
> > So let's aim for a release on my mother's birthday, 13th December.
>
> I vote for 6th December, it's my father birthday.

That would be the tagging date then :-)

How about this, then. It's mainly what Dirk and Allen proposed.

Thursday, 6 September: Release Beta2 (already tagged)

September 24, 2007: Tagging Beta3 (This is a Monday, does that make sense?)
October 2 2007: Release Beta3

October 22, 2007: Tagging Beta4 (Again, a Monday)
October 30 2007: Release Beta4 (Beta4 is only 2 weeks long)

November 5, 2007: Total Release Freeze (a Monday)

November 13 2007: Tagging Release Candidate 1 (move closer to the freeze?)
November 20 2007: Release Release Candidate 1

November 21 2007: Tagging Release Candidate 2 (to close to -rc1?)
November 27 2007: Release Release Candidate 2

December 6  2007: Tagging final Release
December 13 2007: Targeted Release Date

* We should probably move the tagging and release for the following betas 
  closer to each other, maybe tagging on Fridays, releasing on Tuesdays? Is 
(Continue reading)

Allen Winter | 1 Sep 17:11
Picon
Favicon

Re: Release dates/nomenclature


> 
> I can only say that I tried to switch my development desktop to KDE4, and it 
> is still very painful, as barely anything works, and I'm busy compiling after 
> krazy check changes instead of getting things done. This has to stop! It 
> takes me almost two work days go get things recompiled, and I cannot do 
> something during that time on it. 
> 

How about a policy that says only non-BIC bugfixes are allowed on non-Mondays?

IOW: 
 BC bug fixes -> any day
 all other changes -> Monday only

This policy would cover kdesupport, kdelibs, and kdepimlibs.

Comments?
-Allen

 
Matt Rogers | 1 Sep 17:30
Picon
Favicon

Re: Release dates/nomenclature


On Sep 1, 2007, at 10:11 AM, Allen Winter wrote:

>
>>
>> I can only say that I tried to switch my development desktop to  
>> KDE4, and it
>> is still very painful, as barely anything works, and I'm busy  
>> compiling after
>> krazy check changes instead of getting things done. This has to  
>> stop! It
>> takes me almost two work days go get things recompiled, and I  
>> cannot do
>> something during that time on it.
>>
>
> How about a policy that says only non-BIC bugfixes are allowed on  
> non-Mondays?
>
> IOW:
>  BC bug fixes -> any day
>  all other changes -> Monday only
>
> This policy would cover kdesupport, kdelibs, and kdepimlibs.
>
> Comments?
> -Allen
>

That's no different than what we have now. The problem is that people  
(Continue reading)

Thomas Zander | 1 Sep 17:45
Picon
Favicon

Re: Release dates/nomenclature

On Saturday 01 September 2007 17:30:34 Matt Rogers wrote:
> That's no different than what we have now. The problem is that people
> seem to be too interested in fixing Krazy issues rather than fixing
> actual bugs. How do you propose we get them interested in fixing real
> bugs?

Stop running the not-so-interresting krazy tests? ;)

--

-- 
Thomas Zander
Allen Winter | 1 Sep 23:29
Picon
Favicon

Re: Release dates/nomenclature

On Saturday 01 September 2007 11:45:07 am Thomas Zander wrote:
> On Saturday 01 September 2007 17:30:34 Matt Rogers wrote:
> > That's no different than what we have now. The problem is that people
> > seem to be too interested in fixing Krazy issues rather than fixing
> > actual bugs. How do you propose we get them interested in fixing real
> > bugs?
> 
> Stop running the not-so-interresting krazy tests? ;)
> 
We can pull the plug on the EBN entirely.
I don't think that will help get bugs fixed, but at least
it will reduce the number unneeded re-compiles.

I had no idea Krazy/EBN was doing such so harm to the project.
That was not the intention.

-Allen

Matt Rogers | 2 Sep 00:55
Picon
Favicon

Re: Release dates/nomenclature


On Sep 1, 2007, at 4:29 PM, Allen Winter wrote:

> On Saturday 01 September 2007 11:45:07 am Thomas Zander wrote:
>> On Saturday 01 September 2007 17:30:34 Matt Rogers wrote:
>>> That's no different than what we have now. The problem is that  
>>> people
>>> seem to be too interested in fixing Krazy issues rather than fixing
>>> actual bugs. How do you propose we get them interested in fixing  
>>> real
>>> bugs?
>>
>> Stop running the not-so-interresting krazy tests? ;)
>>
> We can pull the plug on the EBN entirely.
> I don't think that will help get bugs fixed, but at least
> it will reduce the number unneeded re-compiles.
>
> I had no idea Krazy/EBN was doing such so harm to the project.
> That was not the intention.
>
> -Allen

I don't think it does that much harm to the project. In fact, I would  
consider the EBN a good thing. However, it may be a good idea to  
suspend it temporarily. Perhaps the number of recompiles caused by  
people not fixing krazy issues will allow some of us to be more  
productive. It may also spur some of the newer developers to work on  
other things besides fixing Krazy issues, which in the grand scheme  
of things, are less important the closer we get to a freeze. (IMHO)
(Continue reading)

Allen Winter | 2 Sep 22:39
Picon
Favicon

Re: Release dates/nomenclature

On Saturday 01 September 2007 6:55:57 pm Matt Rogers wrote:
> 
> On Sep 1, 2007, at 4:29 PM, Allen Winter wrote:
> 
> > On Saturday 01 September 2007 11:45:07 am Thomas Zander wrote:
> >> On Saturday 01 September 2007 17:30:34 Matt Rogers wrote:
> >>> That's no different than what we have now. The problem is that
> >>> people
> >>> seem to be too interested in fixing Krazy issues rather than fixing
> >>> actual bugs. How do you propose we get them interested in fixing
> >>> real
> >>> bugs?
> >>
> >> Stop running the not-so-interresting krazy tests? ;)
> >>
> > We can pull the plug on the EBN entirely.
> > I don't think that will help get bugs fixed, but at least
> > it will reduce the number unneeded re-compiles.
> >
> > I had no idea Krazy/EBN was doing such so harm to the project.
> > That was not the intention.
> >
> > -Allen
> 
> I don't think it does that much harm to the project. In fact, I would
> consider the EBN a good thing. However, it may be a good idea to
> suspend it temporarily. Perhaps the number of recompiles caused by
> people not fixing krazy issues will allow some of us to be more
> productive. It may also spur some of the newer developers to work on
> other things besides fixing Krazy issues, which in the grand scheme
(Continue reading)


Gmane