Hi, 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. 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 conditions. > 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 entirely. 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
