Re: [epp-dev] 2020-12 - Retrospective

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Comments below:

> On Dec 17, 2020, at 05:20, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> EPP is certainly a primary consumer, but Eclipse projects and many others in the ecosystem build Eclipse products based on content consumed from the simultaneous release repository.

+1

I am a consumer of the release repository to build distribution/packages. Having to keep track of individual projects manually is painful. I already see that with "new" projects. They release more often outside the SimRel repository and seem to deliberately ignore backwards compatibility. This makes it hard and expensive to integrate them into the release process.

> That we're only now starting to see serious cracks is a testament to a system (and the designer of that system) that has served us and, with some investment, will continue to serve us.

Bluntly, this is not a new issue. It's a well documented flaw in the underlying technologies that triggered the issue to appear. There is simply a mismatch between runtime constraints and installation time constraints (p2 does not support uses constraints). No matter what process and tools we change, as long as the installation time is predicting a working runtime based on guessing it won't make such issues go away.

Perhaps instead of "killing" something that is totally not the culprit of an issue I'd like to raise awareness of the actual issues:
- flaws in p2 to reliably predict/resolve a working runtime state
- technical debt in project dependencies
- unresponsive projects

We could address the latter two by dropping projects from SimRel. It's an easy fix with a costly downside. It will decrease the value of SimRel and EPP. Those projects were working fine and have users. They are just no longer a (business) priority for their owners. It's sad and if the project really is unresponsive we need to make a hard call - either escalate via EMO and install a fixing patch contributor as committer or remove the project.

The first one needs fixing in p2.

> I am especially concerned that valuable contributors to our years of success are silent in this discussion. If people aren't speaking up, it's not necessarily because they don't care or don't have a different opinion, there's a very high probability that they feel that arguing is futile. I am concerned that an overzealous effort to undo what has taken years to build will drive away our most valuable contributors. Tread carefully and be respectful of the history here. Again, the number of "active contributors" is far larger than I think you understand. Lazy consensus cannot apply in this context.

+1

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/