| Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks |
Mickael,
Comments below.
Hi Ed,
as I already mentioned in some previous emails, I'd be personally in favor or simply getting rid of SimRel and just evolve EPP to provide both the packages and the necessary artifacts for these packages to work.
Yes, I expected such a note from you...
But it seems to me misguided and not grounded in the factual
reality. It seems mostly based on the the principle/assumption
that moving the problem will simplify the problem or make existing
problems disappear by magic. Currently the train repo is a
prerequisite for producing the packages and it composes a large
set of repositories into a single aggregate at which point a high
level of consistency is checked and ensured. In the end, ensuring
that all the artifacts that comprise each package are coherent
(and stable) does not go away even if somehow the packages were
produced by directly pulling content from something other than the
train repository. Nothing changes with regard to ensuring
consistent licenses, signed content, proper inter-operation,
stable repositories, and mutual instability. In the end, I'm not
even sure if you're suggesting that there needs to be no
aggregation at all, but simply a very large set of direct
references to various project repositories. But I can assure you
that loading 50 repositories instead of 2 when doing an install
will not improve the experience, and that getting n projects to
maintain long-term stable sites is a new problem that will also
turn into yet another cat herding exercise and when it fails (as
all things do on occasion), the users will notice immediately.
It feel as if you've joined the discussion years after all the
reasons for having a train the first place were had, and that you
assume there really are no good reasons because you were not part
of those discussions. So all the reasons need to be reiterated,
at which point you are highly inclined to try to shoot each one
down because they don't fit you current conclusion.
In any case, no matter exactly all the concrete details of what
you are suggesting, the question of who does that work remains the
same one.
My reasons to support that is that:* Marketplace would still be available -> no loss for users
I also pointed out that you could fix your marketplace entry:
https://www.eclipse.org/setups/marketplace/?id=3394048
That hasn't happened and the fully 1/3 of the marketplace entries
are completely broken or somewhat broken. Consistent/correct
marketplace listings is yet another exercise of cat herding.
So at least we agree that packages are needed. Unfortunately there's no one to produce them.* packages would still be available -> no loss for users
Here the question is: Which repositories will contain all the artifacts? How much work will I personally (Oomph) have because of a complete change in design in EPP structure?* installer would still be available -? no loss for users
It will only disappear from view, but the identical technical problems will simply migrate somewhere else. Somewhere decentralized? Somewhere with no central oversight? This doesn't not sound like the problems will go away, but rather will become invisible to most of us, but not for the users.* SimRel and its strange governance and all the discussions that have emerged with it disappear -> time saved
The person who does not exist will restructure everything and will manage everything personally and none of us will have to do anything at all anymore to help that person. That sounds great in principle, except for that person. And I'm often that person, and I can assure you it's not great at all; I often cannot solve problems that come from elsewhere.* EPP starts handing everything, and EPP governance is working well -> EDP used efficiently.
Removing projects from the train will be somewhat helpful in reducing the overhead. We could start with EMF and finish with Oomph; that would save me personally one hell of a lot of work. Or did you have specific projects in mind that are not worth the effort?* Active contributors like you stop spending effort on projects that are not worth it (to you): many projects are in SimRel just by the force of habit, but the value for the user community is arguable and the cost for maintainers is present (more things to check, more bugs to open, more files to watch, longer build time....).
Are you volunteering to step up to prototype and demonstrate all the new infrastructure that would be involved in your proposal so that we may concretely assess how that alternative would work in detail rather than in the abstract?With this proposal, the maintenance cost would be drastically reduced and the process be made more streamlined with typical EDP. Hopefully this will become simple enough for the few active contributors on SimRel (build & infra, not contributions) and EPP to be able to cope with this for some years.
I've seen that projects are so very very responsive in addressing the issues raised for them, not!
About enforcing or checking SimRel rules, then they are not really SimRel rules and checking that or declaring compatibility should be handled by projects, as part of their releases; not by a downstream consumption.
I find this so incredibly misguided. But I know you mean well and you do so very much for the community so I don't want to make what seem like personal attacks. Mostly I just want to cry when I read all this and that makes it difficult to not lash out.
To summarize, making SimRel become a "pull" project like EPP and not a "push" project like it is now is IMO the best path to keep the community able to ship good quality end-users oriented IDE artifacts
Cheers,
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev