Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] EclipseCon 2016 AC/PC session

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:
> 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.


Nick Boldt 


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: 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:

On Mon, Jan 25, 2016 at 9:39 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
The panel was just an idea. I'm certainly interested in counter proposals. I also agree that any sort of "meet the councils" session isn't going to be a big draw.

Perhaps there might be some value in just having a (semi-)closed session to talk about the state of our IDEs.

i.e. invite representatives from JDT, Orion, Che, Dirigible, etc. together to talk with the councils about future plans, synergies, and what-not.

If we want to push forward with a panel, we need to move on it soon.



On 25/01/16 09:33 AM, Martin Lippert wrote:

I agree with David, I am not in favor of a panel discussion unless we have something controversial or forward-leading to discuss there.

I am not sure what Tyler is going to talk about in his keynote about the future of IDEs. That might be an interesting topic for a panel on Thursday (discussing the fall-out of that keynote), but that highly depends on the content of the keynote and what the architecture council have to say about that. But maybe that is a different panel discussion then, not the meet-the-architecture-council thing, but more something like “what do you think about the future of IDEs”, probably with a different set of panelists than purely the AC.

Just some thoughts…


Am 18.01.2016 um 23:03 schrieb Wayne Beaton <wayne@xxxxxxxxxxx>:

Greetings folks.

As we discussed on last Thursday's call, we have a big chunk of time set aside for the Architecture and Planning Councils to meet during the conference: we overlap with the session slots on Thursday (10:30-12:35 & 13:45-15:05). We'll have lunch with the rest of the conference attendees.

I'm thinking that it might be cool to have open Q&A sessions and invite the community to join us in the afternoon (e.g. one for the AC and one for the PC). We might consider live streaming these sessions via Google Hangout or something.

10:30-12:35: General discussion (closed session). Role of the Architecture Council, Evolution of the Eclipse Development Process, Eclipse IDE as a product, FEEP priorities
12:35-13:45: Lunch
13:45-14:20: Planning Council Q&A Panel. Changes to the release schedule, joining the simultaneous release, the future of Orbit
14:30-15:05: Architecture Q&A Panel. Eclipse Development Process, technical discussion

The topics listed here are just ideas off the top of my head. The timing seems like a natural fit to me, but we can tweak everything. I welcome your input.

The Thursday session schedule is here:

Note that, if we're going to do a panel discussion, we'll need to decide fairly quickly to make sure that we allocate an appropriately-sized room.

Note also that I haven't discussed this with the Planning Council yet, but I'm pretty sure that  most of the PC is represented on this list anyway. I do intend to bring this formally to the PC later this week, so please provide your input sooner rather than later.


Wayne Beaton
The Eclipse Foundation
_______________________________________________ mailing list

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.
_______________________________________________ mailing list

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
The Eclipse Foundation
          NA 2016

_______________________________________________ mailing list

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.

Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.

Back to the top