Regarding this issue: as several others have noticed, the tree is closed for new features. If the theme has been developed in the public SVN and previous (even ugly/unfinished) versions of the cursors were installed in the RC or betas for testing, then I would support last minute art changes until the tagging. But this was not the case, so this feature missed the freeze deadlines. This is really simple. Something was not in the release modules at the time the freeze was done, it should have to wait for the next release. There should really be no stressing about this. I (and others) have lots of artwork-only changes for themes, and they were prevented from going in and are waiting in the sidelines for the past several months. So, to be clear, let us not try to twist the interpretations of the schedule and freezes. According to the release schedule, it seems logical that this should not be allowed to go in, and Ricardo should not even ask about it (see the Phonon move to kdereview for example.) Once this basic assumption is assumed, we can argue if an exception should be allowed, and this is an entirely different line of reasoning.
Again: if we agree that new features are frozen, then we can treat this as a request for an exception, and deal with it accordingly. In this new light, I am not against granting an exception and adding the cursor theme, as the whole Oxygen was marked as somehow exempt and deemed a showstopper for release. And if you look at the bigger picture, Plasma is not subject to the freeze rules as well. Seeing that we made the *desktop* part of KDE essentially exempt from a hard freeze and some of the deadlines that apply to other modules, it is easy to see why people consider inclusion of cursors a minor thing, right? Before this creates a new schism: we had our reasons for doing this, it is a done deal, and appears to be paying off. I do not want to start a Plasma discussion here. So there is a de-facto situation: some modules are in freeze. Some are not. We can elaborate over the meaning of deep freeze, soft freeze, melting freeze, etc. But this basic situation is in place, and it is causing this tension if we do not understand or deal with it clearly. What I think we will see when we try to learn from this situation in the future is that we should try to be consistent in our policies in order to avoid similar stresses in the future. Some modules have been frozen months ago for even smaller changes like a new theme, while others have been granted an exception and are frantically trying to get into shape before the arbitrary deadline. THIS is what is causing this stress, and the whole pointless discussion about calling something a beta or a RC, among others. We all know our releases were not RCs, as they were never intended for release tagging. If we do not analyze this situation and learn from it, we will repeat it in the future releases. My proposal for the future is: pick a schedule, agree on it, and if the project can not make it as a whole, relax it and pick a new one. Rinse, repeat. Only call something a RC when it is really intended for release, for example. Right now, I think that the people that are frustrated because their work did not go in due to the deadlines (like myself) need to take a deep breath, and relax, and let the Plasma and Oxygen people try to finish their vision, until the very last minute. We already granted exceptions to these teams, let them run with them until the release tag. And we will see how it goes. Hopefully there will be only minor issues, we will correct them in 4.0.1, and move on. We may even learn something new from this: maybe we will find out that having last minute rushes really strenghtens the commnity (see the rising number of contributors in panel-devel against the activity in kdegames for example.) Regards, Mauricio Piacentini _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
