On 06/29/2017 01:40 PM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 07:20:15PM +0200, Petr Šabata wrote:
* Such modules MAY additionally have a "latest" stream, which
would be "rolling release" of the latest stable version (as
opposed to master, which corresponds to rawhide and may be
unstable).
Sounds like the no-more-alphas Rawhide. Such "latest" streams
would drop major changes/rebases on the end users' systems.
It makes sense to have this, especially for developers, but
we should warn people that it's not the best choice for stable
systems and that... it will eat their babies ;)
No, this should definitely not eat babies. (Even Rawhide doesn't do
that anymore. Usually.) And while automatic gating would be fine, it
wouldn't need to be.
Given the response above it appears you understand streams
somewhat differently. Until now we've been operating with
the assumption (and everything is coded that way) that streams
map directly to branch names. If you have a "latest" stream,
you develop it in a branch called "latest". If a user consumes
this stream, their automatically get breaking changes because
the "latest stable version" means different things at different
times. Hence the comparison to Rawhide.
It might be somewhat comparable to rawhide, but it definitely shouldn't
be _called_ rawhide, because that implies a tie to either rawhide as it
stands today or a rawhide version of the platform+host. Doesn't it?
Are they bound to the artifact or could that depend on the
context? Like "this module will go EOL next year for standard
Fedora and nobody will care to make it work with the latest
Platform but we'll still support it in the context of this LTS
spin / derived distro / whatnot".
If this is a thing, modularity hasn't really succeeded.
I don't know how to respond to this.
The point of modularity is to separate application and stack lifecycle
from the platform. If we end up with per-platform application and stack
lifecycles in the end, that point isn't achieved at all.
This is partly why I described EOL as "EOL no earlier than" (thanks to
Langdon). I think the best thing to do in the case of a long extension
would be to create a new branch/stream with the new EOL. That's part of
why I think modules need to carry their own succession information,
too.
Making people switch between update streams if the content they
already consume becomes supported for longer doesn't feel like
the best UX decision. EOL shouldn't be tied to stream names.
Ok, I'm convinced on that point. But, EOL shouldn't be changed lightly,
either. Users (and spin/edition creators) should be able to trust
lifecycle statements.
current design. I guess one option would be for master to automatically
correspond to "latest major version, rolling release", but that
seems not as helpful as being explicit. Maybe "master" should just
contain a readme describing the various branches.
Works for me. Right now we use it for random development but
that's because we're just starting with all this.
Is this something that could/should be enforced by policy in MBS?
We actually have some tests in place that enforce some policy (very
lightly at the moment). However, the goal is that whatever we determine
to be "true" in the modularity guidelines is enforced by a system-wide
test(s) on modules whenever they are built. This would be a gating test
where any exceptions to the guideline would have to be registered in the
"waiver system" (which I can't remember the name of in factory).
Langdon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
