[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QA @ KDE
From:       Thiago Macieira <thiago () kde ! org>
Date:       2005-10-12 22:00:51
Message-ID: 200510121901.01472.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Bojan wrote:
>which is all useful.  But I couldn't find much info on the KDE release
>cycle.  For example, since version 3.4, development for 3.5 has been
>under way.  Now 3.5 is in feature freeze.   What exactly does that
>mean? 

It means "no new features". You can also understand it as "bugfixing only 
and finishing what you started".

>How and who decides when this happens? 

The Release Dude or Team posts to kde-core-devel the initial plan. People 
comment, say how long they need, etc. and a date is set. Generally, we 
look towards one release every 6 months or so.

>Is there some sort of  
>standard cycle/process/timeline that happens for each release.  

Yes:
Phase 1: unrestricted development
Phase 2: feature freeze
Phase 3: message freeze (no new user-visible strings or changes to them)
Phase 4: deep freeze (only important bugfixing)

We generally release an alpha just before feature freeze and the beta 
happens close to the message freeze. We have generally 2 or 3 betas, 
depending on the number of unfinished features; then we have 1 or more 
Release Candidates, which depend on the number of open critical bugs.

>The 
>way I understand, usually 3.x release are minor releases, and 3.x.y
>releases are patch releases that fix stuff in the .X brach. Am I
>correct in saying this? Is there similar type of "feature-freeze"
>thing for the patch releases.

Yes, that's exactly it. Once into feature and message freeze, a release 
never leaves it. So KDE 3.5 is forever frozen now: only bugfixing can 
happen on 3.5.1, 3.5.2, etc.

New development happens only on /trunk (which will be KDE 4).

>What's the protocol/timeline for the .Y 
>releases, if there is one?  Like how is it decided when a 3.4.y
>version should be released?

The .1 generally happens one month after the .0 release. The next ones are 
released if:

a) we find a critical bug to solve
b) we find a security issue that must be solved
c) we reach an important number of general bugfixing that would benefit 
our users to have a new release

It's not dependent on time, but c) happens generally every 3 months or so 
(3.4.1 was released in April; 3.4.2 was in late July; 3.4.3 will happen 
in October)

>AFAIK, when somone w/o SVN access makes a patch for an app, the
>standard thing to do is either:
> - mail it to the app's author/maintainer.
> - mail it through the appropriate mailing list (ed. KOffice mailing
> list) 
> - if appropriate mail it though this list. 
>
>Is this correct?

Yes, in all accounts.

>Is there some sort of standard thing that the author should do with a
>patch, before commiting it?  I think usually the author checks it
>over, and applies it to his/her local code, and tests it.  If he/she
>is happy, commit?  Is this correct?

Correct.

>I am also planning to talk about some other things related to QA and
>testing @ KDE.  For example I can mention the scripts KOffice guys use
>to check code and things.  I think it's neat.  Then there is Valgrind,
>and that is something really cool.  Anyone got any other specific
>ideas I can talk about, that I am not aware of maybe?

There's also:

unit tests (being implemented all over KDE now with QtTestLib)
khtmltests (regression tests on webpages)

>I don't think it will be hard to do well on this, and I think I should
>be able to make it interesting.  Especially since not a lot of people
>around here know about KDE, which is really shameful considering it's
>a CS department.  But I guess it is eastern Canada, and also our
>default DE is Gnome in our Linux labs.  So maybe I'll be able to put
>out there some awareness there about KDE.

I wish you good luck.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.

[Attachment #5 (application/pgp-signature)]

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<


[prev in list] [next in list] [prev in thread] [next in thread]