[lttng-dev] Release strategy
jeremie.galarneau at efficios.com
Wed Jul 24 10:36:49 EDT 2013
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 . 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"
> For 3), I would try to put tentative release dates on the roadmap on
> Redmine or on a wiki article similar to ?
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.
> Any ideas/suggestions/constructive criticism on how we can improve our
> release process are quite welcome!
>  - http://bugs.lttng.org/projects/lttng/roadmap
>  - http://www.redmine.org/plugins/advanced_roadmap
>  - http://www.redmine.org/plugins/redmine_milestones
>  - 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
>> What are your hard / soft deadlines?
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
More information about the lttng-dev