Mickael,
Comments below.
On 29.01.2020 09:09, Mickael Istria wrote:
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.
* packages would still be available -> no loss for users
So at least we agree that packages are needed. Unfortunately there's no
one to produce them.
* installer 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?
* SimRel and its strange governance and all the discussions that have
emerged with it disappear -> time saved
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.
* EPP starts handing everything, and EPP governance is working well ->
EDP used efficiently.
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.
* 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....).
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?
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.
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?
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've seen that projects are so very very responsive in addressing the
issues raised for them, not!
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
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.
Cheers,
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
