I drafted a BP to adopt the Kafka one. I also highlights the content that
might require discussions in blue in the wiki page:
https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP-13+-+Time+Based+Release+Plan

Also I listed following points that require discussion for people to check
them easier:


- Length of a release: 4 months
- How does release cycle looks like?

- A month before release date: Release manager cuts the branch and starts
prepare the release notes including the features.

- Leave another week for minor features to get in.

- Last two weeks before release: Announce code freeze and start rolling the
RCs.

- Apply scope:

- Applied to major/minor feature releases. Bugfix releases will be done
based on the severity of bugs.

- If a feature is too large to span over releases?

- 1) break the feature into small pieces.

- 2) use feature branches

- What are the gaps to focus on?

- Test coverage with check ins.

- Documentation coverage with check ins.

- Compatibility testing.

- What is our EOL policy?

- rolling upgrade can be done from each release in past year (last 3
releases) to latest release

- Schedule for next 4 releases:

- August 2017 - November 2017

- November 2017 - February 2018

- February 2018 - May 2018

- May 2018 - August 2018


Any thoughts?

- Sijie



On Tue, Aug 8, 2017 at 1:00 AM, Enrico Olivelli <eolive...@gmail.com> wrote:

> It would be great.
> Thank you
> Enrico
>
> Il mar 8 ago 2017, 09:24 Jia Zhai <zhaiji...@gmail.com> ha scritto:
>
> > +1 to adopt it.  All the benefits seems reasonable.
> >
> > On Tue, Aug 8, 2017 at 9:59 AM, Sijie Guo <guosi...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > First thanks everyone who contributed to 4.5.0 in the past year, and
> > > especially thanks JV for spending time doing the release. The first
> > release
> > > candidate of 4.5.0 is finally out of review now. We are almost there.
> > >
> > > We eventually merge the major features from 3 main folked branches
> > > (Salesforce, Twitter and Yahoo), so that we can converge to one main
> open
> > > source branch across different organizations. We added a lot of
> features,
> > > bug fixes and improvements. We moved to github to make contribution
> > easier
> > > and friendly and we have new website with more documentation. There are
> > > tons of works we did very well in 4.5.0.
> > >
> > > However, I think the release has taken too long to complete. It causes
> a
> > > lot of inconsistencies between code, configuration and documentation.
> > This
> > > causes most of the contributions were spent on improving documentation
> at
> > > the end of the release. And also people can't really follow what's
> > > happening in a long-cycle release and they eventually left.
> > >
> > > I am thinking of changing the release plan/schedule to a more
> time-based
> > > mechanism what other projects (like Kafka, Flink) are doing:
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/Time+
> Based+Release+Plan
> > > Some of the benefits are documented in their wikis (also copied them in
> > the
> > > email for easy to read).
> > >
> > > Any thoughts? Shall we try to adopt this method?
> > >
> > >
> > >    1.
> > >
> > >    A quicker feedback cycle and users can benefit from features shipped
> > >    quicker
> > >    2.
> > >
> > >    Predictability for contributors and users:
> > >    1.
> > >
> > >       Developers and reviewers can decide in advance what release they
> > are
> > >       aiming for with specific features.
> > >       2.
> > >
> > >       If a feature misses a release we have a good idea of when it will
> > >       show up.
> > >       3.
> > >
> > >       Users know when to expect their features
> > >       3.
> > >
> > >    Transparency - There will be a published cut-off date (AKA feature
> > >    freeze) for the release and people will know about it in advance.
> > > Hopefully
> > >    this will remove the contention around which features make it.
> > >    4.
> > >
> > >    Quality - we've seen issues pop up in release candidates due to
> > >    last-minute features that didn't have proper time to bake in. More
> > time
> > >    between feature freeze and release will let us test more, document
> > more
> > > and
> > >    resolve more issues.
> > >
> > >
> > > - Sijie
> > >
> >
> --
>
>
> -- Enrico Olivelli
>

Reply via email to