| Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks |
Aleksandar,
Comments below.
On Wed, Jan 29, 2020 at 1:47 PM Ed Merks <ed.merks@xxxxxxxxx> 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.
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?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.
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.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.
> 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.
Yes, I remember well my time on the board when this issue was raised and discussed ad nauseum before finally there was progress.> * 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, if you provide a vehicle for immediate gratification, i.e., contributions are delivered quickly, more people will be inclined to take part.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.
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.
Indeed getting agreement on any topic is a challenge when everyone's opinion is equal. Typically he who does the work makes the decisions.> 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".
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?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!) .
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.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?
_______________________________________________
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
--
Alexander KurtakovRed 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