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

List:       kde-devel
Subject:    QA @ KDE
From:       Bojan <dbojan () gmail ! com>
Date:       2005-10-12 2:44:21
Message-ID: d22f9b370510111944u1d9981e4q75bb86788d142520 () mail ! gmail ! com
[Download RAW message or body]

Hello everyone,

This is a somewhat quality related question, but it's for research, so
I am posting it here so hopefully I can get as much feedback as I can.

I am taking a course in Software Quality and Project Management.  As
part of the course we have to create a poster and presentation, and
write up a paper on a topic.  There are varing topics, and one is
"Quality assurance at <insert company or organization here>"  I was
thinking of doing this on KDE.  I am just doing some research, and I
was hoping I could get a few things cleared up, or maybe directed to
somewhere where I can find the answers.  I have tried to look for
stuff myself already.

Obviously the main part of QA is the bugzilla, and I think can talk a
lot about that. I found lots of useful info at quality.kde.org and the
wiki.

I also think the SVN is an importnat part of software quality in KDE,
however I can't seem to find much information on that.  I can find on
how SVN is orginized, and what branches mean, and the related info,
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? How and who decides when this happens? Is there some sort of
standard cycle/process/timeline that happens for each release.  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. 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?

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?

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?

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?

If you are interested in greater detail what the project is about
there is a PDF describing it here:

http://www.ece.unb.ca/Courses/SWE4103/DM/Seminars%20and%20Posters/Poster%20Instructions.pdf

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.

Thank you all,

Bojan
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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