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

Matthew Miller
Fedora Project Leader
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to