On Mon, Aug 7, 2017 at 7:34 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx> 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-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?)
We haven't documented this yet because we have been working through the details of the how it should work. Basically, we need to provide a way, on the system, to define:
a) what the "release" is. In other words, what did the Edition-WG decide should be *installed* by default and what should be *available* by default. For example, less version 487 should be installed, and httpd-2.4 should be available.
b) how to "walk" the streams, hopefully automatically. In other words, if a user makes no changes, how does s/he move from foo:1 -> foo:1.1 (where "1" and "1.1" are different streams) vs foo:1 -> foo:2. And, in a related way, how can s/he choose *not* to follow the guidelines. For example, I am running a simple html website. I want to follow every upgrade to httpd that comes out, assuming it doesn't change it's configuration method (so, auto jump httpd2.4->httpd2.6). However, my php website should stick to httpd2.4.z.
a) what the "release" is. In other words, what did the Edition-WG decide should be *installed* by default and what should be *available* by default. For example, less version 487 should be installed, and httpd-2.4 should be available.
b) how to "walk" the streams, hopefully automatically. In other words, if a user makes no changes, how does s/he move from foo:1 -> foo:1.1 (where "1" and "1.1" are different streams) vs foo:1 -> foo:2. And, in a related way, how can s/he choose *not* to follow the guidelines. For example, I am running a simple html website. I want to follow every upgrade to httpd that comes out, assuming it doesn't change it's configuration method (so, auto jump httpd2.4->httpd2.6). However, my php website should stick to httpd2.4.z.
We think this needs a simple DSL kinda like python requirements, nodejs package, or even like rpm. We needed Boltron to make how this problem is expressed "real." I am glad the question is coming up ;)
Please join us at the Modularity WG meeting[1] to discuss.
[1]: https://apps.fedoraproject.org/calendar/modularity/
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".
Exactly. See my "httpd for simple html" example above. You could choose to walk all new streams automatically. Or you could choose for just some things. However, you would know that everything individual module works as a unit before it it is declared deliverable. Rather than traditional rolling which just updates the pieces as soon as they are ready, irrelevant of the consumers being ready.
Langdon
josh
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
