Huzzah! 3.0.0 is finished, now what?

[Leif Hedstrom <zw...@apache.org>]

Hi all,

I'd like to start the discussions and some brainstorming for how we 
could continue development going forward. This will be a bullet list for 
now, once we've discussed, I'll capture all this in a few Wiki pages. 
These items are just ideas that have been brewing for a while, and I 
don't want to risk losing them due to my ageing brain going mushy.

    * We aim for 6-month release schedule for major stable releases.
      This would put us around mid-December for v3.2, and June 2012 for
      v3.4 (or 4.0, depending on what we schedule in for feature
      changes, see further down).
    * We need a much better project plan for these stable releases. I'll
      start the work on the v3.2 plans on the Wiki asap. What I'd like
      to see is three main sections, like
         1. New features (this has to be a reasonable list, and probably
            no more than 1-2 major feature per core developer / team).
         2. Major bug fixes (this can be a bigger list, but still
            achievable).
         3. Incremental fixes as deemed necessary (bug reports, crashers
            etc.)
      The Wiki will obviously be open for everyone to participate with
      ideas and additions.
    * I'm hoping that v3.2 and v3.4 will be much less painful, and much
      less risky, to finish and upgrade too compared to the v2.0.0 to
      v3.0.0 cycle. We definitely need to add a few more features in
      each relaese, but perhaps with much more focus on stability,
      performance, and usability (ease of use, correctness etc.). Our
      users probably will go crazy if they have to experience the 3.0.0
      pain on every major release :).
    * We should do incremental patch releases for v3.0.x as often as
      necessary. This will not be driven by a fixed schedule, but by
      what the community and our users decides are important to release.
      Obviously security bugs have priority as well.
    * I'd like to suggest that we have a release manager for the v3.0.x
      releases. This doesn't exclude anyone else from cutting a release,
      and it does not change how a release is created and voted on. But,
      it will ease the burden of preparing periodic patch releases,
      backporting patches, and overall "herding the cats" to get things
      done for a release. If this is agreed upon, we'll start a
      different thread on this topic, and if you are interested in
      taking on this role, please post.
    * Documentation, we need to get this stabilized, and to the point
      where any code changes that also requires doc changes should all
      be done together (i.e. no separate bugs thrown over the magical
      doc fence).


Please discuss.

-- Leif

Re: Huzzah! 3.0.0 is finished, now what?

[Igor Galić <i....@brainsware.org>]

----- Original Message -----
> Hi all,
> 
> I'd like to start the discussions and some brainstorming for how we
> could continue development going forward. This will be a bullet list
> for
> now, once we've discussed, I'll capture all this in a few Wiki pages.
> These items are just ideas that have been brewing for a while, and I
> don't want to risk losing them due to my ageing brain going mushy.
> 
>     * We aim for 6-month release schedule for major stable releases.

+1 for time based. More to that, but we followed that philosophy
with -unstable already: Release often, release early.

>       This would put us around mid-December for v3.2, and June 2012
>       for
>       v3.4 (or 4.0, depending on what we schedule in for feature
>       changes, see further down).
>     * We need a much better project plan for these stable releases.
>     I'll
>       start the work on the v3.2 plans on the Wiki asap. What I'd
>       like
>       to see is three main sections, like
>          1. New features (this has to be a reasonable list, and
>          probably
>             no more than 1-2 major feature per core developer /
>             team).
>          2. Major bug fixes (this can be a bigger list, but still
>             achievable).
>          3. Incremental fixes as deemed necessary (bug reports,
>          crashers
>             etc.)
>       The Wiki will obviously be open for everyone to participate
>       with
>       ideas and additions.
>     * I'm hoping that v3.2 and v3.4 will be much less painful, and
>     much
>       less risky, to finish and upgrade too compared to the v2.0.0 to
>       v3.0.0 cycle. We definitely need to add a few more features in
>       each relaese, but perhaps with much more focus on stability,
>       performance, and usability (ease of use, correctness etc.). Our
>       users probably will go crazy if they have to experience the
>       3.0.0
>       pain on every major release :).
>     * We should do incremental patch releases for v3.0.x as often as
>       necessary. This will not be driven by a fixed schedule, but by
>       what the community and our users decides are important to
>       release.
>       Obviously security bugs have priority as well.
>     * I'd like to suggest that we have a release manager for the
>     v3.0.x
>       releases. This doesn't exclude anyone else from cutting a
>       release,
>       and it does not change how a release is created and voted on.
>       But,
>       it will ease the burden of preparing periodic patch releases,
>       backporting patches, and overall "herding the cats" to get
>       things
>       done for a release. If this is agreed upon, we'll start a
>       different thread on this topic, and if you are interested in
>       taking on this role, please post.

I would like to volunteer as RM for the 3.0.x branch.
Obviously, I'll need a little bit of support to get started, but
I'd like to give it a try nonetheless.

>     * Documentation, we need to get this stabilized, and to the point
>       where any code changes that also requires doc changes should
>       all
>       be done together (i.e. no separate bugs thrown over the magical
>       doc fence).

+1
Further down the documentation line: In our ats-cms branch I've
already created a /trunk/ folder. Even though we've branched off
3.0.x, I don't think it makes sense to branch the docs - yet. We
should get them ready for broader consumption, ASAP. Then we can
and should branch.

> Please discuss.
> 
> -- Leif

i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/