[
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
|
Jonah,
As a general FYI for the Planning Council:
https://blogs.eclipse.org/post/paul-buck/welcome-ed
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:
- As a voting member of the Modeling PMC.
- 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:
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.
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?
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
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