Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Wednesday 10 September 2008, Michael Pyne wrote:
> On Tuesday 09 September 2008, Cornelius Schumacher wrote:
> > On Wednesday 10 September 2008 02:35:53 Mauricio Piacentini wrote:
> > There is no way we can force developers to do anything. But we can try to
> > make it easy and rewarding to do so.
>
> I am pretty much super-late to this discussion but I think this is one of
> the points to the summer-in-trunk proposal:
>
> If releases are to come from a "winter" branch then you must not only work
...
> we do to improve quality, and of those processes, which are practical to
> implement without squelching development?

i agree with pretty much everything you say here, Michael =)

> In that regard I like the season-themed branches idea although I would like
> to see the details fleshed out on how we handle merging code from spring ->
> summer -> autumn -> winter branches.

this may be different from project to project, but here's how we would handle 
it in plasma, based on what we already do now:

Primary Development
-----------------------------

Spring -> Summer happens using the usual review and approval system; people 
such as myself, Sebas, Marco, Chani, $OTHER_CENTRAL_PLASMA_DEVS tend to do the 
bulk of approvals and merges. nobody outside of the core team needs to worry 
about Spring branches unless they really care to.

the current analog to this for us right now is playground->kdereview->trunk

Summer->Autumn .. that would be something the plasma team would end up doing 
as well: at known good points in development (from our POV anyways) we'd merge 
over so everyone could start using it. it wouldn't happen more than once per 
week nor less than once a month. i imagine twice a month is realistic. only 
the plasma team would need to worry about this phase, though it would be 
something any plasma contributor could do once we agree it's "ready".

there is no current analog to this part for us.

Autumn -> Winter: this would happen when the release team communicates it's 
release time. i imagine that we'd do the entire kdebase Autumn branch all at 
once, so this is something that we could share and would take just one person 
to do once per release.

the current analog to this is branching for release, though it's not a perfect 
analog as Winter would happen at a different point in time (at freeze) in the 
proposed model.


Quality Improvement (aka bug fixing ;)
----------------------------
this would be in response to reports on bugs.kde.org or from people testing 
Autumn/Winter communicating directly. we'd commit directly to Autumn and push 
that change into Winter once it was deemed tested; that may happen immediately 
for obvious things, or after a short delay. we'd pull changes from Autumn into 
Summer at the point we ready summer for Autumn integration.

if we were using an SCM that supported it, we'd probably use the pull request 
feature to tag commits that need to be pulled over.

the current analog to this is committing to trunk and then backporting to 
branch.


so for the plasma team, we'd work very similarly to how we do now though 
hopefully with a bit less chaos and without having individuals impeded by 
freeze periods.

for people outside the plasma team ... it'd be life as usual: using either 
Autumn or Winter and switching between those as they see fit.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080911/48e201eb/attachment.sig>