Frankly, I'm not seeing a great deal of interest expressed in doing
public panels and am ready to drop the idea.
If we are going do one or more panel discussions, we'll have to
decide very soon as there are some logistics that have to occur to
make that happen (i.e. we need a larger room). Speak up now.
This topic seems, however, like something that we can certainly
discuss with the group.
My revised proposal is that we just set aside (closed) meeting time
and assemble a batch of topics.
Topics
* Role of the Architecture and Planning Councils
* Evolution of the Eclipse Development Process
* Eclipse IDE as a product
* FEEP priorities
* Future and evolution of Simultaneous Release (e.g. changes to the
release schedule, fully-qualified versions in contributions)
* Platform vision and the future of Eclipse IDEs, e.g. JDT, Orion,
Che, Dirigible
Are we getting closer?
Please weigh in if you'd like to add other topics.
If you have not registered for the conference already, please do so.
https://www.eclipsecon.org/na2016/registration
Wayne
On 26/01/16 02:53 PM, Nick Boldt wrote:
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.
Cheers,
Nick Boldt
------
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 reproducible
2. 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 SimRel
Then 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:
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
|
