* Christian Babeux ([email protected]) 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 > <[email protected]> wrote: > > On Tue, Jul 23, 2013 at 11:30 PM, Christian Babeux > > <[email protected]> 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 > >> <[email protected]> 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 > >>> [email protected] > >>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > >> > >> _______________________________________________ > >> lttng-dev mailing list > >> [email protected] > >> 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 _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
