|Re: [eclipse.org-planning-council] 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:
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?
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.
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:https://docs.google.com/spreadsheets/d/1V7LMa0_T7uYPhS1d910R94XNHX7S59Pf-90E4ULLMiw/edit?usp=sharing
I took the high-priority items from the voting that we did a while ago from:https://docs.google.com/spreadsheets/d/1SsbtmbhKp2Q19QeXLRcxk2bWd7U94GgAtiBWuuOpz1M/edit?usp=sharing
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… ;-)
eclipse.org-planning-council mailing list
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