<div dir="ltr">In our team, we use <a href="http://appspot.com">appspot.com</a>. The website manages any "diff" (svn diff, git diff, etc...).<div>And anybody can send a code review on any project. It's a open code review plateform.</div>
<div>So, there is not a lot of feature but it is integrated in our tools.</div><div><br></div><div>I never try guerrit, but probably the same kind of feature.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Aug 5, 2013 at 9:33 AM, Mathieu Desnoyers <span dir="ltr"><<a href="mailto:mathieu.desnoyers@efficios.com" target="_blank">mathieu.desnoyers@efficios.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Christian Babeux (<a href="mailto:christian.babeux@efficios.com">christian.babeux@efficios.com</a>) wrote:<br>
> So far multiple suggestions have been proposed for the issues outlined:<br>
><br>
> 1) Branching policy<br>
><br>
> 1. Creating a branch to stabilize new features (for release<br>
> candidates) while development continues in master.<br>
> 2. Staging branch for new features.<br>
><br>
> I think we will need to wait for feedback from David and Mathieu since<br>
> they are the maintainers of the LTTng codebases. Personally, solution<br>
> 1. get my vote.<br>
><br>
> Mathieu & David: What branching policy would you like to adopt?<br>
<br>
I would add a 3rd option:<br>
<br>
3. Feature freeze during rc<br>
<br>
For two reasons:<br>
<br>
a) It forces people to test, and pushes back on introduction of new<br>
   code, thus improves quality,<br>
b) keeps maintainers sane. We already have one -rc branch to manage,<br>
   and at least one stable branch, per project (we'll have to decide how<br>
   many stable branches we want to keep active). Adding features into<br>
   master or a staging branch would add a 3rd branch to maintain for<br>
   each project.<br>
