Mickael,
Retrospectives are helpful. This is an important discussion that we should have.
Please note that the "small group of us who actively contributes" numbers around 200 for just the three months leading up to the 2020-12 release.
I'll state emphatically that the Eclipse Foundation believes that the simultaneous release provides a required service in the generation of the packages. The repository is an important artifact, but so too are the processes and practices behind the creation of the repository. The processes and practices contribute to the overall quality of the products that we present to the world. Further, the simultaneous release repository is consumed in other ways. 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.
I tend to agree that the "collective we" needs to do a better job of pruning out those projects that are not following the rules, find a means to allocate resources for those projects that the collective identifies as critical to our overall success, and otherwise help project teams be successful with the process. Whatever we might consider replacing the simultaneous release repository with will also need some process, and that process will also need to be supported and maintained. Just shutting down the simultaneous release doesn't change this.
The processes that we follow to produce the simultaneous release were established a decade and a half ago; they have served us well, and continue to serve us. 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. I realize that it doesn't necessarily make sense to continue to do something a certain way just because you've always done it that way, but it also doesn't make sense to just throw away a massive amount of investment because it's starting to show a few cracks.
I'll point out that, while strictly speaking, the simultaneous release and the package are separate things, they are actually tightly coupled parts of a single overall process, with many contributors playing roles in both parts. The notion of the EPP taking "some responsibility of SimRel" makes no sense: if the simultaneous release has a problem, shouldn't we just fix that?
Optimization is good. Shedding useless things is good. But we need to take care to not view this discussion through a myopic lens, and be sensitive to all of the committers and contributors who have invested and continue to invest so heavily in getting us and keeping us where we are today.
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.
I share your hope that most of our users regard marketplace as the means of adding functionality to their installations. Marketplace is a slightly different beast, however, that requires a different sort of care-and-feeding than a purely technical offering, to address a different audience than does the simultaneous release repository. Further, there are many gaps. Marketplace entries supplement; they do not replace the simultaneous release.
Wayne
