On 06/29/2017 11:30 AM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:
To what extent do we want to encourage "collections of stuff" modules?
Numerically, most modules will likely to be designed to be installed as
containers or flatpaks because that's how we handle conflicting dependencies.
If you leave those modules out, then you really have the constraint that
every package has to be in no more than one module. We can't have
"Matthew's System Tools" and "Owen's System Tools" that are independently
curated, because they can't be enabled on the same system.
Well, we *can*. The question is whether we *should*. :)
I'm kind of on the "we shouldn't" side, but I could be convinced. My
intention is for anything that is in the System Tools module which gets
its own more focused module to be moved out.
So my expectation is that the number of "collections modules" that have
no strong connection to a particular upstream release process will be
small and well defined - say Platform, Runtime, System Tools, and a few more.
As such, I think it *would* be reasonable to say that they all
are versioned at the same tempo and even keep the F<N> stream naming.
Langdon? Rebuttal? :)
I think containers are just a packaging type. In other words, whether
the "thing" is delivered as a docker container, flatpak, rpm,
something-not-though-of-yet, it is still the same module. This is kind
of the point, we want to disconnect the "content needed to provide the
service" from the "packaging mechanism to deliver the content" (very
loosely). As a result, we may see many different module collections of
stuff even if they are only being shipped as containers (or whatever).
So, I am not sure. I think Owen may have a point, but I think whether we
have "many" collections will evolve over time. However, I definitely
would not agree with the f<n> naming because why would it need to
"stream change" because of the fedora base? In other words, a new
stream indicates a new ABI/API but, I can tell you, no matter how many
versions of fedora go by, we are never gonna drop emacs OR vi from the
system-tools type collection so why would the stream change? The module
should be allowed to make decisions on its content based on its own
timescale not an arbitrary release boundary. I think this applies to
"collections of stuff" just as much as the more obvious "single
applications."
I definitely think there are a few more "tightly defined" collections of
stuff as Owen describes. However, I am not sure we have found them all
yet. Something like "system-tools" is definitely one of them and there
may be a few others. That said, I don't think we know which way we will
want to go. I definitely think we want to start on the conservative side
and see how often we run in to "needing exceptions". That said, I think
it is important that we don't encode these types of rules in to our
systems (except as tests which we can disable/modify as the rules change).
Hmmm, I see a couple of issues:
* If we have 'apache' with a stream of 2.4 and 'GNOME Desktop' with a
stream of 3.24, we can't have the stream name be the main way we
convey EOL information. So then it's just confusing that for *some*
modules the EOL is duplicated in the stream name.
* The ability to change the EOL for a stream is quite likely useful -
to decide it will have a longer support lifetime than originally
planned. It would be even more confusing to have *incorrect* EOL's
as the stream name.
* Aren't people in July 2018 going to think f1806 is the current stream,
not a two-year old stream?
Yeah that last one is pretty bad. I think all of this argues for a real
first-class EOL metadata item.
If we need arbitrary stream names that are consistent across Fedora, I think
release dates would be a lot clearer than EOL dates - EOL dates seem more
clever than useful.
Okay, I'm convinced, as long as we can get lifecycle/EOL as a first-class
metadata item.
\o/ ;)
Langdon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