<br>
I know the downside is that contributors may have to wait before seeing<br>
their features merged. As a side-effect, it forces them to do more<br>
testing than writing new actual code, but this is exactly what we are<br>
doing right now as maintainers.<br>
<br>
><br>
> 2) Release roadmap & 3) Tentative release dates<br>
><br>
> A cleanup of the bug tracker and setting clear releases dates on<br>
> features would most likely solve this issue. Perhaps we should<br>
> schedule a bug tracker cleaning event in August?<br>
<br>
Sounds good.<br>
<br>
><br>
> As for the monthly summary, I volunteer to write and maintain it if<br>
> the community is interested.<br>
<br>
Good idea.<br>
<br>
><br>
> Also, I really like the idea proposed by Matthew for a system like<br>
> Gerrit to handle patches submission and review. The integration with<br>
> our Jenkins CI would be IMO quite useful to reduce time spent<br>
> reviewing non-working or build breaking patches.<br>
><br>
> Mathieu & David: Would you be open to use such a system for patches?<br>
<br>
Yes. We should compare this system with others used e.g. at Google.<br>
Etienne Bergeron has interesting feedback on this topic.<br>
<br>
Thanks,<br>
<br>
Mathieu<br>
<br>
><br>
> Thanks,<br>
><br>
> Christian<br>
><br>
> On Wed, Jul 24, 2013 at 10:36 AM, Jérémie Galarneau<br>
> <<a href="mailto:jeremie.galarneau@efficios.com">jeremie.galarneau@efficios.com</a>> wrote:<br>
> > On Tue, Jul 23, 2013 at 11:30 PM, Christian Babeux<br>
> > <<a href="mailto:christian.babeux@efficios.com">christian.babeux@efficios.com</a>> wrote:<br>
> >> Hi Matthew,<br>
> >><br>
> >> You certainly raise valid and interesting questions about our release<br>
> >> process. Here how I would categorize these questions:<br>
> >><br>
> >> 1) Branching policy (when do we branch master? after the first release<br>
> >> candidate or after a final release?)<br>
> >><br>
> >> 2) Release roadmap (when the next release is planned? what does it contain?)<br>
> >><br>
> >> 3) Tentative release dates<br>
> >><br>
> >> For 1), the current way we are doing things is that during a release<br>
> >> candidate phase for a new stable release, a complete code freeze is in<br>
> >> effect e.g. only bug fixes will be merged until a stable release is<br>
> >> out. Normally, after multiple release candidates, master is branched<br>
> >> into a stable branch and the final official stable release is created<br>
> >> from that branch.<br>
> >><br>
> >> This could potentially cause troubles for contributors, e.g. posting a<br>
> >> set of patches and getting no response or waiting for merge if a<br>
> >> release candidate cycle is in effect. Any ideas/suggestions on how we<br>
> >> could improve this?<br>
> >><br>
> ><br>
> > We should create a separate branch at the first release candidate and<br>
> > stabilize it until the official release. The feature freeze would then<br>
> > only apply to that branch while invasive changes could be merged in<br>
> > master at all times. It would certainly make it easier on occasional<br>
> > contributors that may not be aware of the release schedule (at the<br>
> > expense of the maintainers' sanity...).<br>
> ><br>
> >> For 2), the release roadmap is available at [1]. The roadmap is kind<br>
> >> of a mess right now because bugs are assigned to older stable releases<br>
> >> giving the wrong impression that some stable releases are way late.<br>
> >><br>
> >> We would need a way to distinguish between bugs on already released<br>
> >> versions and features targeting future versions. Perhaps something<br>
> >> like [2-3] could be promising?<br>
> >><br>
> ><br>
> > Disciplining ourselves in opening Features with reasonable target<br>
> > dates on the bug tracker may be enough to make the current "Roadmap"<br>
> > plug-in useful.<br>
> ><br>
> >> For 3), I would try to put tentative release dates on the roadmap on<br>
> >> Redmine or on a wiki article similar to [4]?<br>
> >><br>
> ><br>
> > I'd prefer using the roadmap functionality. I'm afraid the wiki won't<br>
> > be maintained as releases slip.<br>
> ><br>
> >> Another point that you did not mention is how we plan minor releases.<br>
> >> I think we will need to define a clear policy for minor releases<br>
> >> sooner than later because it is becoming quite painful to support<br>
> >> three codebases (modules, ust, tools) with three stable branches...<br>
> >> Perhaps in another thread?<br>
> >><br>
> >> On a more general note, I think clear communication is the key here.<br>
> >> I'm wondering if a monthly summary of the development activities on<br>
> >> LTTng and related projects could be interesting for the community?<br>
> >> Content example:<br>
> >><br>
> >> - What have we accomplished in the past month.<br>
> >> - What we are planning for the following month.<br>
> >> - Release status (next stable tentative release dates, planned minor<br>
> >> releases, etc.)<br>
> >> - Etc.<br>
> >><br>
> ><br>
> > Sounds good. It would also be a great opportunity to structure<br>
> > discussions around the planning.<br>
> ><br>
> > Regards,<br>
> > Jérémie<br>
> ><br>
> >> Any ideas/suggestions/constructive criticism on how we can improve our<br>
> >> release process are quite welcome!<br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> Christian<br>
> >><br>
> >> [1] - <a href="http://bugs.lttng.org/projects/lttng/roadmap" target="_blank">http://bugs.lttng.org/projects/lttng/roadmap</a><br>
> >> [2] - <a href="http://www.redmine.org/plugins/advanced_roadmap" target="_blank">http://www.redmine.org/plugins/advanced_roadmap</a><br>
> >> [3] - <a href="http://www.redmine.org/plugins/redmine_milestones" target="_blank">http://www.redmine.org/plugins/redmine_milestones</a><br>
> >> [4] - <a href="https://www.gnu.org/software/gdb/schedule/" target="_blank">https://www.gnu.org/software/gdb/schedule/</a><br>
> >><br>
> >> On Tue, Jul 23, 2013 at 3:52 PM, Matthew Khouzam<br>
> >> <<a href="mailto:matthew.khouzam@ericsson.com">matthew.khouzam@ericsson.com</a>> wrote:<br>
> >>> Hello tracing rangers,<br>
> >>><br>
> >>> I am a bit confused about the whole release cycle system.<br>
> >>><br>
> >>> If you guys are in RC, I have a cool feature I was working on, where do<br>
> >>> I put it?<br>
> >>><br>
> >>> When are releases coming out? is it planned or a surprise (I know it's<br>
> >>> planned)<br>
> >>><br>
> >>> What are your hard / soft deadlines?<br>
> >>><br>
> >>> Thanks,<br>
> >>> Matthew<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> lttng-dev mailing list<br>
> >>> <a href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
> >>> <a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" target="_blank">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
> >><br>
> >> _______________________________________________<br>
> >> lttng-dev mailing list<br>
> >> <a href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
> >> <a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" target="_blank">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Jérémie Galarneau<br>
> > EfficiOS Inc.<br>
> > <a href="http://www.efficios.com" target="_blank">http://www.efficios.com</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Mathieu Desnoyers<br>
EfficiOS Inc.<br>
<a href="http://www.efficios.com" target="_blank">http://www.efficios.com</a><br>
</font></span></blockquote></div><br></div>