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-distribution.html 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?) -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
