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