Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-ide-wg] Be a founding member of the Eclipse IDE working group

Thanks for sharing the documents.

Just a fix about
Currently the Eclipse Foundation has made decisions like what contents come from SimRel only. Is this decision tree moved to the working group?
While the downloads page is Eclipse Foundation controlled, it is not 100% SimRel as there may or may not be other projects on that page which are not part of the SimRel.  This adds some complexity.  The Eclipse Foundation does not define which packages are on the packages download page.  The community with oversight form the Planning Council defines that.  The working group could lobby to take control of the download page.  

In practice, this is saying the opposite of what has happened in January for the Rust package: EPP and Planning Council were fine keeping this package, and with , Wayne/EF stated
Responsibility to decide which Eclipse IDE packages are distributed as official "Eclipse IDE" releases (e.g., the packages listed on the Eclipse IDE packages download page or are installable via the installer) rests with the Eclipse Foundation. That is, the Eclipse Foundation has (and has always had) responsibility to ensure that the content being distributed as official "Eclipse IDE" releases meets a well-defined standard.
The standard is set by the participation rules of the simultaneous release and following the practices established for the simultaneous release, are in our opinion, the best means of mitigating risk.
In order for a package to be listed as an official "Eclipse IDE" release, displayed on "package" download pages and included in the installer, these rules must be followed:
All features to the package must come through the simultaneous release.
That resulted in the Corrosion package being removed from download page.

While I don't really mind the actual decisions on that matter, it seems like there is some inconsistency here about this particular item. People on this mailing-list who care strongly about that part in their decision or strategy towards the WG (if any, as it's not a big deal nor much a criterion of success in the end IMO) should probably request some clarification to find which one of the statement between call vs mailing-list is the current state of things.

Another thing I want to highlight, as a project lead on various IDE related projects, is that the Working Group is *not* a requirement *nor* a privilege for anyone to invest in particular development on such projects.
An organization that has interest in fixing one particular aspect of a project (performance, feature, icons...) can already do that by investing manpower onto the project or directly hiring contractors to work on the desired projects/items (the community has had a bunch of very skilled individual contributors that can be already hired as contractors for particular tasks). As expected by the Eclipse Developer Process, projects should welcome those changes according to the rules of meritocracy, independently of whether they come from direct contributions, or thought a contractor, from the Working Group, the Eclipse Foundation, some member or whoever else the same. From projects POV, Working Group is not a replacement for meritocracy. I feel it's important that people remind that as my reading of some the Q&As gave me the impression some people could build false expectations.


Back to the top