[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipse.org-planning-council] [eclipse.org-architecture-council] EclipseCon 2016 AC/PC session
- From: Nick Boldt <nickboldt@xxxxxxxxx>
- Date: Tue, 26 Jan 2016 14:53:05 -0500
- Delivered-to: email@example.com
One topic that might be panel-worthy is one I've been wanting to put in front of the Planning Council -- the use of fully-qualified versions in simrel contribution files.
This idea comes from Mickael Istria, who's created a video to show how this might work in future for contributing to Neon, Oxygen, etc.
>ÂHere is the change I proposed to b3 editor to hopefully convince contributors, and PMC, of using fully-qualified versions:Âhttps://vid.me/K3GV
> The cost of fully-qualified version being almost free with that change, there is no reason why not making it mandatory now IMO.
Let me know if this is something that would make a good panel discussion, or would be better discussed in the Planning Council calls.
A longer discussion is attached below.
Issue:1. Consider a project that contributes content from an URL, with version range for the contributed features. If content of the repository changes, then without any change in aggregation description, the output of the simultaneous release is different. It makes build not reproducible2. The PMC has emitted a rule that makes that if a project contributes to SimRel, then the contribution file (describing the repo URL and the features to include) has to change. Concretely, there are 2 ways of implementing that:Â a. either the project specified fully-qualified versions, and change them whenever they want to contribute a new version, orÂ b. the project uses a build-specific URL, whom content don't change over time.If this rule is respected, it solves problem 1.3. The rule 2a is trivial to check, locally, during build, when contributing a change to GitHub, in the tool... Rule 2b is very difficult to check because it requires to keep an history of the p2 repository over time. Also, rule 2a makes the files more explicit, easier to humanly guess what is going to get into SimRel (but that's more a comfort thing)My goal is to show that 2a is a way more sustainable solution for item 1 than rule 2b, and then to clearly demonstrate that rule 2a should be the only allowed rule.In order to get the community OK with updating the versions in their contribution files, I worked on additions the the Aggregator model tool:Âhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=485472
Âand dependencies.How would fully-qualified versions be a way to continuous release?========================================In order to get continuous release, it is necessary to have reproducible and traceable builds. Indeed, let's imagine a project contribution is "flexible", it means that we do not know how much the current build output would differ from the previous one (it's issue 1). Continuous release requires that we always know what changes, to make sure that the change is acceptable for being released. So we need to know what changes, always, and to check it.Checking automatically that projects conform to rule 2 can only be done in the case of rule 2a. So we need 2a to automatically get 2 to automatically be able to trust contributions and allow continuous releases.Another important step for continuous releases is the enforcement of Gerrit and code-review before the merge. If all contributions go through Gerrit, we can add some automated tests on Gerrit to guarantee that the contribution is valid from SimRel POV (that can be license check, or even an install test, and even manual tests for some contributions that are known to be fragile...).If we get:* Trust that all changes are explicit (rule 2)* Checks on all incoming changes that they are acceptable for SimRelThen it means that we get the HEAD of SimRel always acceptable in the SimRel criteria, which means that we can release continuously.
For more details into the b3 files, see: