Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] Fast releasing projects

On 28 Mar 2018, at 10:29, Mickael Istria wrote:


So this creates the situation that due to parallel IP process we get an
approval for check-in but we can not really checkin because our cadence is
quicker than the CQ process.

A technical workaround can be to take advantage of multiple branches: one with ip-cleared content and the other with pending ip-check content. You'd only release from the first one, but snapshots would be built from the 2nd one. When you get IP approval, you can cherry-pick the commits from the
"wip" branch to the "ip-cleared" one.
This shouldn't slow down development too much, however, it brings some
uncertainity to release content: non IP cleared change that's already
developed before release X may or may not get in release X, and whether it
makes it or not in release X, X+1, X+2... would only depend on the IP
checks completion date.

This is not very different from the current practice. Everything on Che is a PR and PRs that require CQs are not approved until final approval. This was developer’s are not
really blocked but it hinders the benefits of fast release cadences.

But one point you raise is quite interesting: the parallel IP process is
something very good and can profit to mature projects too. It would be
worth discussing (with the Architecture Council I guess) whether a
non-Incubation project could keep this parallel IP process under certain

Is there any advice on how we can do CQs on a quick release cadence?

Many CQs are automated so they shouldn't take much time to proceed. Have you identified what was the bottleneck step in the approval of CQs? PMC approval? If so, maybe it's more something to bring to the PMC, and maybe try to get someone closer to Che part of the PMC to speed up the approvals.

Another issue we face with quick cadences is the release reviews.
According to project handbook [5] a project should do
a release review for all Major and Minor releases [1]. (IMHO it is wrong
to assume a project will follow major.minor.service versioning
but that is a different matter). That requires the Che leads to submit a
review every 3 weeks and I am not
sure if this is really creating much value.

From outsiders of this project, a release record (requested by review) is actually pretty useful to get a good summary of what's going on. While you think it doesn't really create value (and it probably doesn't for you), I believe it creates value for outsiders and helps making the project more open and welcoming. So I don't think it's a step that should be bypassed

Isn’t the Release notes (the new & noteworthy) a better format the outsiders audience?

But for such projects with fast release cadence, it would indeed be good to
have release review becoming easier and faster to do.
incubation mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top