At Monday 08 September 2008 20:25, you wrote:
> once the 4.2 schedule decision is worked out, i think it would be really good
> to sit back and ask some questions. this may simply re-affirm what we are
> doing
>
> or it may indicate need for changes. either way, having a conscious awareness
> of how we are doing is undeniably better than simply making it up as we go
> along.
>
> some questions i'd suggest asking ourselves (please add your own as well):
>
> * what has the 6 month cycle won us in terms of real benefit thus far?
Well, the counter question is, have we proven ourselfes enough so other parties
will depend on it. I think not. Even before the first cycle was completed there
were already votes to change the schedule (yeah, that was you ;-)).
If I was a project that was looking at if it would be possible to depend on
KDE's planning, I would be scared away immediatly. And to take a bit of blame
myself: the 4.2 shifting thing would have been a confirmation of that
conclusion.
So for people to trust our planning, we need to prove it first, that has not
happened and that need 2-4 years more. Untill that I don't think we will get
any benefit from it, other than clearity for users and devels.
> * are we getting the return in commitment promised from third parties due to
> the discipline of a 6 month cycle, or do we need to re-assess that with them?
Already answered mostly. But querying the likely subjects would be a good idea.
> * how long before we can disentable the development cycle from it, ala Dirk
> and Sebastian's presentation at Akademy '08?
>
> * if that disentanglement will take more than a year, how do we deal with
> aligning our development with Qt? (our most critical and quickly evolving
> component)
No ideas.
> * under what circumstances should we allow ourselves to alter the plan for
> the
> cycle we are currently in at the time?
It is of course a matter of judging weights. If we would have external projects
depending on our cycles, we would consider their position, but as long as we
don't have any, we are tempted to not be to firm in keeping to the dates, which
of course leads to doubts at those considering to depend on the cycle. So - and
i can not stress this to much -, get a schedule and stick to it for ~5
releases, and then evaluate.
> * how do we define "useful predictability"? is it knowing that the goal in N
> cycles from now will be 6 months, or is it more important to know with
> certainty what the next 2-3 releases will actually be?
>
> * are application developers being well served by the amount and form of
> communication thus far?
no
> * are the libraries being well served by the amount and form of communication
> thus far?
no
> overall, i think the release team is doing a very good job. the above
> questions are not an indictment or a measure of distrust in the process. they
> are, rather, out of respect for what is working and a desire to see this team
> remain a healthy and well-oiled machine.
Allen's conclusions are spot on. We need to improve communication. But also the
discussion in this room. The change to the 4.2 schedule was announced pretty
clear on this mailinglist, but got no feedback at all. After posting to k-c-d
there was so much resistance that we needed to revert. That simply implies this
list failed and that we need to think why that happened. And to be honest, I
don't want to repeat that ever in the future. I've got no answers how we can
improve that though.
And, to make it personal: I would like to know what I should have done
differently to prevent this, but I've found no answer yet by talking to myself.
Toma
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
