Skip to main content

[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

Thanks, Ed, for raising these concerns.

The thread is already at a volume which makes it hard to digest, I can only hope I got the essence of what everybody is thinking.

One way I could interpret the situation is: It takes a very small number of qualified people to herd the train - full-time, and then the immediate issue is resolved. There are member companies for whom it should not be a problem to fund the one appointed train master - perhaps via the foundation. I'd love to see Ed's efforts to be compensated in a way which would allow him to give us a long term perspective. I don't represent a member company so I can't comment on whether and how this simple idea could be put to action.

I assume all of us subscribed to cross-projects have a shared interest in providing to our users plenty of options of which software they want to install, in various combinations, and all in the latest and greatest version. Without bad surprises on their way. Please, those who want to do away with SimRel: tell me, what efforts are incurred by SimRel that or not essential for this original goal? If SimRel incurs non-essential efforts, produces accidental complexity, shouldn't we just name these, so we can fix things (process? automation?). (Disclaimer: I don't care about packages because a simrel repo + various oomph setups are all I need to get the Eclipses I want, or to push the same to colleagues in the company). (Disclaimer 2: I don't hate the cbi aggregator, I prefer to fix it when there's a problem).

For a thought experiment wrt the release cadence: is it possible our cadence is still too slow? Imagine a truly continuous SimRel. Perhaps, SimRel contributions should happen *always*, i.e., whenever a project has any code changes, or buffered to once per day. Some contributions will break downstream projects, which have the option to react, or drop out after 3 build failures. If your dependency drops out, you will notice immediately. Some version bumps, dependency changes will need coordination, here on cross-projects, but they will just happen at their own timing, not driven by release dates. In a world where so many tasks can be automated, isn't the continues flow of all seeing each others HEAD the simplest model of all?

In this model, SimRel (or should we call it SimFlow) would concentrate on ensuring that our components stay on track wrt compatibility with each other. The other concern about more regressions due to shorter cycles and no maintenance branch would still need to be discussed but that's probably a different discussion. That discussion could well suggest a much slower cadence, but perhaps that is even possibly *on top* of a continues SimFlow.

Just brain storming ...


Back to the top