[lttng-dev] Release strategy

Mon Aug 5 09:46:02 EDT 2013

In our team, we use appspot.com. The website manages any "diff" (svn diff,
git diff, etc...).
And anybody can send a code review on any project. It's a open code review
plateform.
So, there is not a lot of feature but it is integrated in our tools.

I never try guerrit, but probably the same kind of feature.

On Mon, Aug 5, 2013 at 9:33 AM, Mathieu Desnoyers <
mathieu.desnoyers at efficios.com> wrote:

> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130805/0b6d08b1/attachment.html>