[lttng-dev] Release strategy

[Christian Babeux]

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?

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?

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

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?

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