KDE 3.1 final tarballs

[Thiago Macieira]

Trevor Harmon wrote:
>> But I should like to say that, at this time, all developers should be more
>> interested in getting 3.1 done right rather than be doing the cool new
>> features for 3.2.
>
>I totally agree with that for the beta cycle. However, once the first
> release candidate is out, there are only a handful of bugs left, right?
> (The so-called "showstoppers", I mean.) Why should all KDE developers be
> focused on these few bugs when there are so many others to work on?
> Besides, it seems as if I'm actually prevented from fixing bugs because
> only showstopper fixes can be applied to HEAD during the RC phase.
>
>Once HEAD enters RC, I feel it should be branched to KDE_3_1_BRANCH or
>whatever the next stable release is. That way, HEAD could be opened up for
>non-showstopper bug fixes.

I think that would be too much duplicate work. For one thing, all the bugs 
fixed in the release branch would have to be merged into HEAD. Actually, all 
changes made into the release brach should be ported as well. So, we'd be 
duplicating this work.

Then, imagine you're working on HEAD and you find a showstopper bug. Do you 
know if it was introduced since the branching or if it's present in the 
release candidate? No, so you have to recompile for the branch and see if 
it's there. And only then can you fix it.

Besides, it's not like only showstopper bugs can get fixed. Showstopper bugs 
are the kind of thing that prevents an RC from becoming final. But, once that 
it's been decided there will be more RCs, you can fix other bugs that were 
found -- provided the new code doesn't introduce yet new bugs.

If you have a big bugfix to commit, you can commit it, just like you proposed. 
Except that it wouldn't be on HEAD, it would be on a branch (you're allowed 
to open branches, you know). When HEAD is cleared for new commits, new 
features, etc., just merge your branch into HEAD -- and into KDE_3_1_BRANCH.

And why should all KDE developers be focused on a handful of bugs? Because 
they are there. We don't want them to be there. And the more pair of eyes you 
have, the more likely you are to find it.

I've made my position clear, but this is actually not a real debate. This is a 
policy and a decision that only the release coordinator can make. It's up him 
to tell us whether he might be considering your option or not.

Cordially (and sleepily),
-- 
  Thiago Macieira - UFOT Registry number: 1001
 thiagom at mail.com
   ICQ UIN: 1967141  PGP/GPG: 0x6EF45358
     Registered Linux user #65028
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021126/ba0f0ac1/attachment.sig>