[lttng-dev] Release strategy

[Mathieu Desnoyers]

* Christian Babeux (christian.babeux at efficios.com) wrote:
> So far multiple suggestions have been proposed for the issues outlined:
> 
> 1) Branching policy
> 
> 1. Creating a branch to stabilize new features (for release
> candidates) while development continues in master.
> 2. Staging branch for new features.
> 
> I think we will need to wait for feedback from David and Mathieu since
> they are the maintainers of the LTTng codebases. Personally, solution
> 1. get my vote.
> 
> Mathieu & David: What branching policy would you like to adopt?

I would add a 3rd option:

3. Feature freeze during rc

For two reasons:

a) It forces people to test, and pushes back on introduction of new
   code, thus improves quality,
b) keeps maintainers sane. We already have one -rc branch to manage,
   and at least one stable branch, per project (we'll have to decide how
   many stable branches we want to keep active). Adding features into
   master or a staging branch would add a 3rd branch to maintain for
   each project.

I know the downside is that contributors may have to wait before seeing
their features merged. As a side-effect, it forces them to do more
testing than writing new actual code, but this is exactly what we are
doing right now as maintainers.

> 
> 2) Release roadmap & 3) Tentative release dates
> 
> A cleanup of the bug tracker and setting clear releases dates on
> features would most likely solve this issue. Perhaps we should
> schedule a bug tracker cleaning event in August?

Sounds good.

> 
> As for the monthly summary, I volunteer to write and maintain it if
> the community is interested.

Good idea.

> 
> Also, I really like the idea proposed by Matthew for a system like
> Gerrit to handle patches submission and review. The integration with
> our Jenkins CI would be IMO quite useful to reduce time spent
> reviewing non-working or build breaking patches.
> 
> Mathieu & David: Would you be open to use such a system for patches?

Yes. We should compare this system with others used e.g. at Google.
Etienne Bergeron has interesting feedback on this topic.

Thanks,

Mathieu

> 
> Thanks,
> 
> Christian
> 
> On Wed, Jul 24, 2013 at 10:36 AM, Jérémie Galarneau
> <jeremie.galarneau at efficios.com> wrote:
> > On Tue, Jul 23, 2013 at 11:30 PM, Christian Babeux
> > <christian.babeux at efficios.com> wrote:
> >> Hi Matthew,
> >>
> >> You certainly raise valid and interesting questions about our release
> >> process. Here how I would categorize these questions:
> >>
> >> 1) Branching policy (when do we branch master? after the first release
> >> candidate or after a final release?)
> >>
> >> 2) Release roadmap (when the next release is planned? what does it contain?)
> >>
> >> 3) Tentative release dates
> >>
> >> For 1), the current way we are doing things is that during a release
> >> candidate phase for a new stable release, a complete code freeze is in
> >> effect e.g. only bug fixes will be merged until a stable release is
> >> out. Normally, after multiple release candidates, master is branched
> >> into a stable branch and the final official stable release is created
> >> from that branch.
> >>
> >> This could potentially cause troubles for contributors, e.g. posting a
> >> set of patches and getting no response or waiting for merge if a
> >> release candidate cycle is in effect. Any ideas/suggestions on how we
> >> could improve this?
> >>
> >
> > We should create a separate branch at the first release candidate and
> > stabilize it until the official release. The feature freeze would then
> > only apply to that branch while invasive changes could be merged in
> > master at all times. It would certainly make it easier on occasional
> > contributors that may not be aware of the release schedule (at the
> > expense of the maintainers' sanity...).
> >
> >> For 2), the release roadmap is available at [1]. The roadmap is kind
> >> of a mess right now because bugs are assigned to older stable releases
> >> giving the wrong impression that some stable releases are way late.
> >>
> >> We would need a way to distinguish between bugs on already released
> >> versions and features targeting future versions. Perhaps something
> >> like [2-3] could be promising?
> >>
> >
> > Disciplining ourselves in opening Features with reasonable target
> > dates on the bug tracker may be enough to make the current "Roadmap"
> > plug-in useful.
> >
> >> For 3), I would try to put tentative release dates on the roadmap on
> >> Redmine or on a wiki article similar to [4]?
> >>
> >
> > I'd prefer using the roadmap functionality. I'm afraid the wiki won't
> > be maintained as releases slip.
> >
> >> Another point that you did not mention is how we plan minor releases.
> >> I think we will need to define a clear policy for minor releases
> >> sooner than later because it is becoming quite painful to support
> >> three codebases (modules, ust, tools) with three stable branches...
> >> Perhaps in another thread?
> >>
> >> On a more general note, I think clear communication is the key here.
> >> I'm wondering if a monthly summary of the development activities on
> >> LTTng and related projects could be interesting for the community?
> >> Content example:
> >>
> >> - What have we accomplished in the past month.
> >> - What we are planning for the following month.
> >> - Release status (next stable tentative release dates, planned minor
> >> releases, etc.)
> >> - Etc.
> >>
> >
> > Sounds good. It would also be a great opportunity to structure
> > discussions around the planning.
> >
> > Regards,
> > Jérémie
> >
> >> Any ideas/suggestions/constructive criticism on how we can improve our
> >> release process are quite welcome!
> >>
> >> Thanks,
> >>
> >> Christian
> >>
> >> [1] - http://bugs.lttng.org/projects/lttng/roadmap
> >> [2] - http://www.redmine.org/plugins/advanced_roadmap
> >> [3] - http://www.redmine.org/plugins/redmine_milestones
> >> [4] - https://www.gnu.org/software/gdb/schedule/
> >>
> >> On Tue, Jul 23, 2013 at 3:52 PM, Matthew Khouzam
> >> <matthew.khouzam at ericsson.com> wrote:
> >>> Hello tracing rangers,
> >>>
> >>> I am a bit confused about the whole release cycle system.
> >>>
> >>> If you guys are in RC, I have a cool feature I was working on, where do
> >>> I put it?
> >>>
> >>> When are releases coming out? is it planned or a surprise (I know it's
> >>> planned)
> >>>
> >>> What are your hard / soft deadlines?
> >>>
> >>> Thanks,
> >>> Matthew
> >>>
> >>> _______________________________________________
> >>> lttng-dev mailing list
> >>> lttng-dev at lists.lttng.org
> >>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >>
> >> _______________________________________________
> >> lttng-dev mailing list
> >> lttng-dev at lists.lttng.org
> >> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> >
> >
> > --
> > Jérémie Galarneau
> > EfficiOS Inc.
> > http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com