On Wed, Jan 29, 2020 at 1:47 PM Ed Merks <ed.me...@gmail.com> 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 . 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. 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. > > * 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. 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. > > 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". 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!) . 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@eclipse.org > 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 Kurtakov Red Hat Eclipse Team
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
