Change release schedule 4.2 and schedule for 4.3

[Sebastian Kügler]

On Wednesday 10 September 2008 03:57:15 Aaron J. Seigo wrote:
> going back to what you said about communication: unless we communicate
> *clearly* how things work, this will fail no matter how clever it is.
> personally, i'd set the "clearly" metric as:
>
> * no more than 3 normal length paragraphs of text
> * 3-6 explanatory images/graphs (the ones in the dot story were a good
>   start) 
> * clear enough that one read through is enough
>

Obviously, I'm willing to help with this. I'd propose to draft something like 
this (I feel we're getting a very good idea and even consensus here what we 
want, and are getting closer to finding a way how we could design that so it's 
an improvement over our current processes). This drafting will happen on the 
release-team mailinglist, so we'll end up with a proposal that's both clear 
and concrete by the release-team based on this (fruitful and important) 
discussion. Hopefully, the proposal is good enough so that enough people will 
help with getting in a really good shape it implemented it. The proposal 
should go along with a plan-de-campagne and a timeline (we basically have 
windows between releases where such structural changes can be done, so we need 
some sort of planning and cannot just switch at the moment it's ready).

> we may have a different set of information for new / casual devleopers
> ("just use Autumn") versus regularly commiting application developers
> versus project maintainers ...
>
> i think it can be done. i couldn't personally write those three paragraphs
> yet, though. maybe after another 10lbs of email and more reading about how
> other projects with centralized repositories that usie a distributed SCM
> handle it .....
>
> but if we can't write those 3 short paragraphs + a handful of
> illustrations, we won't be able to make this fly, imho.

Augmenting the above 3-paragraph-description, we also need documentation how 
to deal with the development process and tools. Some starting points I have in 
mind are:

- how does a certain team work (as opposed to KDE's overall dev model)
- best practise guide for stabilisation and feature development
- workflow tips for code review processes
- cheat sheets for git + kde (or whatever VCS we end up using)
- how you can do team-based development

A new development model will likely allow for more flexibility, so extra 
clarity of what is a good practise will be needed. I can chip in here as well.

> > That's why I really would like to maintain some release rhythm for the
> > overall development.
>
> yes, that would need to be part of the new system as well .. it just
> wouldn't be enforced using technical limitations but social coordination
> (the FOSS version of project management? =)

Indeed. I think we're even in a rather good situation for this. The KDE 
community has quite strong social ties (even more so within subprojects like 
edu, games, plasma, ...) so I'm pretty confident that with enough clarity (for 
example better communication by the release team ;)), we can make great leaps 
here.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080910/115eb0de/attachment.sig>