Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

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 ...

Stephan