|Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks|
Comments below. On 29.01.2020 12:08, Aleksandar Kurtakov wrote:
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.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.
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.
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.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 :)
* 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.
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!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 .
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+EPPTo 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.
Back to the top