Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] list for IDE WG steering committee with concrete actions


As a general FYI for the Planning Council:

I considered resigning my position on the Planning Council, as I did my position as elected committer representative on the Steering Committee,  but the Modeling PMC is not very active so I think it makes sense that I continue to represent the Modeling PMC on the Planning Council.

That leaves me in the somewhat awkward position of attending Planning Council meetings wearing two hats:

  1.  As a voting member of the Modeling PMC.
  2.  As a non-voting Eclipse Foundation Representative/Contractor.

I'll refrain from voting on issues where I feel there might be perceived to be a conflict of interest.


In terms of the spreadsheet I agree that it looks very good.

Like you I have some general comments.  Firstly I don't think the Planning Council is a management body so I don't think the Planning Council needs to manage in detail how/what resources are assigned to work on specific line items.   With most issues, sizing will depend who is doing the work and what their qualifications are for that task.  Do we really feel we are obligated to size the work?

I think there is low hanging fruit for marketplace cleanup based on the existing automated reporting.  But even here, sending emails to 100 people also needs to be automated; I'm not sure how the Foundation staff managed that during the previous cleanup cycle.  We also need to be sensitive to the fact that the testing process itself may have errors, e.g., perhaps there is an issue with missing certificates in the specific JRE being used...  (And I think there is a replacement for the current MPC REST services in the works too.)

For the generalized PGP support, I cannot currently estimate that because I do not know what will all be involved.  I know from past experience that p2 dialogs and such often do not work without a Workbench, therefore requiring specialization (and there isn't much in the way of API).  I also see bugs such as this one coming up:

I'm not sure how and where this information is being stored.  But again, from past experience these things tend to be stored in instance scope or in configuration scope, neither of which are helpful locations because each of those involve duplication.  Quickly at the Gerrit, I think this is being stored in some file that could/would be shared by the installer and by all installations so hopefully that's the case.  But does the new preference page really need to be an IWorkbenchPreferencePage?  (The init method is a no-op, so I guess it won't hurt.)  In any case, it's difficult to keep up with such a moving target during this phase of its development.

And finally, yes, in terms of duplication of bundles, I think many projects have a very hard time simply doing builds.  There are always changes to something that make builds stop working and no one really wants to spend time on builds in the first place.   That is one of the huge challenges for SimRel: simply getting projects to contribute up-to-date content.  I hope to work more closely with the various teams to understand better the common challenges...  What could "we" do to make doing builds, doing releases, and contributing to SimRel less painful?


On 11.11.2021 02:11, Jonah Graham wrote:
Hi Martin,

I think this spreadsheet is excellent.

I would change a couple of things:
1) A bit too much seems to come under the "release engineer" umbrella - I think that long term those items can/should be there, but in the short term there is technical debt that should be picked up. This applies marketplace + redundant libraries entries.
2) I don't think updating the installer for PGP should be under the release engineer - it is a shorter term specific contract. Of course the actual release engineer may be best suited for this job. This is somewhat the same argument as (1)
3) In light of the above, I would put in some initial estimates for what kind of contract work it is to clean those things up. 
 - cleanup marketplace, catchup is a matter of days or less, because Ed has done the heavy lifting. This assumes a blanket / automated approach. The debt part of this could grow much further because even installable projects may (and many probably do) fail to do anything useful at runtime. This is particularly evident with things that access internal APIs of Eclipse Platform, they install fine, but fail at runtime.
- pgp installer - Ed - how much work is this?
- remove redundant versions - start with JNA and JAXB redundancies - I have spent plenty of time on these myself and I think the big job is getting individual under resourced projects up to speed again (ECF for JNA and Mylyn for JAXB). There are probably other libraries, but I don't know what they are off the top of my head.


Jonah Graham
Kichwa Coders

On Fri, 5 Nov 2021 at 15:17, Martin Lippert <mlippert@xxxxxxxxx> wrote:

As discussed in the previous planning council call, I started to assemble a list that we will present to the IDE WG steering committee:

I took the high-priority items from the voting that we did a while ago from:

I tried to turn this into a list for the IDE WG with concrete actions and suggestions what we from the planning council perspective want - in the hope that we can dive into a mode of actually getting things done… :-)

Let me know what you think. Feedback welcome (via comments, edits, or extra columns, whatever you prefer). The doc is open for everybody.

We would like to present this to the IDE WG steering committee on their next call (Nov 16), so lets try to get some agreement in place from the planning council side soon… ;-)


_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top