On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
Our Change process has the basic assumption that if a Change
isn't
working, we will be able to back out. But, in practice, when there are
problems, we often find it that it's easiest to shrug and go forward,
scrambling to fix problems in the change itself as well as any fallout.
I won't say this is a _failure_ exactly — with the Change process, at
least, we do have that checkpoint where we know the scramble is needed
rather than waiting until the very last minute. But, especially if we
are serious about a six-month schedule, it'd be _better_ if we could
simply decide at the Change Checkpoints whether to include the feature
at all.
Arbitrary branching and Modularity give us a way to do this. We can, at
any time, say "this release includes this set of modules" (see
https://docs.pagure.org/modularity/design/constructing/compose-distributi...
and
https://docs.pagure.org/modularity/design/constructing/back-together.html).
I'm really liking what I'm seeing from the Boltron demo, questions
about how to actually manage modules as an end user notwithstanding. If
we can deliver this with minimal end-user disruption and yet give
ourselves capabilities like this, it's a huge success.
(Aside: This possibly involves what the Boltron walkthrough calls
"system profiles". Modularity team! This isn't in the docs yet. Can you
clarify?)
Hm. I agree entirely with you, but when reading this I thought of
another possibility. I think modularity gives people the option for a
rolling release, where we don't have to make release == "collection of
specific module versions". If that's one of the outcomes, then
Changes simply become "this module version is available".
josh