[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks
|
Aleksandar,
Comments below.
On 29.01.2020 13:23, Aleksandar
Kurtakov wrote:
Comments below.
On 29.01.2020 12:08, Aleksandar Kurtakov wrote:
>
> Let's add that I fully stand by Mickael here and his
proposal is the
> only one we got so far with a potential to improve the
situation.
As I mentioned in my reply to Mickael, the proposal is
mostly juggling
the locations of the problems, not eliminating the
underlying problems,
though likely reducing the problems by virtue of reducing
the number of
involved projects.
I have never even thought that this will fix the
underlying problems. But reducing them gives some fresh air
and time(!) so we can actually look at how to actually fix
them. Keeping the status quo means all of our time goes into
preserving it .
Yet even this is non-trivial work that must be done by someone.
Let me give another example - we have spent months on
getting api tools, version checks, even new compile warnings
fail gerrit verification jobs for platform. This came at a
cost - a number of third party dependencies (Lucene, Felix ,
Batik ...) haven't been updated regularly. But now that
these checks are in line and every single patch is verified
to not break these things (that used to cost weeks per
release) we are full steam ahead on improving the situation
as we are no longer paying the time price to do it manually.
Yes, I'd like to see the same thing happen for SimRel, whatever form
that its in or it becomes. But this comes at a cost and the
question is how best to minimize that cost and who will bear it?
If that means we get EPP+simrel shrinked to some bare
minimum so we can automate things and whoever wants to add
something adheres to more and automated(!) checks - it's
totally worth it.
I don't think size affects the cost of automating the checks.
Though size will likely reduce the number of things that fail the
checks.
> We have to just admit that Simrel and EPP can't
continue in the way
> they are and look out for changes that will improve the
situation.
I don't agree. I would argue that train aggregate's value
is not merely
to install EPP packages, but rather to provide one-stop
shopping for a
consistent set of features that will function cohesively.
But it's fair
to argue, "I don't care about that so I won't invest my
resource in
that". Nevertheless, I do see value in that, and have been
investing
resource in that.
> From Ed's proposal:
> * Choice 1 - let's be realistic and admit that this
would not happen.
> No one will step up and do things the way they used to
be just because
> someone is used to it being that way E.g. If I (or
anyone from my
> team) step up - we will effectively implement the
proposal. Of course
> anyone is free to jump in and keep things the way they
are - I'll be
> more than happy to be proven wrong here :)
I would be happy to step in if I were able to continue to
pay my bills
in some way that was directly or indirectly related to the
investment of
my effort.
And many others but I don't see anyone offering it.
That's why I call it unrealistic until we actually see
someone offering it.
Indeed. Yet I persevere, though for how long?
Of course I don't see anyone else stepping forward either. Just
the proposal to throw away as much as possible to make doing this
horrible, frustrating, thankless grunt work a bit less
unattractive than it is currently, along with some +1s to back
that point of view.
+1s and proposals aren't actions. So to date, I am the only one
who has taken action.
> * Choice 2 - speak to representatives. From all the
> Planning/Architecture council meetings there used to be
a lot of
> wishful thinking over the years and pretty much no one
there spent the
> time/resources to make it happen. Read this as - we
don't need talks,
> we need actions.
I've prompted the board the take action but without further
prompting it
is indeed just so many words and so little action.
> * Choice 3 - do nothing . I understand this is meant to
be provocative
> and I fully support some stress over the community. We
should start
> questioning every single piece of our process and if it
has resource
> issues consider it ineffective or not needed before
trying to solve
> it. For many of the existing plugins that are part of
the Simrel that
> would be the best to do - nothing.
Yes, I intend to make people realize that this is basically
what
everyone is doing and has been doing.
> Well actually do single step - remove them.
> To use DLTK project - we did exactly that - dropped
the python (Pydev
> is better offering!), ruby (Solargraph is better
offering!), shell
> script (ShellWas is better offering), js
(WildWebDeveloper is better
> offering) from the December release.
> To use CDT project - launchbar and templates repo are
merged into
> main one to reduce cycles. Terminal is getting moved to
CDT so RSE can
> finally be left to rot there. Ancient parsers are
getting dropped and
> so on.
> I'm not even going to mention the amount of work and
automation that
> went on Platform and Tycho side .
Yes, I'm well aware of how much work it is just contributing
quality
content to SimRel for my own projects. I'm sure this is a
huge effort
for a great many, hence the cries for doing fewer releases.
But the
platform drives and that drives the rest of us and we have
far less
resource than does the platform!
Interestingly enough Platform used to be the one of the
most understaffed project and exactly the change to more
releases and faster delivery of user fixes made it better
covered with resources.
Yes, I remember well my time on the board when this issue was raised
and discussed ad nauseum before finally there was progress.
See e.g. Alexander Fedorov - he is one of the
contributors that jumped after the more to frequent
releases. With less frequent releases there will be less
resources on Platform which will bring the ecosystem in even
worse state.
Yes, if you provide a vehicle for immediate gratification, i.e.,
contributions are delivered quickly, more people will be inclined to
take part.
It's not what we (old timers) want - it's what the
greater software world demands to stay relevant. If others
release monthly (e.g. VSCode) this becomes the norm and
failing to show that adaptation throws you out of market as
no new contributor will wait an year to see his fix in a
release. And people move on - such is life - work, personal,
whatever reason so failing to attract new contributors means
project doesn't have many days left IMHO.
I fully agree and understand the benefits. But, as others have
pointed out, this is not without corresponding drawbacks. The
churn of changes is much more likely to result in regressions, and
that adversely impacts the reputation and uptake of the releases.
This has a counter productive impact...
I often think to myself "I wish these people would spend more
time on fixing bugs and less time on changing code style and
deprecating APIs". But I hesitate to say that out loud. I'm
quite sure most contributors would rather work on cool new
features than to fix crappy old bugs and I'm also quite sure that
many people are fixing crappy old bugs too.
> Aka active projects are already actively engaged into
streamlining the
> developer experience so burden is manageable. In my
eyes there is no
> other way but to do that for Simrel+EPP
To me it's a fundamental issue of resource and leadership.
Someone must
lead. Someone must take responsibility. Someone must have
broad,
long-term oversight. Someone must manage and deal with the
removal of
projects and that somone must have the authority to do so.
We agree that strong leadership is needed. Unfortunately
as I see it the community is split between "no change
allowed" and "not spending any time on keeping NAME_YOUR
anachronism".
Indeed getting agreement on any topic is a challenge when everyone's
opinion is equal. Typically he who does the work makes the
decisions.
This is exactly the problem we have been facing in
Platform for years. Finding the balance is tough and the
middle ground usually means neither side is happy which
means it even tougher to manage. That's why the fundamental
measure for success is the contribution increase rate we see
- if there is such we are moving in the right direction (and
there will be wrong steps for sure!) .
Actually I would hope that the fundamental measure of success is the
quality of the deliverable and I do hope that in fact higher
contribution rates improve that measure. Of course question this
comes down to what you mean by success. Active project? Happy
committers and contributors. Happy consumers and users?
One thing I've seen for sure with interns is that if our
totally broken and non-automated build process 10+ years ago
was kind of accepted, the way more simple and automated one
we have right now is accepted worse than before. To me this
means only one thing steps to keep up with tendencies in
software world are not enough to keep up the pace.
It means projects die if they can't keep up. But it also
means that we attract new people and thus have future when
one of us decides to retire :).
So do you guys agree with such leadership?
I think without the involvement of people like you and others from
your organization the platform (and Eclipse) would be in a
disastrous shape, so I am beyond glad of the leadership you
contribute! I appreciate that you speak your opinions openly and
honestly as you see them.
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
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