Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] aCute *wish* to participate in Simultaneous Release

I guess, my first question, if it’s not ready yet, why the rush to put it in simrel for Photon? Why not do your own release for now and add it later. We do have examples, pretty big ones, of things being added in the quarterly releases, why not add it in Photon.1?


And if you really want to get it into Photon.0, it might be easier to ask for a late add exception when your confident you want it in.


Just my thoughts. Alex is our rep on the planning council.




From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx] On Behalf Of Mickael Istria
Sent: Thursday, November 30, 2017 2:41 PM
To: tools-pmc@xxxxxxxxxxx; acute developer discussions <acute-dev@xxxxxxxxxxx>; Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [tools-pmc] aCute *wish* to participate in Simultaneous Release



Dear PMC,

We would like to have Eclipse aCute (for C# development in Eclipse IDE) included in the SImultaneous Release and did announce it the cross-project-issues-dev.

The issue is that the current quality of aCute is not sufficient for us to consider as ready for SimRel, and this depends mostly on some change in an upstream project we're using (OmniSharp). As soon as OmniSharp releases a newer version including the change we're waiting for, aCute should be safe to go into SimRel.

The big issue is that we don't know, nor have the power/influence to estimate or change, when OmniSharp will release our needed feature. So we cannot actually commit on a date when aCute can be perceived as good enough for SimRel.

Wayne informed that as of now, the SimRel process doesn't have a path for such projects who would like to be part of SimRel but cannot guarantee they'll be able to actually be in; and suggested that I ask the PMC to cascade the request to Planning Council.

One important thing to note in this discussion is that we do not expect any other project to depend on aCute. aCute has no public API, is still incubating, and we wouldn't advise anyone to start building on top of it. So, hopefully, the presence or not of aCute in SimRel shouldn't affect any other project.


My impression in that for this case, we could ask the Planning Council to set up a new rule to allow such "we'd like to get it but we're not sure we'll be able" projects to come in or out late in the release train, if it's clear that no other project should build on top of it and if project (aCute in that case) agrees to some constraints that Planning Council would consider necessary.


Can you please bring this to the next Planning Council and advise?


Thanks in advance!


Mickael Istria

Eclipse IDE developer, at Red Hat Developers community

Elected Committer Representative at the Eclipse Foundation board of directors

Back to the top