3:07 p.m.
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
doesn't have any rules, so let's make one. Specifically:
* Modules which correspond primarily to a single application or
versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
use a stream label corresponding to the major version of that software
(e.g. 2.4 or 8)
* 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).
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense if
we get
to my dream of mixing and matching with CentOS modules....)
Additionally and for all of our sanity, I suggest:
* Valid module end-of-life dates are always either June or December,
corresponding to the Fedora schedule of early May / late October
base releases. So, f1806 or f1812, but not f1810 or f1901.
I know there is some work on stream-to-stream upgrades in modularity;
that work could take advantage of this convention.
So, we'd have:
httpd 2.4
httpd 2.6
nodejs 8
nodejs 10
sysadmin-tools latest
sysadmin-tools f1812
sysadmin-tools f1906
Does this make sense? Do you have improvements or entirely better
ideas?
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
With this alternate proposal, we'd have:
httpd 2.4:stable
httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
nodejs 8:f1912 (because that's upstream eol)
nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
nodejs 10:f2106 (or maybe e2012)
sysadmin-tools 1:latest
sysadmin-tools 1:f1812
sysadmin-tools 1:f1906
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:26 a.m.
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
doesn't have any rules, so let's make one. Specifically:
I see those guidelines need to be updated to match reality.
/me makes a note to review them.
* Modules which correspond primarily to a single application or
versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
use a stream label corresponding to the major version of that software
(e.g. 2.4 or 8)
So if I'm reading this correctly, you're proposing Fedora should
forbid packagers from creating alternative streams for the same
major release of such software? I can imagine different variants
of httpd 2.4, built with different compile time options, bundling
different components, having different module metadata and such.
I agree there should be some recommendations on stream naming
but this feels far too strict for no reason.
* 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 ;)
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
+1
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
There are still some open questions regarding EOLs.
For instance:
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".
Can EOL be extended for already released artifacts and if so, do
we need to issue an update to let users know through refreshing
their metadata?
Answers to these questions help us decide whether EOL metadata
should be bundled with the module, inside modulemd in the
repodata, or whether it belongs in an external system such
as PDC.
It also affects many other things all over the place such as
UX, system profiles or extended module dependency selectors.
It's not as simple as it may sound.
Each such "collection" module MUST have one or both of the
following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
By the way, should rawhide streams be called rawhide or would
master be fine? Stream names come directly from dist-git branch
names but of course there could be a hardcoded exception in
MBS that does s/master/rawhide/.
Just bikeshedding.
* One or more streams corresponding to "end of life no earlier
than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense
if we get
to my dream of mixing and matching with CentOS modules....)
See my EOL-related points above. Plus this would be ugly :P
Additionally and for all of our sanity, I suggest:
* Valid module end-of-life dates are always either June or December,
corresponding to the Fedora schedule of early May / late October
base releases. So, f1806 or f1812, but not f1810 or f1901.
Sounds like a valid recommendation rather than a necessary rule.
I know there is some work on stream-to-stream upgrades in
modularity;
that work could take advantage of this convention.
So, we'd have:
httpd 2.4
httpd 2.6
nodejs 8
nodejs 10
sysadmin-tools latest
sysadmin-tools f1812
sysadmin-tools f1906
Does this make sense? Do you have improvements or entirely better
ideas?
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
I like simple integer approach and it feels natural from an
engineer's point of view. I think. I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.
Like "tools 2017", "tools 2017.6". *shrugs*
But I don't really have a preference.
I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules. No matter where
the tools get it from.
":" is one of the symbols still considered for name:stream
separation, if it's going to change from the "-" used currently.
I also like the idea of a stable marker. Not only users but
even the pipeline needs to know.
Anyway, thanks for doing this,
P
With this alternate proposal, we'd have:
httpd 2.4:stable
httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
nodejs 8:f1912 (because that's upstream eol)
nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
nodejs 10:f2106 (or maybe e2012)
sysadmin-tools 1:latest
sysadmin-tools 1:f1812
sysadmin-tools 1:f1906
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
10:07 a.m.
On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> * Modules which correspond primarily to a single application or
> versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
> use a stream label corresponding to the major version of that software
> (e.g. 2.4 or 8)
So if I'm reading this correctly, you're proposing Fedora should
forbid packagers from creating alternative streams for the same
major release of such software? I can imagine different variants
of httpd 2.4, built with different compile time options, bundling
different components, having different module metadata and such.
I think alternate versions are okay, but those should come after a
primary version -- there should be *at least* this and then there could
be others.
In thinking a little further, I think there are three basic bits of
metadata that need to be easily visible per-stream. Whether it goes
into the stream label or into other metadata is an implementation
detail. They are:
* major identifier (in the case of modules with a primary piece of
software, probably the major version of that software)
* lifecycle / eol identifier
* extra tags describing alternate options
So, for example:
nodejs 8:e1912 (or maybe 8:e1912:main, but I don't like that)
nodejs 8:e1806:turbocharged
nodejs 8:e1912:lite
httpd 24:stable
httpd 26:latest
httpd 24:e1812:spdypatches
> * 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.
There are still some open questions regarding EOLs.
For instance:
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.
Can EOL be extended for already released artifacts and if so, do
we need to issue an update to let users know through refreshing
their metadata?
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.
Answers to these questions help us decide whether EOL metadata
should be bundled with the module, inside modulemd in the
repodata, or whether it belongs in an external system such
as PDC.
Right. :)
> * A "latest" rolling stream (As above, this would be
separate from
> "rawhide", as "latest stable", but could update frequently
and
> arbitrarily.)
By the way, should rawhide streams be called rawhide or would
master be fine? Stream names come directly from dist-git branch
names but of course there could be a hardcoded exception in
MBS that does s/master/rawhide/.
There's two big things here. First, it absolutely shouldn't be rawhide.
That's the same as having f26 or f27 branches: tied to a particular
base.
Second, though, if we have all the various different variants per
stream as you describe above, does it even make sense to _have_ a
master branch? Which variants would it be the master _for_? This might
suggest that long-lived and very distinct streams should actually have
a different _name_ and live in a different repo in dist-git, with
streams in the same repo required to be closely linked in some way.
I'm not sure I like that, though, and it seems very contrary to the
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.
> * One or more streams corresponding to "end of life no
earlier than",
> in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"?
Or "uYYMM" for
> 'until'? Or "fYYMM" for 'fedora' — which might make
sense if we get
> to my dream of mixing and matching with CentOS modules....)
See my EOL-related points above. Plus this would be ugly :P
Uglier than a bunch of random names with no semantic relation? I'm not
so sure!
> Additionally and for all of our sanity, I suggest:
> * Valid module end-of-life dates are always either June or December,
> corresponding to the Fedora schedule of early May / late October
> base releases. So, f1806 or f1812, but not f1810 or f1901.
Sounds like a valid recommendation rather than a necessary rule.
I'm gonna argue for rule. As a user, a situation where modules are
arbitrarily EOLing every day seems nightmarish.
[And I'm going to reply to the second half of this in a separate
message.]
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:20 p.m.
On Thu, Jun 29, 2017 at 11:07:10AM -0400, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> > * Modules which correspond primarily to a single application or
> > versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
> > use a stream label corresponding to the major version of that software
> > (e.g. 2.4 or 8)
> So if I'm reading this correctly, you're proposing Fedora should
> forbid packagers from creating alternative streams for the same
> major release of such software? I can imagine different variants
> of httpd 2.4, built with different compile time options, bundling
> different components, having different module metadata and such.
I think alternate versions are okay, but those should come after a
primary version -- there should be *at least* this and then there could
be others.
Okay. Then it needs to be worded differently.
In thinking a little further, I think there are three basic bits of
metadata that need to be easily visible per-stream. Whether it goes
into the stream label or into other metadata is an implementation
detail. They are:
* major identifier (in the case of modules with a primary piece of
software, probably the major version of that software)
* lifecycle / eol identifier
* extra tags describing alternate options
So, for example:
nodejs 8:e1912 (or maybe 8:e1912:main, but I don't like that)
nodejs 8:e1806:turbocharged
nodejs 8:e1912:lite
httpd 24:stable
httpd 26:latest
httpd 24:e1812:spdypatches
EOL's not part of modulemd today for the reasons I mentioned
in my previous email (we don't know if that's the way to go)
but can be added if we finally make that decision.
The extra tags are meant to be part of the stream name today.
The intention was to have stream names more descriptive and
less version-y. Splitting streams into main package versions
and some additional tags would require some changes to how we
handle dist-git-branch-name-to-modulemd-fields mapping.
> > * 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.
And I knew you would respond to the babies bit ;)
> There are still some open questions regarding EOLs.
>
> For instance:
>
> 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.
> Can EOL be extended for already released artifacts and if so,
do
> we need to issue an update to let users know through refreshing
> their metadata?
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.
> Answers to these questions help us decide whether EOL metadata
> should be bundled with the module, inside modulemd in the
> repodata, or whether it belongs in an external system such
> as PDC.
Right. :)
> > * A "latest" rolling stream (As above, this would be separate from
> > "rawhide", as "latest stable", but could update
frequently and
> > arbitrarily.)
> By the way, should rawhide streams be called rawhide or would
> master be fine? Stream names come directly from dist-git branch
> names but of course there could be a hardcoded exception in
> MBS that does s/master/rawhide/.
There's two big things here. First, it absolutely shouldn't be rawhide.
That's the same as having f26 or f27 branches: tied to a particular
base.
Second, though, if we have all the various different variants per
stream as you describe above, does it even make sense to _have_ a
master branch? Which variants would it be the master _for_? This might
suggest that long-lived and very distinct streams should actually have
a different _name_ and live in a different repo in dist-git, with
streams in the same repo required to be closely linked in some way.
I'm not sure I like that, though, and it seems very contrary to the
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.
> > * One or more streams corresponding to "end of life
no earlier than",
> > in the format "YYMM". (Or "eolYYMM"? Or
"eYYMM"? Or "uYYMM" for
> > 'until'? Or "fYYMM" for 'fedora' — which might
make sense if we get
> > to my dream of mixing and matching with CentOS modules....)
> See my EOL-related points above. Plus this would be ugly :P
Uglier than a bunch of random names with no semantic relation? I'm not
so sure!
> > Additionally and for all of our sanity, I suggest:
> > * Valid module end-of-life dates are always either June or December,
> > corresponding to the Fedora schedule of early May / late October
> > base releases. So, f1806 or f1812, but not f1810 or f1901.
> Sounds like a valid recommendation rather than a necessary rule.
I'm gonna argue for rule. As a user, a situation where modules are
arbitrarily EOLing every day seems nightmarish.
[And I'm going to reply to the second half of this in a separate
message.]
Ok :)
P
12:40 p.m.
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?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:17 a.m.
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
10:19 a.m.
On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> I have an alternate idea too: "collection" type
modules would
> use arbitrary integer versions starting with 1 and increase only if the
> content undergoes a major switch. ALL module streams would contain EOL
> information after the version number separated by a ":". This EOL info
> would be a date as above, or the string "latest", _or_ the string
> "stable", indicating that no abi-breaking changes are expected ever and
> that we basically have no known EOL.
I like simple integer approach and it feels natural from an
engineer's point of view. I think. I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.
Like "tools 2017", "tools 2017.6". *shrugs*
But I don't really have a preference.
I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules. No matter where
the tools get it from.
I really, really don't want anyone creating new modules without
considering lifecycle. Forcing it into the stream name is:
a) one way to force that, and
b) possible now without changing the tooling.
How hard would it be to get EOL into the spec and prominently displayed
in DNF and whatever compose tools? And, perhaps more saliently, how
quickly could it be done?
":" is one of the symbols still considered for name:stream
separation, if it's going to change from the "-" used currently.
That's not necessarily a problem, as long as it's defined as "the first
: separates name from stream" and : isn't allowed in name. But I'm not
hung up on the particular symbol.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:27 a.m.
On Thu, Jun 29, 2017 at 11:19 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> > I have an alternate idea too: "collection" type modules would
> > use arbitrary integer versions starting with 1 and increase only if the
> > content undergoes a major switch. ALL module streams would contain EOL
> > information after the version number separated by a ":". This EOL
info
> > would be a date as above, or the string "latest", _or_ the string
> > "stable", indicating that no abi-breaking changes are expected ever
and
> > that we basically have no known EOL.
> I like simple integer approach and it feels natural from an
> engineer's point of view. I think. I can also imagine using
> years or years.months, depending on how often the module
> maintainer decides to release a new... thing.
>
> Like "tools 2017", "tools 2017.6". *shrugs*
> But I don't really have a preference.
>
> I wouldn't include EOL directly in the stream (i.e. branch)
> name but I totally agree it needs to be prominently displayed
> in any user interface that deals with modules. No matter where
> the tools get it from.
I really, really don't want anyone creating new modules without
considering lifecycle. Forcing it into the stream name is:
I agree with lifecycle being required. I disagree completely with it
being in the stream name. It doesn't make sense at all for a large
variety of reasons. It's a cheap hack to get what you really want,
and I think it's just going to incur technical debt we should avoid in
the first place.
Modularity is new. It's different. It will be hard at first. Let's
not hamstring ourselves from the start.
josh
11:24 a.m.
On 06/29/2017 11:27 AM, Josh Boyer wrote:
On Thu, Jun 29, 2017 at 11:19 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
>>> I have an alternate idea too: "collection" type modules would
>>> use arbitrary integer versions starting with 1 and increase only if the
>>> content undergoes a major switch. ALL module streams would contain EOL
>>> information after the version number separated by a ":". This EOL
info
>>> would be a date as above, or the string "latest", _or_ the string
>>> "stable", indicating that no abi-breaking changes are expected ever
and
>>> that we basically have no known EOL.
>> I like simple integer approach and it feels natural from an
>> engineer's point of view. I think. I can also imagine using
>> years or years.months, depending on how often the module
>> maintainer decides to release a new... thing.
>>
>> Like "tools 2017", "tools 2017.6". *shrugs*
>> But I don't really have a preference.
>>
>> I wouldn't include EOL directly in the stream (i.e. branch)
>> name but I totally agree it needs to be prominently displayed
>> in any user interface that deals with modules. No matter where
>> the tools get it from.
> I really, really don't want anyone creating new modules without
> considering lifecycle. Forcing it into the stream name is:
I agree with lifecycle being required. I disagree completely with it
being in the stream name. It doesn't make sense at all for a large
variety of reasons. It's a cheap hack to get what you really want,
and I think it's just going to incur technical debt we should avoid in
the first place.
Modularity is new. It's different. It will be hard at first. Let's
not hamstring ourselves from the start.
josh
_______________________________________________
devel mailing list --devel(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
As I said to Matt on IRC, I agree with the point that metadata should
*not* be encoded in "yet another string" like "name" has been used for
a
long time. We need to be very careful of this problem as it is
*incredibly* tempting to use our years of experience with doing this to
basically introduce the problem again. We need to add metadata labels
for new metadata when we need it. We need to try VERY hard not to use
any string to hold more than one piece of metadata. TBH, I fell in to
that trap myself when first talking about it to Matt.
I also am not the biggest fan of the "stream" being a user-defined
thing, rather, I wish it could be something that is more like a computed
amalgamation of the other metadata (this is kinda what Nix does).
However, I am still on the fence on this. Stream != name.. and name is
where "lamp with httpd" kinda belongs.
As I said in another part of the thread (/me hates thread splitting), we
fully expect to have guideline enforcement gating release of modules. We
can very easily require that EOL be provided (whether it be modulemd,
pdc, or something else) as part of that test. In fact, we have planned
for it to be there all along and prominently displayed in UX tools (one
of the very early dev topics). However, the problem of "how to store it"
has come up multiple times because it is HARD. I am also not sure EOL is
something we can just plop in somewhere and then fix it later. So, your
concerns are very valid and well understood, we just haven't figured out
exactly how to solve it. Current plan is PDC along with SLA but I would
need to follow up with Ralph, et al to know if that part got implemented
yet.
Langdon
9:49 a.m.
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
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.
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.
But certainly there are other fine ways of doing it.
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense
if we get
to my dream of mixing and matching with CentOS modules....)
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?
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.
Owen
10:30 a.m.
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? :)
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:39 p.m.
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
12:55 p.m.
On Thu, Jul 06, 2017 at 01:39:35PM -0400, langdon wrote:
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
The system-tools comps group as definied has an awkward mix of
command-line utilities, GUI apps, and things that are actually services
(like incron). I think we should make this module *just* command-line
utilities. Services should *probably* get their own individual modules.
I don't know about GUI apps.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:58 p.m.
On Thu, 2017-07-06 at 13:39 -0400, langdon wrote:
On 06/29/2017 11:30 AM, Matthew Miller wrote:
> On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:
> > 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).
I think you make different decisions depending on how you expect your
module to be packaged/deployed.
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."
But dropping emacs out of the system-tools collection would only be one
form of ABI/API breakage. The following can also be breakages:
* Upgrading a package, if the package changes its ABI, API,
configuration files or command line options.
* Adding a new package (the new package may conflict with packages
from other modules with unpredictable results)
And if module A depends on module B, and module B changes its ABI/API,
that also effectively changes the ABI/API of module A in the general
case.
One of the main ways we have of handling this fragility is to
distribute in a container (or container-like thing). If you design for
distributing in a container, and always distribute in a container, then
consumers can ignore a lot of things that happen inside the module.
But for a module that is not containerized, that has a lot of packages
in it, that depends on the Fedora Platform module, I think that the
only realistic model that provides API/ABI stable streams is to release
new streams often, probably in sync with the Platform model, and not
change the streams much after release.
Whether those streams are called F<n> or 201806 or whatever is a
somewhat arbitrary choice.
Owen
2:29 p.m.
On 07/06/2017 02:58 PM, Owen Taylor wrote:
On Thu, 2017-07-06 at 13:39 -0400, langdon wrote:
> On 06/29/2017 11:30 AM, Matthew Miller wrote:
>> On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:
>>> 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).
I think you make different decisions depending on how you expect your
module to be packaged/deployed.
> 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."
But dropping emacs out of the system-tools collection would only be one
form of ABI/API breakage. The following can also be breakages:
* Upgrading a package, if the package changes its ABI, API,
configuration files or command line options.
* Adding a new package (the new package may conflict with packages
from other modules with unpredictable results)
And if module A depends on module B, and module B changes its ABI/API,
that also effectively changes the ABI/API of module A in the general
case.
One of the main ways we have of handling this fragility is to
distribute in a container (or container-like thing). If you design for
distributing in a container, and always distribute in a container, then
consumers can ignore a lot of things that happen inside the module.
But for a module that is not containerized, that has a lot of packages
in it, that depends on the Fedora Platform module, I think that the
only realistic model that provides API/ABI stable streams is to release
new streams often, probably in sync with the Platform model, and not
change the streams much after release.
I think the modules:
a) need to assume, as much as possible, that they are independent from
all other modules that they don't depend on. We may need to provide some
tooling that makes this "true" but that is ok
b) a module should depend on as few other modules as possible, in other
words, just host&plat and shared-userspace. Otherwise, your lifecycle,
as you say, is bound to the other module.
I think you are probably right, at first. However, I expect, over time,
that this will shift. Either more things will be containerized, the
dependency set will get cleaner, better bundling methods will be
supported, etc.
Whether those streams are called F<n> or 201806 or whatever is a
somewhat arbitrary choice.
so ^^ yes.. but as in the rest of this thread.. I
strongly disagree with
the perception of binding to a "release" even if, for some period of
time we most of the time do. If we don't carefully & quickly move away
from the "release" terminology, the flexibility will be lost because
people will think there is a requirement of a lock when there may not,
in fact, be.
Langdon
Owen
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:21 p.m.
On 29/06/17 15:49, Owen Taylor wrote:
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
...
>
> * One or more streams corresponding to "end of life no earlier than",
> in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
> 'until'? Or "fYYMM" for 'fedora' — which might make
sense if we get
> to my dream of mixing and matching with CentOS modules....)
Hmmm, I see a couple of issues:
...
* Aren't people in July 2018 going to think f1806 is the current stream,
not a two-year old stream?
...
Owen
Also, there would be a big potential for one-off confusion* in a year or
two when people are seeing e2006, e2012, f2012, or whatever, and get the
impression that they're looking at seven or twelve year old releases,
instead of the latest.
* Well, for the next 101 years, anyway.
--
J. Randall Owens | http://www.GhiaPet.net/
1:25 p.m.
On Wed, Jun 28, 2017, at 10:07 PM, Matthew Miller wrote:
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
doesn't have any rules, so let's make one. Specifically:
* Modules which correspond primarily to a single application or
versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
use a stream label corresponding to the major version of that software
(e.g. 2.4 or 8)
* 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).
Does this mean that a module built primarilly from a single application
does not have a 13 month fixed lifecycle? I hope this is true because,
in my mind, one of the things a module is promising is that some form of
API/ABI won't break. When I hear Apache-2.4, I think, "this module is
apache 2.4. I don't need to know the z-release because I know the 2.4
API won't be broken." I also think that having an arbitrary EOL for the
stream of 13 months even though Apache 2.4.x will continue to be
available after that is odd. What changed causing the need to EOL the
stream I was on and replace it with a new Apache-2.4 stream? Have I
just misunderstood modules?
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
What is changing from one collection version to the next? What is my
understanding of what is in the box at any moment in time? If the
module is tied to a specific host/platform then I would expect it to
carry that information in the metadata (see below). If it isn't, what
change prompts a new version? I think that is what we need to define as
well.
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense
if we get
to my dream of mixing and matching with CentOS modules....)
I'll be brief as some others have touched on this already, but, as jwb
said, "Modularity is new. It's different. It will be hard at first.
Let's not hamstring ourselves from the start."
Along these lines, I'd like to see us encode less in the name and more
in the metadata. I'd like our tools to be metadata consumers, not name
parsers. I believe it is reasonable to make some query the
stream/module/object and not just expect to read the information they
want in an FTP listing. For all of these reasons, I think streams could
just be X-version and X-latest.
regards,
bex
>
> Additionally and for all of our sanity, I suggest:
>
> * Valid module end-of-life dates are always either June or December,
> corresponding to the Fedora schedule of early May / late October
> base releases. So, f1806 or f1812, but not f1810 or f1901.
>
> I know there is some work on stream-to-stream upgrades in modularity;
> that work could take advantage of this convention.
>
> So, we'd have:
>
> httpd 2.4
> httpd 2.6
> nodejs 8
> nodejs 10
> sysadmin-tools latest
> sysadmin-tools f1812
> sysadmin-tools f1906
>
> Does this make sense? Do you have improvements or entirely better
> ideas?
>
> I have an alternate idea too: "collection" type modules would
> use arbitrary integer versions starting with 1 and increase only if the
> content undergoes a major switch. ALL module streams would contain EOL
> information after the version number separated by a ":". This EOL info
> would be a date as above, or the string "latest", _or_ the string
> "stable", indicating that no abi-breaking changes are expected ever and
> that we basically have no known EOL.
>
> With this alternate proposal, we'd have:
>
> httpd 2.4:stable
> httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
> nodejs 8:f1912 (because that's upstream eol)
> nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
> nodejs 10:f2106 (or maybe e2012)
> sysadmin-tools 1:latest
> sysadmin-tools 1:f1812
> sysadmin-tools 1:f1906
>
>
> --
> Matthew Miller
> <mattdm(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:35 p.m.
On Thu, Jun 29, 2017 at 08:25:59PM +0200, Brian Exelbierd wrote:
Does this mean that a module built primarilly from a single
application
does not have a 13 month fixed lifecycle? I hope this is true because,
in my mind, one of the things a module is promising is that some form of
API/ABI won't break. When I hear Apache-2.4, I think, "this module is
apache 2.4. I don't need to know the z-release because I know the 2.4
API won't be broken." I also think that having an arbitrary EOL for the
stream of 13 months even though Apache 2.4.x will continue to be
available after that is odd. What changed causing the need to EOL the
stream I was on and replace it with a new Apache-2.4 stream? Have I
just misunderstood modules?
I think it's likely that we would want an Apache 2.4 module to have a
longer-than-13-month-lifecycle. However, I don't want to commit to that
right now. This is actually a good argument for allowing EOL changes.
:)
> So far, easy, I think. But what about modules like mine which
are
> collections of stuff? We could give them an arbitrary version and
[...]
What is changing from one collection version to the next? What is
my
understanding of what is in the box at any moment in time? If the
module is tied to a specific host/platform then I would expect it to
carry that information in the metadata (see below). If it isn't, what
change prompts a new version? I think that is what we need to define as
well.
Different versions of the various programs included may have changes to
command line parameters, big changes to output, etc. One command may
even need to be retired and possibly replaced with another. Having
versioned streams allows people to expect that they can use a certain
toolset without these surprises *inside* that stream.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:29 p.m.
On Thu, Jun 29, 2017, at 08:35 PM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 08:25:59PM +0200, Brian Exelbierd wrote:
> Does this mean that a module built primarilly from a single application
> does not have a 13 month fixed lifecycle? I hope this is true because,
> in my mind, one of the things a module is promising is that some form of
> API/ABI won't break. When I hear Apache-2.4, I think, "this module is
> apache 2.4. I don't need to know the z-release because I know the 2.4
> API won't be broken." I also think that having an arbitrary EOL for the
> stream of 13 months even though Apache 2.4.x will continue to be
> available after that is odd. What changed causing the need to EOL the
> stream I was on and replace it with a new Apache-2.4 stream? Have I
> just misunderstood modules?
I think it's likely that we would want an Apache 2.4 module to have a
longer-than-13-month-lifecycle. However, I don't want to commit to that
right now. This is actually a good argument for allowing EOL changes.
:)
Sounds like this should be built-in and we should have tooling capable
of alerting to lifecycle changes. I think it is a good plan to add a
rule that barring massive issues, EOLs should only move out, not in.
> > So far, easy, I think. But what about modules like mine
which are
> > collections of stuff? We could give them an arbitrary version and
[...]
> What is changing from one collection version to the next? What is my
> understanding of what is in the box at any moment in time? If the
> module is tied to a specific host/platform then I would expect it to
> carry that information in the metadata (see below). If it isn't, what
> change prompts a new version? I think that is what we need to define as
> well.
Different versions of the various programs included may have changes to
command line parameters, big changes to output, etc. One command may
even need to be retired and possibly replaced with another. Having
versioned streams allows people to expect that they can use a certain
toolset without these surprises *inside* that stream.
In this case, I feel like the system-tools module should be tied to a
specific host/platform. It feels like a system-tools container. There
is just too many moving parts for this to not be constantly spawning
streams (even though these tools tend to be relatively stable). I think
we should discourage this in general practice but have rules for getting
permission to do it and ensure thee tooling can handle it.
However, considering this from a different angle, a LAMP stack module,
for example, might just need to make a certain API/ABI promise and then
it could roll for quite a while. This would be without regard to the
changes in the underlying software versions, as long as what was
promised on the wrapper was still met. If this is the case then
"collections" are no different from "single applications."
regards,
bex
3:34 p.m.
On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:
However, considering this from a different angle, a LAMP stack
module,
for example, might just need to make a certain API/ABI promise and then
it could roll for quite a while. This would be without regard to the
changes in the underlying software versions, as long as what was
promised on the wrapper was still met. If this is the case then
"collections" are no different from "single applications."
In terms of EOL, right. But collections have no obvious intrinsic
version number to use as the major stream identifier, whereas
applications (and environments and stacks) do.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:53 a.m.
On Thu, Jun 29, 2017, at 10:34 PM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:
> However, considering this from a different angle, a LAMP stack module,
> for example, might just need to make a certain API/ABI promise and then
> it could roll for quite a while. This would be without regard to the
> changes in the underlying software versions, as long as what was
> promised on the wrapper was still met. If this is the case then
> "collections" are no different from "single applications."
In terms of EOL, right. But collections have no obvious intrinsic
version number to use as the major stream identifier, whereas
applications (and environments and stacks) do.
I think we should allow for an arbitrary version number when the
collection is not obviously tied to a specific release/user space.
However, I think that should strongly be discouraged and if at all
possible the motivating software in the collection's version number
should be used. This is not something that should ever require heavy
debate, imho. I trust packagers to make the right decision.
regards,
bex
12:48 p.m.
On 07/03/2017 06:53 AM, Brian Exelbierd wrote:
On Thu, Jun 29, 2017, at 10:34 PM, Matthew Miller wrote:
> On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:
>> However, considering this from a different angle, a LAMP stack module,
>> for example, might just need to make a certain API/ABI promise and then
>> it could roll for quite a while. This would be without regard to the
>> changes in the underlying software versions, as long as what was
>> promised on the wrapper was still met. If this is the case then
>> "collections" are no different from "single applications."
> In terms of EOL, right. But collections have no obvious intrinsic
> version number to use as the major stream identifier, whereas
> applications (and environments and stacks) do.
I think we should allow for an arbitrary version number when the
collection is not obviously tied to a specific release/user space.
However, I think that should strongly be discouraged and if at all
possible the motivating software in the collection's version number
should be used. This is not something that should ever require heavy
debate, imho. I trust packagers to make the right decision.
regards,
bex
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
one quick point, even in the case of "single applications" what is
included may not be obvious. For example, does this mariadb module
include the client? how about python bindings? For what versions of
python? You quickly run in to problems when trying to fit information in
to the name that isn't the name of the thing. Major +1 to the points
about NOT encoding information in to the "wrong" metadata element.
Again, struggling with how do we capture all this? I believe it should
be in the module guidelines, however, it would be useful to capture
these discussions so that when we (I, for sure :) ) forget, we can see
the "threads". Should we shift this kind of discussion to the "wiki
discussion" page? Should we move the guidelines to a pagure repo and do
it with PRs, issues, etc?
Langdon
1:36 p.m.
On Thu, Jul 06, 2017 at 01:48:39PM -0400, langdon wrote:
capture these discussions so that when we (I, for sure :) ) forget,
we can see the "threads". Should we shift this kind of discussion to
the "wiki discussion" page? Should we move the guidelines to a
pagure repo and do it with PRs, issues, etc?
That sounds good to me.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:09 a.m.
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense
if we get
to my dream of mixing and matching with CentOS modules....)
Please make the year a full four-digit YYYY value. Typing that extra
"20" will not hurt anybody and the chance for confusion will be much
smaller.
--
Jan Pazdziora
Senior Principal Software Engineer, OpenShift Security Team, Red Hat
2:22 a.m.
On 29 June 2017 at 06:07, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
Each such "collection" module MUST have one or both of the
following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or
"uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense
if we get
to my dream of mixing and matching with CentOS modules....)
While "date based" is a good fallback when there's no natural version
number, I'd advise *against* using the projected EOL dates. Rather,
I'd suggested running with the "year of definition" as
http://www.vfxplatform.com/ does.
My rationale for that:
- planned EOL dates can change, years of definition don't
- a year of definition tells you at a glance how current you're
expecting target platforms to be
- versioning by year of definition has a long history in the standards
world (including language standards like C89 and C++11)
In that context, a stream label like "cy2017" would just mean "initial
version set defined in calendar year 2017", while "cm201706" (for
"calendar month") would allow for multiple new streams per year.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
2483
days inactive
2492
days old
24 comments
10 participants
participants (10)
-
Brian Exelbierd -
J. Randall Owens -
Jan Pazdziora -
Josh Boyer -
langdon -
langdon -
Matthew Miller -
Nick Coghlan -
Owen Taylor -
Petr Šabata