a self debriefing

[Aaron J. Seigo]

On Tuesday 09 September 2008, Tom Albers wrote:
> 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.

and the years and years of releases where we hit schdules spot on, time after 
time? what we didn't have was a set "always N months" cycle; but let's not 
short change ourselves just because of 4.0 (which everyone understands, btw) 
and forget our track record for the last 12 years. if we are concerned about 
trust from others, we need to remind them about that track record, show them 
our current track record and start explicitly expecting some quid pro quo from 
them for us to remain interested in keeping that communication open.

if that's too much like negotiating and partner relationship to deal with, 
then we either need to find people who are willing to do that work or just stop 
deluding ourselves that we are actually doing this for other people.

it's not enough to have a schedule shaped after the interests of others. those 
others need to brought into it.

i think we have decent communication with the Suse people, but everyone else 
is pretty much a mystery .. including the most vocal company, Canonical.

> > * 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.

agreed.

> > * 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.

a good start might be to get a TT person who can speak to release schedules 
either on this list or talking regularly with someone who is and get 
information about the release schedules flowing.

> > * 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.

the counter point being that there is exactly one project out there that seems 
to benefit externally from a set release schedule, and whether that is the 
actual causal factor that it is made out to be is *highly* debatable. 

being precisely on the same week twice a year every year is one thing. being 
in the same month twice a year is another thing. simply being predictable 
(6-... or 6-6-9 or whatever) is another thing again.

i'm really concerned about letting the tail (certain distributions) wag the 
dog (KDE) here. there is a balance to be found between trying to placate 
external interests and taking care of our own.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080909/0d0c06b1/attachment.sig