|Re: [incubation] Fast releasing projects|
On 28 Mar 2018, at 10:29, Mickael Istria wrote:
Hi,So this creates the situation that due to parallel IP process we get anapproval for check-in but we can not really checkin because our cadence isquicker 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 alreadydeveloped before release X may or may not get in release X, and whether itmakes 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 issomething very good and can profit to mature projects too. It would be worth discussing (with the Architecture Council I guess) whether anon-Incubation project could keep this parallel IP process under certainconditions.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  a project should doa release review for all Major and Minor releases . (IMHO it is wrongto assume a project will follow major.minor.service versioningbut that is a different matter). That requires the Che leads to submit areview 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 bypassedentirely.
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 tohave release review becoming easier and faster to do. _______________________________________________ incubation mailing list incubation@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top