Shipping a cursor theme with KDE

[Mauricio Piacentini]

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