[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks
|
Hi all,
-1 for going back to annual releases.
For stable components there is an option to keep the same version
contributed for a number of releases - this should be sufficient to
support "annual release" experience.
For new and incubation components "annual" may mean mostly "next
life".
For people that wants to contribute a patch it sounds like "ok, if
you will be patient enough to go through all the environment setup,
reviews and discussion - you have a chance to see you change next
year" - for a majority of newcomers this doesn't look attractive.
For eclipse-based vendors - annual release is the invitation to do a
fork and think about switching to another platform. Why? Because
"another platform" with growing popularity has monthly releases.
Also annual releases will resurrect a number of "service releases"
with all the effort required, at least to support the new Java
versions. So, as Mickael stated below, the effort is comparable.
I agree with Mickael that only enforced automated reject via
pipeline rules can improve the situation with release quality.
Passing pipeline should mean "the change is good enough to spent
time on final review before the merge".
Regards,
AF
29.01.2020 12:58, Mickael Istria пишет:
Hi all,
+1 for going back to annual releases.
Projects are not forced to do quarterly releases. You can
have your project do a yearly release, but it just means
that since Platform releases every 3 months, you need to
check your project against 2 milestones and 2 RCs of the
Platform every 3 months (12 times a year). Which doesn't
change much compared to previous state where projects were
supposed to be tested against all Platform milestones and
RC, ie 11 times a year.\
The work done by Ed M is very appreciated. Ideally,
the different checks (e.g. licenses) could be automated
to prevent degradation of SimRel quality.
The licence check may be missing, and could be added.
Or one can probably just build a similar Maven
configuration to run the other analyzers.
But the real thing is that what matters is not building
the report, but enforcing rules without human intervention.
This typically happens only with mechanism that fail the
build in case the analyzers see issue. As long as human
reading is required, it cost too much effort and time to
someone, and feedback loop becomes too long. The only good
way to report a bad state is to fail the build so it doesn't
pass review.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
