KDE 3.2 release cycle

[Mosfet]

Well, as I said before I don't think we necessarily have to push up the stable 
releases although CVS has been very stable for me so far. As was noted many 
bugs listed on bugs.kde.org aren't crashes but other behavior that isn't 
optimal. 

I do understand that there is a lot of cool things people want to do for 
KDE3.2, especially in regards to kde-pim, and I'm all for that. What I think 
now would be good is for us to occasionally release development snapshots 
with descriptive changelogs, screenshots, etc... to show off what has been 
accomplished already. This is very hard for someone to just go ahead and do 
because the changelog - it would require developers to sit down and take a 
hour to list all the new stuff they implemented. It shouldn't just be "Merged 
Safari changes to 05/12/2003 snapshot", or something like that. It should 
actually list what that would of improved and only developers really know 
that.

The point of all this being to give the users an idea of all the progress that 
has been made up until that point. Not that they would want to actually use 
the snapshot, or that it would have all the features or even most of the 
features we want in a final release. It's more to keep users informed. As I 
said in my previous post KDE development seems slow to many users because 
they don't get much information all packaged up in one place during the 
development cycle. Weekly updates on what is going on in CVS is fine but it 
can't beat impressive changelogs listing everything from KDE3.x and CVS HEAD 
;-) People forget what happened last week - the changes need to be listed in 
one place occasionally.

And of course all this is my opinion >;-)

On Monday 12 May 2003 03:30 am, Daniel Stone wrote:
> On Mon, May 12, 2003 at 09:29:05AM +0200, Stephan Binner wrote:
> > On Sunday 11 May 2003 20:45, Stephan Kulow wrote:
> > > To my counting, there are ~2300 _confirmed_ bugs known to KDE. If you
> > > can
> >
> > From which are 470 due to khtml/kjs (no problem there to confirm much
> > more with some work, and expect that growing) and 390 are for products
> > not part of KDE release cycle atm (KOffice, KDevelop, CDRs, Boson, KBear,
> > ...). Your bug count based release schedule ("release when only 1000
> > confirmed bugs left") is totally unrealistic. And btw, nothing prevented
> > three KDE 3.1.x releases with the current amount of open critical and
> > grave bugs. You have to release.
> >
> > Either switch to a time-based or feature-based release-schedule now.
>
> I'm sorry, but this is something I cannot accept. If we start shipping
> releases based on time/features, then we're going to end up with
> something buggy. I'm sure most users would rather have something very
> nice that works, rather than something that's very very shiny and
> jam-packed full of eyecandy, that segfaults whenever you click on "Lock
> Desktop"[1].
>
> We have a responsibility to our users. There's a place for "get all the
> features and eye candy you want, but this edge bleeds". It's called CVS.
> We already have excellent infrastructure[2] for this, so I don't see the
> need to turn releases into a second CVS stream.
>
> To me, when I see kdelibs-x.x.x.tar.bz2, that says to me, "Ah, a release.
> Tested. Stable. Works". It doesn't convey to me, "Ah. Shiny. Immature. I
> gotta get me some of that". If we start releasing based on
> time/features, not stability, I can guarantee you that we will start
> losing users. The people who are that hellbent on shiny new stuff will
> grab CVS anyway. Others will just live with it.
>
> And you're ignoring another aspect: packagers.
>
> Here is the reason why my life has been hell for a while:
> daniel at nanasawa:~/debian/xfree86-svn/people/daniel/debian/patches% ls -l *
> | wc -l && wc -l * | tail -1 105
>   34998 total
>
> Now, there's a serious disincentive to package something. I'm not
> inferring that KDE will turn into something that requires 35,000 lines
> of patches (the count was 51k at one point) in its packages, but for
> every serious bug you add, you're forcing patches upon the packagers,
> and  please take my word as an ex-KDE maintainer, that it's really,
> incredibly unpleasant to deal with.
>
> The other option, of course, is more frequent releases. But if we go to
> KDE 3.2.17, and it's still buggy and woefully unstable, what's the
> point? KDE's reputation will also go to the toilet, not only with end
> users, but also with corporations (psst: kdekiosk is there for a
> reason).
>
> "The only winning move is not to play." (Or, of course, stick to
> stability-based releases).
>
> > > Beside that, I see a revised kdepim as the key feature for 3.2 and that
> > > has basicly just started. An alpha release doesn't help keeping the
> > > developer's
> >
> > Why 3.2? Is whole kdepim alpha state? Or only Kontact? Then move it to
> > 3.3.
>
> Last time I checked, kdepim was just settling down with all the
> libraries, the delineation between network/pim being sorted, etc. This
> was a while ago, but not that long so that you could call it mature now.
>
> Please, let's not go down that path. That way lies insanity.
>
> :) d
>
> [1]: kdesktop_lock segfaults when you click on Lock Desktop, but my
> checkout is old. Still, it's a very good example of why shipping based
> on time/features is utterly bogus.
> [2]: Tags, branches, separate trees ... what more can you ask for?