Planning Council calls better, if that.
A "cross-project" bug might even suffice. I think Doug
responded to this, or similar proposal, that we (the Planning Council)
need to be careful not to require a lot of 'extra work' from projects.
I responded to this or similar proposal that it was not clear such an "up
front" check would help all that much - help enough to make it worth
while to spend this much time on it. How much more could be said at a panel
Nick Boldt <nickboldt@xxxxxxxxx> To:
Mickael Istria <mistria@xxxxxxxxxx>,
"Nboldt@xxxxxxxxxx" <Nboldt@xxxxxxxxxx> Date:
01/26/2016 02:55 PM Subject:
2016 AC/PC session Sent by:
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,
> 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
Let me know if this is something that would make a good
panel discussion, or would be better discussed in the Planning Council
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 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.
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
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.
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: Hey!
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.
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
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
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.