On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller
> 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
> 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
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".
devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org