Change release schedule 4.2 and schedule for 4.3

[Albert Astals Cid]

A Dijous 11 Setembre 2008, Aaron J. Seigo va escriure:
> 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.

Sorry to hijack the thread at this mail, i've not been following much but 
this "core people" approval sentence just made my radar ring.

Are we going to loose the capacity of committing everywhere? If so i'm totally 
against that kind of change.

Albert

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