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