--Boundary-02=_1Nr49damut4HuI3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: signed data Content-Disposition: inline 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@mail.com ICQ UIN: 1967141 PGP/GPG: 0x6EF45358 Registered Linux user #65028 --Boundary-02=_1Nr49damut4HuI3 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA94rN1M/XwBW70U1gRAndjAJ4tYQ71NWFFS/UMTlQ6ucOpF7wNhACff2X4 cSl+jniQFVmBDie6mp/J5q0= =CTcT -----END PGP SIGNATURE----- --Boundary-02=_1Nr49damut4HuI3--