Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] list for IDE WG steering committee with concrete actions

On Thu, 11 Nov 2021 at 04:51, Ed Merks <ed.merks@xxxxxxxxx> wrote:

Jonah,

As a general FYI for the Planning Council:

  https://blogs.eclipse.org/post/paul-buck/welcome-ed


Congratulations Ed on the new job!
 

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.


OK.
 

------

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?


The sizing thing came from our last call where we proposed to push more specifically for investments from the IDE WG Steering Committee. There is a bit of a chicken and egg situation going on here on progressing concrete improvements. 


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


I agree - hence Bug 577044 may be a quick fix to address security concern, but a bigger cleanup is longer.
 

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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=577193

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.


This is where we may be ahead of where we were just last week when Martin put this spreadsheet together. The "releng" person is you now, so like we reference above, the chicken and egg on planning this may be helped, assuming that this work falls within the scope of your new position.
 

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?

That is an important question - but still somewhat orthogonal to where we are now as almost anything "we" could do is yet another change. If we get it right, such change means less change in the future.

Jonah


 

Regards,
Ed


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.

HTH
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


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

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… ;-)

Cheers
Martin


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council

Back to the top