12:44 p.m.
OVERVIEW
========
As the modularity work starts to enter Fedora with the Fedora 27
release, a typical Change Proposal did not seem to do justice on
capturing the moving parts and dependencies for the work to successfully
land. As a result, this document attempts to capture, at a high level,
the goals and deliverables for F27. We are also providing links to the
details to most aspects. Some of the details are still in progress and
will change over the F26 lifecycle (e.g. which modules will be included
for F27 Server).
THE GOAL
========
The Modularity and Server Working Groups plan, with the help of many
other groups in Fedora, to deliver a fully modularized version of the
Fedora Server Edition. As an equal and complementary goal, the tooling
for module creation/development, deployment and automatic testing will
be as simple and automated as possible.
[*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
CAVEATS
=======
- Although modularity allows for lifecycle changes, there is no plan
for anything besides the normal 13 month lifecycle at this point.
- Available content as modules will be less than a typical Server release
- Only components that are a part of a module will be available
- Any RPM that is a part of module will be available to be
installed directly or in addition to the “install profile” install of
the module
ASPECTS TRACKED
===============
- Infrastructure Changes/Improvements:
- Bodhi: changes to support updating & tracking modules:
[*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
- Arbitrary branching: enables modules to versions bound to
something other than Fedora release number:
[*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
- Bugzilla & ABRT module-awareness are still in progress
- COPR: support for building modules has been added and will be
improved over the F26 cycle
- Automation (Freshmaker)
- On Demand Compose Service (for testing and container rebuilds)
- Greenwave: for policy/gating in Bodhi. User interactions
take place in Bodhi.
- Installation & System Management
- Anaconda: still in progress
- DNF: Work underway to support modules, additional features need
to be added. Please report comments/features/bugs in the [*normal
manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
- Gnome Software: still in progress
- Host & Platform module(s): Base components that provide the
“operating system” aspects of Modular Fedora:
[*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
[*Content tracker*](https://github.com/fedora-modularity/hp)
- Application modules ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
- TBD language modules (1 or more versions each)
- TBD database modules (1 or more versions each)
- TBD web server modules (1 or more versions each)
- TBD utility server modules (1 or more versions each)
- Applications as System Containers ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
- TBD system integrated containers
- Module Guidelines and Processes:
[*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123)
- HowTos, Examples, and Tools for Modules:
[*Website*](https://docs.pagure.org/modularity/)
BENEFITS FOR USERS
==================
- Content available in multiple streams - good examples needed
- Software Collections done the right way - Languages, Databases
- No visible change to dnf/yum unless you want to select non-default
versions
FURTHER DETAILS
===============
- [*Bodhi
Milestone*](https://github.com/fedora-infra/bodhi/milestone/4) for
Modularity
- Bodhi Changes [*Focus
document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/B...
- Freshmaker Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker)
- ODCS Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS)
- Branching Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching)
Langdon White
Fedora Modularity Objective Lead
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
8:42 a.m.
On Sun, Jun 25, 2017 at 01:44:43PM -0400, langdon wrote:
- Although modularity allows for lifecycle changes, there is no
plan for anything besides the normal 13 month lifecycle at this
point.
So, this basically gives until November 2018 to figure out a way to
handle longer lifecycles. :)
- Available content as modules will be less than a typical Server
release
- Only components that are a part of a module will be available
- Any RPM that is a part of module will be available to be
installed directly or in addition to the “install profile” install
of the module
Hmmm, so, if I want some random utility (let's say gcal, which I don't
package, or calc, which I do) on my server, what are my options? Can I
enable all general Fedora content in some way? Or do I need to make
modules for each of these things or convince someone else to? Or is the
expectation that such stuff would go into a container (which would draw
from all of Fedora RPM content)?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:06 a.m.
On Mon, Jun 26, 2017 at 09:42:39AM -0400, Matthew Miller wrote:
On Sun, Jun 25, 2017 at 01:44:43PM -0400, langdon wrote:
> - Although modularity allows for lifecycle changes, there is no
> plan for anything besides the normal 13 month lifecycle at this
> point.
So, this basically gives until November 2018 to figure out a way to
handle longer lifecycles. :)
> - Available content as modules will be less than a typical Server release
> - Only components that are a part of a module will be available
> - Any RPM that is a part of module will be available to be
> installed directly or in addition to the “install profile” install
> of the module
Hmmm, so, if I want some random utility (let's say gcal, which I don't
package, or calc, which I do) on my server, what are my options? Can I
enable all general Fedora content in some way? Or do I need to make
modules for each of these things or convince someone else to? Or is the
expectation that such stuff would go into a container (which would draw
from all of Fedora RPM content)?
The modular release is effectively a separate distro.
While using single RPMs from traditional Fedora might work in
most cases, I wouldn't recommend enabling the entire repository
which also provides packages conflicting with (and possibly
updating) those provided by modules.
Creating logical modules would be the best approach here.
Containers are also an option but someone needs to make them, too.
P
10:49 a.m.
On Mon, Jun 26, 2017 at 04:06:18PM +0200, Petr Šabata wrote:
> Hmmm, so, if I want some random utility (let's say gcal,
which I don't
> package, or calc, which I do) on my server, what are my options? Can I
[...]
The modular release is effectively a separate distro.
While using single RPMs from traditional Fedora might work in
most cases, I wouldn't recommend enabling the entire repository
which also provides packages conflicting with (and possibly
updating) those provided by modules.
Creating logical modules would be the best approach here.
Containers are also an option but someone needs to make them, too.
So, would a "Random Command-Line Tools" module make sense? Sort of like
the old "system-tools" comps group? That's a grab bag of stuff like
screen, setserial, nmap, xdelta, htop, and a whole bunch more.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:55 a.m.
On Mon, Jun 26, 2017 at 4:49 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Mon, Jun 26, 2017 at 04:06:18PM +0200, Petr Šabata wrote:
> > Hmmm, so, if I want some random utility (let's say gcal, which I don't
> > package, or calc, which I do) on my server, what are my options? Can I
[...]
> The modular release is effectively a separate distro.
>
> While using single RPMs from traditional Fedora might work in
> most cases, I wouldn't recommend enabling the entire repository
> which also provides packages conflicting with (and possibly
> updating) those provided by modules.
>
> Creating logical modules would be the best approach here.
> Containers are also an option but someone needs to make them, too.
So, would a "Random Command-Line Tools" module make sense? Sort of like
the old "system-tools" comps group? That's a grab bag of stuff like
screen, setserial, nmap, xdelta, htop, and a whole bunch more.
How do you come to a consensus on what people believe are must
have/critical "Random Command-Line Tools" that "make sense"? I
suspect
everyone will have a differing opinion there.
Peter
11:31 a.m.
On Mon, Jun 26, 2017 at 04:55:42PM +0100, Peter Robinson wrote:
>> Creating logical modules would be the best approach here.
>> Containers are also an option but someone needs to make them, too.
> So, would a "Random Command-Line Tools" module make sense? Sort of like
> the old "system-tools" comps group? That's a grab bag of stuff like
> screen, setserial, nmap, xdelta, htop, and a whole bunch more.
How do you come to a consensus on what people believe are must
have/critical "Random Command-Line Tools" that "make sense"? I
suspect
everyone will have a differing opinion there.
Absolutely; this module would contain these tools but not install them
by default.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:30 p.m.
On Mon, 2017-06-26 at 16:55 +0100, Peter Robinson wrote:
On Mon, Jun 26, 2017 at 4:49 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Mon, Jun 26, 2017 at 04:06:18PM +0200, Petr Šabata wrote:
> > > Hmmm, so, if I want some random utility (let's say gcal, which I
don't
> > > package, or calc, which I do) on my server, what are my options? Can I
>
> [...]
> > The modular release is effectively a separate distro.
> >
> > While using single RPMs from traditional Fedora might work in
> > most cases, I wouldn't recommend enabling the entire repository
> > which also provides packages conflicting with (and possibly
> > updating) those provided by modules.
> >
> > Creating logical modules would be the best approach here.
> > Containers are also an option but someone needs to make them, too.
>
> So, would a "Random Command-Line Tools" module make sense? Sort of like
> the old "system-tools" comps group? That's a grab bag of stuff like
> screen, setserial, nmap, xdelta, htop, and a whole bunch more.
How do you come to a consensus on what people believe are must
have/critical "Random Command-Line Tools" that "make sense"? I
suspect
everyone will have a differing opinion there.
Okay, fine, I'll start:
vi!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:03 a.m.
On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata <contyk(a)redhat.com> wrote:
The modular release is effectively a separate distro.
While using single RPMs from traditional Fedora might work in
most cases, I wouldn't recommend enabling the entire repository
which also provides packages conflicting with (and possibly
updating) those provided by modules.
Creating logical modules would be the best approach here.
Containers are also an option but someone needs to make them, too.
P
Perhaps I'm confused or have outdated information, but I thought I
recalled reading plans to (at least initially) potentially throw all
non-already-module'd packages into something like an "Everything"
module so it continued to be installable? And then gradually migrate
things out from it into modules.
It seems like doing so would solve this problem.
Many of the packages I maintain are essentially one-offs that I'm not
convinced will ever belong in a specific module-- where would things
like this end up?
Ben Rosser
12:04 p.m.
On Mon, Jun 26, 2017, 12:06 Ben Rosser <rosser.bjr(a)gmail.com> wrote:
On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata
<contyk(a)redhat.com> wrote:
>
> The modular release is effectively a separate distro.
>
> While using single RPMs from traditional Fedora might work in
> most cases, I wouldn't recommend enabling the entire repository
> which also provides packages conflicting with (and possibly
> updating) those provided by modules.
>
> Creating logical modules would be the best approach here.
> Containers are also an option but someone needs to make them, too.
>
> P
Perhaps I'm confused or have outdated information, but I thought I
recalled reading plans to (at least initially) potentially throw all
non-already-module'd packages into something like an "Everything"
module so it continued to be installable? And then gradually migrate
things out from it into modules.
It seems like doing so would solve this problem.
Many of the packages I maintain are essentially one-offs that I'm not
convinced will ever belong in a specific module-- where would things
like this end up?
Ben Rosser
We talked about this with the server wg and decided for F27 server we would
try to avoid an "everything else" module and figure out how to solve this
problem more nicely between now and release. We have multiple options here
including : generating modules for everything, making an extra repo of
stuff available, leaving non-modules out, and, finally, the everything else
module.
Definitely a recognized issue, but not sure we are decided on the answer
(or answers). We would like the module guidelines to address the use cases
with recommendations but it is tough to iron this out.
Langdon
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
12:29 p.m.
On 06/26/2017 11:04 AM, Langdon White wrote:
We talked about this with the server wg and decided for F27 server we
would
try to avoid an "everything else" module and figure out how to solve this
problem more nicely between now and release. We have multiple options here
including : generating modules for everything, making an extra repo of
stuff available, leaving non-modules out, and, finally, the everything else
module.
So there is never going to be any mixing of modules and non modules? I
would think another way to solve this issue might be to get dnf to
prefer modules, but still operate on either rpms or modules, so if you
ran 'dnf install tmux' it would look for a tmux module, if it finds it
great, it uses that. If it doesn't then it looks for the rpm and uses that.
Then if later you do 'dnf update' and there is now a tmux module it
uninstalls the rpm and intalls the module, etc.
Definitely a recognized issue, but not sure we are decided on the answer
(or answers). We would like the module guidelines to address the use cases
with recommendations but it is tough to iron this out.
yeah, there definitely could be some complex interactions here, but I
think it's important to have the ability to install local rpms or things
that are not (yet) modularized.
Unrelated question: We will still be making the server repo and
netinstall so people can install the legacy server setup with rpms, right?
kevin
12:35 p.m.
On Mon, Jun 26, 2017 at 1:33 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
Unrelated question: We will still be making the server repo and
netinstall so people can install the legacy server setup with rpms, right?
I don't know if we'll bother creating an actual Fedora Server netinstall,
but we'll certainly still have the unbranded netinstall for the foreseeable
future.
12:44 p.m.
On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote:
On 06/26/2017 11:04 AM, Langdon White wrote:
> We talked about this with the server wg and decided for F27 server we would
> try to avoid an "everything else" module and figure out how to solve this
> problem more nicely between now and release. We have multiple options here
> including : generating modules for everything, making an extra repo of
> stuff available, leaving non-modules out, and, finally, the everything else
> module.
So there is never going to be any mixing of modules and non modules? I
would think another way to solve this issue might be to get dnf to
prefer modules, but still operate on either rpms or modules, so if you
ran 'dnf install tmux' it would look for a tmux module, if it finds it
great, it uses that. If it doesn't then it looks for the rpm and uses that.
Then if later you do 'dnf update' and there is now a tmux module it
uninstalls the rpm and intalls the module, etc.
This question is kinda like "so there is never going to be any
mixing of Fedora and Mageia RPMs?".
Module content is built separately and while the sources are
often the same or close to what was used to build traditional
composes, the modular content is not guaranteed to be 100%
binary compatible.
Enhancing dnf with a feature with a potential to unexpectedly
explode users' systems doesn't sound like a reasonable thing
to do.
> Definitely a recognized issue, but not sure we are decided on
the answer
> (or answers). We would like the module guidelines to address the use cases
> with recommendations but it is tough to iron this out.
yeah, there definitely could be some complex interactions here, but I
think it's important to have the ability to install local rpms or things
that are not (yet) modularized.
That can be done. And if those local RPMs were built against
the modular platform, even better.
P
Unrelated question: We will still be making the server repo and
netinstall so people can install the legacy server setup with rpms, right?
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:19 p.m.
On 06/26/2017 01:44 PM, Petr Šabata wrote:
On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote:
> On 06/26/2017 11:04 AM, Langdon White wrote:
>
>> We talked about this with the server wg and decided for F27 server we would
>> try to avoid an "everything else" module and figure out how to solve
this
>> problem more nicely between now and release. We have multiple options here
>> including : generating modules for everything, making an extra repo of
>> stuff available, leaving non-modules out, and, finally, the everything else
>> module.
> So there is never going to be any mixing of modules and non modules? I
> would think another way to solve this issue might be to get dnf to
> prefer modules, but still operate on either rpms or modules, so if you
> ran 'dnf install tmux' it would look for a tmux module, if it finds it
> great, it uses that. If it doesn't then it looks for the rpm and uses that.
> Then if later you do 'dnf update' and there is now a tmux module it
> uninstalls the rpm and intalls the module, etc.
This question is kinda like "so there is never going to be any
mixing of Fedora and Mageia RPMs?".
Module content is built separately and while the sources are
often the same or close to what was used to build traditional
composes, the modular content is not guaranteed to be 100%
binary compatible.
Petr, I think you are jumping to the worst case scenario version
of this
question. Specifically, that the "arbitrary rpms" in question here are
coming from an arbitrary repo. Yes, your concerns are valid if we are
adding in arbitrary stuff from arbitrary sources. However, like I said
in my email which crossed in the ether, that doesn't mean we can't
manipulate RPMs directly from DNF. We just don't want people pulling
arbitrary rpms from non-modular sources.
Enhancing dnf with a feature with a potential to unexpectedly
explode users' systems doesn't sound like a reasonable thing
to do.
I think this is a matter of UX testing. If the tmux-rpm was silently
replaced with the tmux-module it may be a good thing assuming it does
what the user expects. I, personally, struggle with the
"uninstall/reinstall" portion of this but if we could find a way to just
add stream information without actually replacing the rpm, the user
could just follow the "tmux-before-it-was-a-module" stream until they
are ready to switch then be give the "real" module-stream options.
Langdon
>> Definitely a recognized issue, but not sure we are decided on
the answer
>> (or answers). We would like the module guidelines to address the use cases
>> with recommendations but it is tough to iron this out.
> yeah, there definitely could be some complex interactions here, but I
> think it's important to have the ability to install local rpms or things
> that are not (yet) modularized.
That can be done. And if those local RPMs were built against
the modular platform, even better.
P
> Unrelated question: We will still be making the server repo and
> netinstall so people can install the legacy server setup with rpms, right?
>
> kevin
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
2:41 p.m.
On Mon, Jun 26, 2017 at 02:19:42PM -0400, langdon wrote:
On 06/26/2017 01:44 PM, Petr Šabata wrote:
> On Mon, Jun 26, 2017 at 11:29:08AM -0600, Kevin Fenzi wrote:
> > On 06/26/2017 11:04 AM, Langdon White wrote:
> >
> > > We talked about this with the server wg and decided for F27 server we
would
> > > try to avoid an "everything else" module and figure out how to
solve this
> > > problem more nicely between now and release. We have multiple options
here
> > > including : generating modules for everything, making an extra repo of
> > > stuff available, leaving non-modules out, and, finally, the everything
else
> > > module.
> > So there is never going to be any mixing of modules and non modules? I
> > would think another way to solve this issue might be to get dnf to
> > prefer modules, but still operate on either rpms or modules, so if you
> > ran 'dnf install tmux' it would look for a tmux module, if it finds it
> > great, it uses that. If it doesn't then it looks for the rpm and uses
that.
> > Then if later you do 'dnf update' and there is now a tmux module it
> > uninstalls the rpm and intalls the module, etc.
> This question is kinda like "so there is never going to be any
> mixing of Fedora and Mageia RPMs?".
>
> Module content is built separately and while the sources are
> often the same or close to what was used to build traditional
> composes, the modular content is not guaranteed to be 100%
> binary compatible.
Petr, I think you are jumping to the worst case scenario version of this
question. Specifically, that the "arbitrary rpms" in question here are
coming from an arbitrary repo. Yes, your concerns are valid if we are adding
in arbitrary stuff from arbitrary sources. However, like I said in my email
which crossed in the ether, that doesn't mean we can't manipulate RPMs
directly from DNF. We just don't want people pulling arbitrary rpms from
non-modular sources.
Kevin specifically asked about mixing modular and non-modular content.
Yes, you can manipulate RPMs directly. I'm not saying you cannot.
> Enhancing dnf with a feature with a potential to unexpectedly
> explode users' systems doesn't sound like a reasonable thing
> to do.
I think this is a matter of UX testing. If the tmux-rpm was silently
replaced with the tmux-module it may be a good thing assuming it does what
the user expects. I, personally, struggle with the "uninstall/reinstall"
portion of this but if we could find a way to just add stream information
without actually replacing the rpm, the user could just follow the
"tmux-before-it-was-a-module" stream until they are ready to switch then be
give the "real" module-stream options.
I'm not sure who would be doing mapping between random RPMs
and modules that "replace" them. Sounds difficult, dangerous
and not really doable at a large scale, especially if there are
more variants of the same content available at the same time,
which is one of our features.
P
Langdon
> > > Definitely a recognized issue, but not sure we are decided on the answer
> > > (or answers). We would like the module guidelines to address the use
cases
> > > with recommendations but it is tough to iron this out.
> > yeah, there definitely could be some complex interactions here, but I
> > think it's important to have the ability to install local rpms or things
> > that are not (yet) modularized.
> That can be done. And if those local RPMs were built against
> the modular platform, even better.
>
> P
>
> > Unrelated question: We will still be making the server repo and
> > netinstall so people can install the legacy server setup with rpms, right?
> >
> > kevin
> >
> >
>
>
>
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
12:55 p.m.
On 06/26/2017 01:29 PM, Kevin Fenzi wrote:
On 06/26/2017 11:04 AM, Langdon White wrote:
> We talked about this with the server wg and decided for F27 server we would
> try to avoid an "everything else" module and figure out how to solve this
> problem more nicely between now and release. We have multiple options here
> including : generating modules for everything, making an extra repo of
> stuff available, leaving non-modules out, and, finally, the everything else
> module.
So there is never going to be any mixing of modules and non modules? I
would think another way to solve this issue might be to get dnf to
prefer modules, but still operate on either rpms or modules, so if you
ran 'dnf install tmux' it would look for a tmux module, if it finds it
great, it uses that. If it doesn't then it looks for the rpm and uses that.
Then if later you do 'dnf update' and there is now a tmux module it
uninstalls the rpm and intalls the module, etc.
Essentially, this ^^ is exactly the plan. The DNF folks will have to
weigh in on exactly how the priorities will work. I also would like to
see some UX testing around your last point. As in, I am not sure the
user gets what they expect if it replaces the tmux-rpm with the
tmux-module without any hint.
For example, even if we had an httpd module, mod_ssl may not be there in
the default-install. However, it would still be available and we are
trying to make it essentially "dnf install mod_ssl" (apologies if I am
misremembering the exact package names) to add in that function. The
modular aspect just indicates the stream the mod_ssl comes from, e.g.
httpd 2.4 vs httpd 2.2.
Apologies, but I was talking about "available in the Fedora Server
repo". Specifically, we have a lofty goal that everything in that repo
would have a module wrapped around it. We may not get there which
triggers the choices above.
Hopefully, that makes more sense.
Langdon
PS: the problems with communicating when you are very close to something
for a long time.
> Definitely a recognized issue, but not sure we are decided on the
answer
> (or answers). We would like the module guidelines to address the use cases
> with recommendations but it is tough to iron this out.
yeah, there definitely could be some complex interactions here, but I
think it's important to have the ability to install local rpms or things
that are not (yet) modularized.
Unrelated question: We will still be making the server repo and
netinstall so people can install the legacy server setup with rpms, right?
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:13 p.m.
On 26 June 2017 at 13:55, langdon <langdon(a)fedoraproject.org> wrote:
On 06/26/2017 01:29 PM, Kevin Fenzi wrote:
>
> On 06/26/2017 11:04 AM, Langdon White wrote:
>
>> We talked about this with the server wg and decided for F27 server we
>> would
>> try to avoid an "everything else" module and figure out how to solve
this
>> problem more nicely between now and release. We have multiple options
>> here
>> including : generating modules for everything, making an extra repo of
>> stuff available, leaving non-modules out, and, finally, the everything
>> else
>> module.
>
> So there is never going to be any mixing of modules and non modules? I
> would think another way to solve this issue might be to get dnf to
> prefer modules, but still operate on either rpms or modules, so if you
> ran 'dnf install tmux' it would look for a tmux module, if it finds it
> great, it uses that. If it doesn't then it looks for the rpm and uses
> that.
> Then if later you do 'dnf update' and there is now a tmux module it
> uninstalls the rpm and intalls the module, etc.
Essentially, this ^^ is exactly the plan. The DNF folks will have to weigh
in on exactly how the priorities will work. I also would like to see some UX
testing around your last point. As in, I am not sure the user gets what they
expect if it replaces the tmux-rpm with the tmux-module without any hint.
Compared to the email from Petr Šabata <contyk(a)redhat.com> that came
out at the same time:
Module content is built separately and while the sources are
often the same or close to what was used to build traditional
composes, the modular content is not guaranteed to be 100%
binary compatible.
===
I am now even more confused.. are we even talking about the same
things in these emails or different things with the same name? Because
if there isn't 100% binary compatibility, I can't see how what you say
above is possible.
Langdon
PS: the problems with communicating when you are very close to something for
a long time.
Or that many people "see" how they are going to deliver the giant
robot differently :)
--
Stephen J Smoogen.
1:30 p.m.
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote:
Apologies, but I was talking about "available in the Fedora
Server
repo". Specifically, we have a lofty goal that everything in that
repo would have a module wrapped around it. We may not get there
which triggers the choices above.
As Fedora stands today, of course, "the Fedora Server repo" means "all
the stuff Fedora packages at all". At the extreme, even though we tell
people that it's better to install Workstation or a desktop Spin if
they want to add a GUI, you _can_ install GNOME or KDE on server.
I don't think we need to support the extreme on Fedora Server (as an
edition) in the future (although I think we should do what we can to
allow community members to compose such a thing of their own if they
want it). But, we should set a goal like 60% of packages
which make sense in a server install available to modular server in
F27, and 95% by F28. (Where those specific numbers are just made up.)
That can be done by:
- Every RPM that's not a library (or library-like) becomes a module.
Like, basically everything in `dnf group info system-tools`, plus
cowsay.
- Lumping some of these tools logically into "network admin tools",
"file archive/backup/sync", "benchmarking", or whatever. (This
seems... hard to get right.)
- Bigger split without real attempt to categorize, like "Random CLI
tools" and "Random GUI tools" modules.
- Gigantic "Everything Else!" module.
- Allowing package installs from the unmodularized Fedora repository,
and doing something fancy to avoid trouble.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:50 p.m.
On Mon, Jun 26, 2017 at 02:30:20PM -0400, Matthew Miller wrote:
That can be done by:
[...]
Ugh, got distracted and sent before really done. Are there other ways
we're looking at? Which of these are the Modularity and Server WGs
thinking?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:32 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, 2017-06-26 at 14:30 -0400, Matthew Miller wrote:
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote:
> Apologies, but I was talking about "available in the Fedora Server
> repo". Specifically, we have a lofty goal that everything in that
> repo would have a module wrapped around it. We may not get there
> which triggers the choices above.
As Fedora stands today, of course, "the Fedora Server repo" means
"all
the stuff Fedora packages at all". At the extreme, even though we
tell
people that it's better to install Workstation or a desktop Spin if
they want to add a GUI, you _can_ install GNOME or KDE on server.
I don't think we need to support the extreme on Fedora Server (as an
edition) in the future (although I think we should do what we can to
allow community members to compose such a thing of their own if they
want it). But, we should set a goal like 60% of packages
which make sense in a server install available to modular server in
F27, and 95% by F28. (Where those specific numbers are just made up.)
That can be done by:
- Every RPM that's not a library (or library-like) becomes a
module.
Like, basically everything in `dnf group info system-tools`, plus
cowsay.
- Lumping some of these tools logically into "network admin tools",
"file archive/backup/sync", "benchmarking", or whatever. (This
seems... hard to get right.)
- Bigger split without real attempt to categorize, like "Random CLI
tools" and "Random GUI tools" modules.
- Gigantic "Everything Else!" module.
- Allowing package installs from the unmodularized Fedora
repository,
and doing something fancy to avoid trouble.
This has been tried by AltLinux,
they were using Group tag to organize
packages into small repositories and after all they went back for one
big repository because of cross-dependencies, questions where to put
what and probably other problems.
--
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
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAllRYT8ACgkQaVcUvRu8
X0w6iA/9EeCA2B+I/NaLe+LIdr7gfAshyIsgIBJ6690QRmeqNNgv1RKkVuRfKEy8
NtEbp5NENAa9T5Z7PtcccDoWzkU14KMB/ECyzK5nkVd1La1DdDfpJSHpw8wTwD8+
P5setc4zkwxS0kEPA/Wxp1tw71VBhoHLFBcKBYd3/CW8/E7e/wcqfNW1hhHww1XD
lMgBL0ISJynBuJuzRt2y0A9ymP96S7HN1Sy7nu5h+zV6ZS7IvdOviGKdrRgo0iOk
Y8eHFmGtzAGLni/95rGVYHyZ0IIY+cLn1HLs23IPvoF8/Hz5FjjJkIkP22fw06No
Ljy4SaL589e+dBPYRn+MFR2w1niAFOcOHATvnXqNpwbxlYv7CsjBEPv1o/+3BWQw
PX7krNorSHo5wgw7ldA6leqp/aer8xz6Kc6v3MbV0p5ooCOn5kJLxFCLDnFbVOKe
ogkfAVlW0RDEMMf/DoF4MfRoRTfGLBF72ALrm3BMtatxPZPpQECffsiAJ8jtjpei
Gaps2ULlyrBu1kFbPsFXDe9mo4meLpiOH3ko5ZXHTZzTClaPlLHQMX39UD1YwcY8
N5KFDhXSsjmeSWOh4cVl0I8Gy3XBQ77DV9oTXaKMXgwCtQWPlHkkPhpWc/h/TOIM
cb8a2wrRQTDUNem00r1oilDuimdaNO4Hb7RLZBkrOw94QhTXF38=
=Hyrm
-----END PGP SIGNATURE-----
3:13 p.m.
On Mon, Jun 26, 2017 at 09:32:15PM +0200, Igor Gnatenko wrote:
This has been tried by AltLinux, they were using Group tag to
organize
packages into small repositories and after all they went back for one
big repository because of cross-dependencies, questions where to put
what and probably other problems.
The modularity tech covers the cross-dependencies problem in a new way.
For some things, it's pretty clear that "yep, that's a module" is the
way to go. (Like, the sort of stuff already building in modules —
databases, webservers, language runtimes.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:42 a.m.
On Mon, Jun 26, 2017 at 9:13 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Mon, Jun 26, 2017 at 09:32:15PM +0200, Igor Gnatenko wrote:
> This has been tried by AltLinux, they were using Group tag to organize
> packages into small repositories and after all they went back for one
> big repository because of cross-dependencies, questions where to put
> what and probably other problems.
The modularity tech covers the cross-dependencies problem in a new way.
For some things, it's pretty clear that "yep, that's a module" is the
way to go. (Like, the sort of stuff already building in modules —
databases, webservers, language runtimes.)
What "new way" is this? My examination of this indicates that there's
*nothing* for fixing this, and this _will_ blow up in the Server WG's
face if you're not even going to bother properly handling RPM and
modules concurrently and multiple modules together.
Modularity sounds like a good idea, but I am not yet convinced that
you've figured out some way to make coarse dependencies work, unless
there's some magical use of relocatable RPMs or something like that to
ensure everything is namespaced on install.
Frankly, I don't know how modules are any different from composition
groups from the user point of view. Yes, we have the thing with
messing with the build environment and package filters in the module
source configuration, but I'm not sure how you'll deal with
conflicting builds on the same system.
In addition, I do not believe that distributors of third party
software will find modularity useful as-is. Also, the ref/versioning
stuff is confusing.
Finally, what the heck are we supposed to do about non x86_64, or even
bringing in new architectures (RISC-V, MIPS, etc.)?
--
真実はいつも一つ！/ Always, there's only one truth!
5:10 p.m.
On Mon, 2017-06-26 at 14:30 -0400, Matthew Miller wrote:
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote:
> Apologies, but I was talking about "available in the Fedora Server
> repo". Specifically, we have a lofty goal that everything in that
> repo would have a module wrapped around it. We may not get there
> which triggers the choices above.
As Fedora stands today, of course, "the Fedora Server repo" means "all
the stuff Fedora packages at all".
Um. Does it? I am not entirely sure if this is what was meant in
context, but there *is* a "Fedora Server repo" which does *not* contain
"all the stuff Fedora packages at all" - for instance, the repos you
can find under:
https://dl.fedoraproject.org/pub/fedora/linux/releases/25/Server/
The contents of the Server install tree (and hence these repos) are, I
believe, defined in:
https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml
and can easily be seen to be a subset of the entire Fedora package set.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:25 p.m.
On 06/27/2017 06:10 PM, Adam Williamson wrote:
On Mon, 2017-06-26 at 14:30 -0400, Matthew Miller wrote:
> On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote:
>> Apologies, but I was talking about "available in the Fedora Server
>> repo". Specifically, we have a lofty goal that everything in that
>> repo would have a module wrapped around it. We may not get there
>> which triggers the choices above.
> As Fedora stands today, of course, "the Fedora Server repo" means
"all
> the stuff Fedora packages at all".
Um. Does it? I am not entirely sure if this is what was meant in
context, but there *is* a "Fedora Server repo" which does *not* contain
"all the stuff Fedora packages at all" - for instance, the repos you
can find under:
https://dl.fedoraproject.org/pub/fedora/linux/releases/25/Server/
The contents of the Server install tree (and hence these repos) are, I
believe, defined in:
https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml
and can easily be seen to be a subset of the entire Fedora package set.
I think this confusion comes in because the content is all under one
directory structure to ease mirror replication. However, logically (and,
in practice, in terms of repodata), there are a number of different
repos under that one directory structure
(https://dl.fedoraproject.org/pub/fedora). When I say "confusion" I
don't mean anyone is really confused rather that it is easy to conflate
the two unless being very specific. Not to mention the repos at that url
are not necessarily the same repos that end up in, say, a livecd.
Langdon
12:27 p.m.
On Tue, Jun 27, 2017 at 03:10:16PM -0700, Adam Williamson wrote:
> As Fedora stands today, of course, "the Fedora Server
repo" means "all
> the stuff Fedora packages at all".
Um. Does it? I am not entirely sure if this is what was meant in
context, but there *is* a "Fedora Server repo" which does *not* contain
"all the stuff Fedora packages at all" - for instance, the repos you
can find under:
I know, but as you've heard me whining about before, that's a weird
artifact of the build process that leaks out onto the mirrors. Once you
have a Fedora Server system up and running you're pointed at
Everything. The "Server" package tree is just a red herring and
confusing to users (while wasting at _least_ processing time while
mirroring, if not space and network traffic where hardlinking isn't
available).
If we wanted to change that the other way around and make it a real
thing, I'm not *necessarily* opposed, but it would definitely be a huge
change in user experience.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:42 p.m.
On Wed, 2017-06-28 at 13:27 -0400, Matthew Miller wrote:
On Tue, Jun 27, 2017 at 03:10:16PM -0700, Adam Williamson wrote:
> > As Fedora stands today, of course, "the Fedora Server repo" means
"all
> > the stuff Fedora packages at all".
>
> Um. Does it? I am not entirely sure if this is what was meant in
> context, but there *is* a "Fedora Server repo" which does *not* contain
> "all the stuff Fedora packages at all" - for instance, the repos you
> can find under:
I know, but as you've heard me whining about before, that's a weird
artifact of the build process that leaks out onto the mirrors. Once you
have a Fedora Server system up and running you're pointed at
Everything.
Well, yes, but *in context*, the text was specifying the extent of the
package set it covered. It seems, to me, at least as likely that the
intent of the text was "the Change will cover all the packages in the
Server install tree" as "the Change will cover all the packages in the
'fedora' repository".
I don't think it's necessary or appropriate to debate the nature or
desirability of the Server install tree repos at this point, as the
actual practical *point* under discussion here is what the text
actually means in defining the scope of the Change.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:12 a.m.
On Wed, Jun 28, 2017 at 06:42:37PM -0700, Adam Williamson wrote:
Well, yes, but *in context*, the text was specifying the extent of
the
package set it covered. It seems, to me, at least as likely that the
intent of the text was "the Change will cover all the packages in the
Server install tree" as "the Change will cover all the packages in the
'fedora' repository".
I don't think it's necessary or appropriate to debate the nature or
desirability of the Server install tree repos at this point, as the
actual practical *point* under discussion here is what the text
actually means in defining the scope of the Change.
I'm not trying to be cute about the server tree here. I mean that
people's real-world expectation of "What's in the repos for Fedora
Server" does not equal "the thing that looks like the Fedora Server
repo if you go digging into the ftp tree structure", and that if don't
make that clear, there will be tears.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:41 a.m.
On Mon, Jun 26, 2017 at 01:55:58PM -0400, langdon wrote:
On 06/26/2017 01:29 PM, Kevin Fenzi wrote:
> On 06/26/2017 11:04 AM, Langdon White wrote:
>
> > We talked about this with the server wg and decided for F27 server we would
> > try to avoid an "everything else" module and figure out how to solve
this
> > problem more nicely between now and release. We have multiple options here
> > including : generating modules for everything, making an extra repo of
> > stuff available, leaving non-modules out, and, finally, the everything else
> > module.
> So there is never going to be any mixing of modules and non modules? I
> would think another way to solve this issue might be to get dnf to
> prefer modules, but still operate on either rpms or modules, so if you
> ran 'dnf install tmux' it would look for a tmux module, if it finds it
> great, it uses that. If it doesn't then it looks for the rpm and uses that.
> Then if later you do 'dnf update' and there is now a tmux module it
> uninstalls the rpm and intalls the module, etc.
Essentially, this ^^ is exactly the plan. The DNF folks will have to weigh
in on exactly how the priorities will work. I also would like to see some UX
testing around your last point. As in, I am not sure the user gets what they
expect if it replaces the tmux-rpm with the tmux-module without any hint.
What exactly would be the difference between tmux.rpm and tmux.module.rpm?
Would it be configure flags? Bundled libraries? Something else?
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl -- Baron Vladimir Harkonnen
7:30 a.m.
On Sun, Jun 25, 2017 at 1:44 PM, langdon <langdon(a)fedoraproject.org> wrote:
OVERVIEW
========
As the modularity work starts to enter Fedora with the Fedora 27
release, a typical Change Proposal did not seem to do justice on
capturing the moving parts and dependencies for the work to successfully
land. As a result, this document attempts to capture, at a high level,
the goals and deliverables for F27. We are also providing links to the
details to most aspects. Some of the details are still in progress and
will change over the F26 lifecycle (e.g. which modules will be included
for F27 Server).
THE GOAL
========
The Modularity and Server Working Groups plan, with the help of many
other groups in Fedora, to deliver a fully modularized version of the
Fedora Server Edition. As an equal and complementary goal, the tooling
for module creation/development, deployment and automatic testing will
be as simple and automated as possible.
[*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
Given that Server is widely used across a number of architectures,
with participation from various groups using those architectures, we
still need Server to work on all the architectures it does today. Is
that your understanding as well?
CAVEATS
=======
- Although modularity allows for lifecycle changes, there is no plan for
anything besides the normal 13 month lifecycle at this point.
- Available content as modules will be less than a typical Server release
- Only components that are a part of a module will be available
- Any RPM that is a part of module will be available to be installed
directly or in addition to the “install profile” install of the module
ASPECTS TRACKED
===============
- Infrastructure Changes/Improvements:
- Bodhi: changes to support updating & tracking modules:
[*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
- Arbitrary branching: enables modules to versions bound to something
other than Fedora release number:
[*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
- Bugzilla & ABRT module-awareness are still in progress
- COPR: support for building modules has been added and will be
improved over the F26 cycle
- Automation (Freshmaker)
- On Demand Compose Service (for testing and container rebuilds)
What does "testing" mean here?
- Greenwave: for policy/gating in Bodhi. User interactions
take
place in Bodhi.
- Installation & System Management
- Anaconda: still in progress
- DNF: Work underway to support modules, additional features need to
be added. Please report comments/features/bugs in the [*normal
manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
- Gnome Software: still in progress
- Host & Platform module(s): Base components that provide the “operating
system” aspects of Modular Fedora:
[*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
[*Content tracker*](https://github.com/fedora-modularity/hp)
- Application modules ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
- TBD language modules (1 or more versions each)
- TBD database modules (1 or more versions each)
- TBD web server modules (1 or more versions each)
- TBD utility server modules (1 or more versions each)
- Applications as System Containers ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
- TBD system integrated containers
This requires a container build service capable of producing these
containers. I think the Fedora layered build service can do that for
x86_64, but it is not capable of doing that for other architectures.
Is support for that being worked on?
josh
> - Module Guidelines and Processes:
> [*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123)
> - HowTos, Examples, and Tools for Modules:
> [*Website*](https://docs.pagure.org/modularity/)
>
> BENEFITS FOR USERS
> ==================
>
> - Content available in multiple streams - good examples needed
> - Software Collections done the right way - Languages, Databases
> - No visible change to dnf/yum unless you want to select non-default
> versions
>
> FURTHER DETAILS
> ===============
>
> - [*Bodhi Milestone*](https://github.com/fedora-infra/bodhi/milestone/4)
> for Modularity
> - Bodhi Changes [*Focus
> document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/B...
> - Freshmaker Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker)
> - ODCS Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS)
> - Branching Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching)
>
> Langdon White
> Fedora Modularity Objective Lead
> _______________________________________________
> devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
9:44 a.m.
On 06/27/2017 08:30 AM, Josh Boyer wrote:
On Sun, Jun 25, 2017 at 1:44 PM, langdon
<langdon(a)fedoraproject.org> wrote:
> OVERVIEW
> ========
>
> As the modularity work starts to enter Fedora with the Fedora 27
> release, a typical Change Proposal did not seem to do justice on
> capturing the moving parts and dependencies for the work to successfully
> land. As a result, this document attempts to capture, at a high level,
> the goals and deliverables for F27. We are also providing links to the
> details to most aspects. Some of the details are still in progress and
> will change over the F26 lifecycle (e.g. which modules will be included
> for F27 Server).
>
> THE GOAL
> ========
>
> The Modularity and Server Working Groups plan, with the help of many
> other groups in Fedora, to deliver a fully modularized version of the
> Fedora Server Edition. As an equal and complementary goal, the tooling
> for module creation/development, deployment and automatic testing will
> be as simple and automated as possible.
> [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
Given that Server is widely used across a number of architectures,
with participation from various groups using those architectures, we
still need Server to work on all the architectures it does today. Is
that your understanding as well?
We fully expect to build for all the supported architectures as Server
Edition does today.
> CAVEATS
> =======
>
> - Although modularity allows for lifecycle changes, there is no plan for
> anything besides the normal 13 month lifecycle at this point.
> - Available content as modules will be less than a typical Server release
> - Only components that are a part of a module will be available
> - Any RPM that is a part of module will be available to be installed
> directly or in addition to the “install profile” install of the module
>
> ASPECTS TRACKED
> ===============
>
> - Infrastructure Changes/Improvements:
> - Bodhi: changes to support updating & tracking modules:
> [*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
> - Arbitrary branching: enables modules to versions bound to something
> other than Fedora release number:
> [*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
> - Bugzilla & ABRT module-awareness are still in progress
> - COPR: support for building modules has been added and will be
> improved over the F26 cycle
> - Automation (Freshmaker)
> - On Demand Compose Service (for testing and container rebuilds)
What does "testing" mean here?
I think it just means "things are rebuilt and sent to automated
testing". Why it doesn't say "for release" I am not sure. I may have
"cleaned up" the text poorly.
Ralph, JanK: can you weigh in here?
> - Greenwave: for policy/gating in Bodhi. User interactions take
> place in Bodhi.
> - Installation & System Management
> - Anaconda: still in progress
> - DNF: Work underway to support modules, additional features need to
> be added. Please report comments/features/bugs in the [*normal
> manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
> - Gnome Software: still in progress
> - Host & Platform module(s): Base components that provide the “operating
> system” aspects of Modular Fedora:
> [*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
> [*Content tracker*](https://github.com/fedora-modularity/hp)
> - Application modules ([*Content
> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
> - TBD language modules (1 or more versions each)
> - TBD database modules (1 or more versions each)
> - TBD web server modules (1 or more versions each)
> - TBD utility server modules (1 or more versions each)
> - Applications as System Containers ([*Content
> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
> - TBD system integrated containers
This requires a container build service capable of producing these
containers. I think the Fedora layered build service can do that for
x86_64, but it is not capable of doing that for other architectures.
Is support for that being worked on?
I understand that to be the case as well. We
plan to do, at least,
x86_64. I need Ralph, Adam Miller, and Eliska to comment any further on
the plan.
Langdon
josh
> - Module Guidelines and Processes:
> [*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123)
> - HowTos, Examples, and Tools for Modules:
> [*Website*](https://docs.pagure.org/modularity/)
>
> BENEFITS FOR USERS
> ==================
>
> - Content available in multiple streams - good examples needed
> - Software Collections done the right way - Languages, Databases
> - No visible change to dnf/yum unless you want to select non-default
> versions
>
> FURTHER DETAILS
> ===============
>
> - [*Bodhi Milestone*](https://github.com/fedora-infra/bodhi/milestone/4)
> for Modularity
> - Bodhi Changes [*Focus
> document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/B...
> - Freshmaker Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker)
> - ODCS Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS)
> - Branching Focus doc
>
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching)
>
> Langdon White
> Fedora Modularity Objective Lead
> _______________________________________________
> devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
9:54 a.m.
On Tue, Jun 27, 2017 at 10:44 AM, langdon <langdon(a)redhat.com> wrote:
On 06/27/2017 08:30 AM, Josh Boyer wrote:
>
> On Sun, Jun 25, 2017 at 1:44 PM, langdon <langdon(a)fedoraproject.org>
> wrote:
>>
>> OVERVIEW
>> ========
>>
>> As the modularity work starts to enter Fedora with the Fedora 27
>> release, a typical Change Proposal did not seem to do justice on
>> capturing the moving parts and dependencies for the work to successfully
>> land. As a result, this document attempts to capture, at a high level,
>> the goals and deliverables for F27. We are also providing links to the
>> details to most aspects. Some of the details are still in progress and
>> will change over the F26 lifecycle (e.g. which modules will be included
>> for F27 Server).
>>
>> THE GOAL
>> ========
>>
>> The Modularity and Server Working Groups plan, with the help of many
>> other groups in Fedora, to deliver a fully modularized version of the
>> Fedora Server Edition. As an equal and complementary goal, the tooling
>> for module creation/development, deployment and automatic testing will
>> be as simple and automated as possible.
>> [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
>
> Given that Server is widely used across a number of architectures,
> with participation from various groups using those architectures, we
> still need Server to work on all the architectures it does today. Is
> that your understanding as well?
We fully expect to build for all the supported architectures as Server
Edition does today.
Yay!
>> CAVEATS
>> =======
>>
>> - Although modularity allows for lifecycle changes, there is no plan
>> for
>> anything besides the normal 13 month lifecycle at this point.
>> - Available content as modules will be less than a typical Server
>> release
>> - Only components that are a part of a module will be available
>> - Any RPM that is a part of module will be available to be
>> installed
>> directly or in addition to the “install profile” install of the module
>>
>> ASPECTS TRACKED
>> ===============
>>
>> - Infrastructure Changes/Improvements:
>> - Bodhi: changes to support updating & tracking modules:
>> [*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
>> - Arbitrary branching: enables modules to versions bound to
>> something
>> other than Fedora release number:
>> [*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
>> - Bugzilla & ABRT module-awareness are still in progress
>> - COPR: support for building modules has been added and will be
>> improved over the F26 cycle
>> - Automation (Freshmaker)
>> - On Demand Compose Service (for testing and container
>> rebuilds)
>
> What does "testing" mean here?
I think it just means "things are rebuilt and sent to automated testing".
Why it doesn't say "for release" I am not sure. I may have "cleaned
up" the
text poorly.
Ralph, JanK: can you weigh in here?
>
>> - Greenwave: for policy/gating in Bodhi. User interactions
>> take
>> place in Bodhi.
>> - Installation & System Management
>> - Anaconda: still in progress
>> - DNF: Work underway to support modules, additional features need
>> to
>> be added. Please report comments/features/bugs in the [*normal
>>
>> manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
>> - Gnome Software: still in progress
>> - Host & Platform module(s): Base components that provide the
>> “operating
>> system” aspects of Modular Fedora:
>> [*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
>> [*Content tracker*](https://github.com/fedora-modularity/hp)
>> - Application modules ([*Content
>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
>> - TBD language modules (1 or more versions each)
>> - TBD database modules (1 or more versions each)
>> - TBD web server modules (1 or more versions each)
>> - TBD utility server modules (1 or more versions each)
>> - Applications as System Containers ([*Content
>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)):
>> - TBD system integrated containers
>
> This requires a container build service capable of producing these
> containers. I think the Fedora layered build service can do that for
> x86_64, but it is not capable of doing that for other architectures.
> Is support for that being worked on?
I understand that to be the case as well. We plan to do, at least, x86_64. I
need Ralph, Adam Miller, and Eliska to comment any further on the plan.
Here's my concern. If system containers are a main component of a
modular Server Edition, to the degree that it's the default way to do
some things, then not having that experience present on all the
architectures Server supports leads to a weird disparity and different
user experience. If system containers are *optional* for F27 and most
of the modularity aspects are focused on RPM/repo module artifacts,
then that is somewhat less of an impact. It's unclear to me which is
the plan here.
josh
9:58 a.m.
On Tue, Jun 27, 2017, 10:54 Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Jun 27, 2017 at 10:44 AM, langdon <langdon(a)redhat.com>
wrote:
> On 06/27/2017 08:30 AM, Josh Boyer wrote:
> >> On Sun, Jun 25, 2017 at 1:44 PM, langdon
<langdon(a)fedoraproject.org >> wrote:
>> >>> OVERVIEW
>>> ========
>> >>> As the modularity work
starts to enter Fedora with the Fedora 27
>>> release, a typical Change Proposal did not seem to do justice on
>>> capturing the moving parts and dependencies for the work to
successfully
>>> land. As a result, this document attempts to capture, at a high level,
>>> the goals and deliverables for F27. We are also providing links to the
>>> details to most aspects. Some of the details are still in progress and
>>> will change over the F26 lifecycle (e.g. which modules will be included
>>> for F27 Server).
>> >>> THE GOAL
>>> ========
>> >>> The Modularity and
Server Working Groups plan, with the help of many
>>> other groups in Fedora, to deliver a fully modularized version of the
>>> Fedora Server Edition. As an equal and complementary goal, the tooling
>>> for module creation/development, deployment and automatic testing will
>>> be as simple and automated as possible.
>>> [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
> >> Given that Server is widely used across a number of
architectures,
>> with participation from various groups using those architectures, we
>> still need Server to work on all the architectures it does today. Is
>> that your understanding as well?
> We fully expect to build for
all the supported architectures as Server
> Edition does today.
Yay!
>>> CAVEATS
>>> =======
>> >>> - Although
modularity allows for lifecycle changes, there is no plan
>>> for
>>> anything besides the normal 13 month lifecycle at this point.
>>> - Available content as modules will be less than a typical Server
>>> release
>>> - Only components that are a part of a module will be available
>>> - Any RPM that is a part of module will be available to be
>>> installed
>>> directly or in addition to the “install profile” install of the module
>> >>> ASPECTS TRACKED
>>> ===============
>> >>> - Infrastructure
Changes/Improvements:
>>> - Bodhi: changes to support updating & tracking modules:
>>> [*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
>>> - Arbitrary branching: enables modules to versions bound to
>>> something
>>> other than Fedora release number:
>>> [*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
>>> - Bugzilla & ABRT module-awareness are still in progress
>>> - COPR: support for building modules has been added and will be
>>> improved over the F26 cycle
>>> - Automation (Freshmaker)
>>> - On Demand Compose Service (for testing and container
>>> rebuilds)
> >> What does "testing" mean here?
> I think it just means
"things are rebuilt and sent to automated testing".
> Why it doesn't say "for release" I am not sure. I may have
"cleaned up"
the
> text poorly.
> Ralph, JanK: can you weigh in here?
> >>> -
Greenwave: for policy/gating in Bodhi. User interactions
>>> take
>>> place in Bodhi.
>>> - Installation & System Management
>>> - Anaconda: still in progress
>>> - DNF: Work underway to support modules, additional features
need
>>> to
>>> be added. Please report comments/features/bugs in the [*normal
>> >>> manner*](
https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
>>> - Gnome Software: still in progress
>>> - Host & Platform module(s): Base components that provide the
>>> “operating
>>> system” aspects of Modular Fedora:
>>> [*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
>>> [*Content tracker*](https://github.com/fedora-modularity/hp)
>>> - Application modules ([*Content
>>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)
):
>>> - TBD language modules (1 or more versions each)
>>> - TBD database modules (1 or more versions each)
>>> - TBD web server modules (1 or more versions each)
>>> - TBD utility server modules (1 or more versions each)
>>> - Applications as System Containers ([*Content
>>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)
):
>>> - TBD system integrated containers
> >> This requires a container build service capable of
producing these
>> containers. I think the Fedora layered build service can do that for
>> x86_64, but it is not capable of doing that for other architectures.
>> Is support for that being worked on?
> I understand that to be the case as well. We plan to do,
at least,
x86_64. I
> need Ralph, Adam Miller, and Eliska to comment any further on the plan.
Here's my concern. If system containers are a main component of a
modular Server Edition, to the degree that it's the default way to do
some things, then not having that experience present on all the
architectures Server supports leads to a weird disparity and different
user experience. If system containers are *optional* for F27 and most
of the modularity aspects are focused on RPM/repo module artifacts,
then that is somewhat less of an impact. It's unclear to me which is
the plan here.
josh
Sorry, meant to write that.. Yes, optional (but cool!)
/me needs to figure out how to capture all these clarifications somewhere
not-email
Langdon
10:02 a.m.
On Tue, Jun 27, 2017 at 02:58:04PM +0000, Langdon White wrote:
Sorry, meant to write that.. Yes, optional (but cool!)
/me needs to figure out how to capture all these clarifications somewhere
not-email
Edit them into the change proposal (since it's not approved yet) and
notify Jan that you've done that (so that he can make sure FESCo knows,
and possibly re-send to devel-announce when the changes are
substantial).
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:06 p.m.
On Tue, 2017-06-27 at 08:30 -0400, Josh Boyer wrote:
On Sun, Jun 25, 2017 at 1:44 PM, langdon
<langdon(a)fedoraproject.org> wrote:
> OVERVIEW
> ========
>
> As the modularity work starts to enter Fedora with the Fedora 27
> release, a typical Change Proposal did not seem to do justice on
> capturing the moving parts and dependencies for the work to successfully
> land. As a result, this document attempts to capture, at a high level,
> the goals and deliverables for F27. We are also providing links to the
> details to most aspects. Some of the details are still in progress and
> will change over the F26 lifecycle (e.g. which modules will be included
> for F27 Server).
>
> THE GOAL
> ========
>
> The Modularity and Server Working Groups plan, with the help of many
> other groups in Fedora, to deliver a fully modularized version of the
> Fedora Server Edition. As an equal and complementary goal, the tooling
> for module creation/development, deployment and automatic testing will
> be as simple and automated as possible.
> [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
Given that Server is widely used across a number of architectures,
with participation from various groups using those architectures, we
still need Server to work on all the architectures it does today. Is
that your understanding as well?
I'll note that the only 'release-blocking' Server deliverables are all
x86_64. The only other 'release-blocking' arch we have is armhfp, but
the 'release-blocking' deliverables for that arch are the minimal and
Xfce disk images, not any Server image (and implicitly, not any Server
product).
I'd say it's quite obviously the case that the modular Server has to
work on 'all' arches that were release-blocking for the previous
Server, but that turns out in practice to be only x86_64. How important
it is that it work immediately on other arches doesn't seem to be a
question with an immediate and obvious answer, to me. After all, at
present it is theoretically the case that we would release Fedora if
Server was entirely broken on armhfp or any other arch but x86_64; and
indeed we have recently rejected a proposed blocker bug -
https://bugzilla.redhat.com/show_bug.cgi?id=1463297 - that is a fairly
significant bug in Server on armhfp (not quite a showstopper, but
close) on the grounds that there are no release-blocking Server armhfp
deliverables...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:07 p.m.
On Tue, Jun 27, 2017 at 6:06 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2017-06-27 at 08:30 -0400, Josh Boyer wrote:
> On Sun, Jun 25, 2017 at 1:44 PM, langdon <langdon(a)fedoraproject.org> wrote:
> > OVERVIEW
> > ========
> >
> > As the modularity work starts to enter Fedora with the Fedora 27
> > release, a typical Change Proposal did not seem to do justice on
> > capturing the moving parts and dependencies for the work to successfully
> > land. As a result, this document attempts to capture, at a high level,
> > the goals and deliverables for F27. We are also providing links to the
> > details to most aspects. Some of the details are still in progress and
> > will change over the F26 lifecycle (e.g. which modules will be included
> > for F27 Server).
> >
> > THE GOAL
> > ========
> >
> > The Modularity and Server Working Groups plan, with the help of many
> > other groups in Fedora, to deliver a fully modularized version of the
> > Fedora Server Edition. As an equal and complementary goal, the tooling
> > for module creation/development, deployment and automatic testing will
> > be as simple and automated as possible.
> > [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
>
> Given that Server is widely used across a number of architectures,
> with participation from various groups using those architectures, we
> still need Server to work on all the architectures it does today. Is
> that your understanding as well?
I'll note that the only 'release-blocking' Server deliverables are all
x86_64. The only other 'release-blocking' arch we have is armhfp, but
the 'release-blocking' deliverables for that arch are the minimal and
Xfce disk images, not any Server image (and implicitly, not any Server
product).
You are correct on the existing blocker criteria.
I'd say it's quite obviously the case that the modular Server
has to
work on 'all' arches that were release-blocking for the previous
Server, but that turns out in practice to be only x86_64. How important
it is that it work immediately on other arches doesn't seem to be a
question with an immediate and obvious answer, to me. After all, at
present it is theoretically the case that we would release Fedora if
Server was entirely broken on armhfp or any other arch but x86_64; and
indeed we have recently rejected a proposed blocker bug -
https://bugzilla.redhat.com/show_bug.cgi?id=1463297 - that is a fairly
significant bug in Server on armhfp (not quite a showstopper, but
close) on the grounds that there are no release-blocking Server armhfp
deliverables...
I cannot argue with the criteria as you have set forth. However, I
never said we should block the release. I said it should work on the
architectures it does today. That is more than x86_64. We *know* we
have significant interest from multiple parties around Server on other
architectures. This comes from both the project sponsor and from
parties representing those architectures. They are even participating
members in the Server WG. So while you may not hold a Fedora release
for it, I do not think it is out of line to come into a Modular Server
release with the intention of it actually working across multiple CPU
architectures.
josh
10:20 p.m.
On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
I cannot argue with the criteria as you have set forth. However, I
never said we should block the release. I said it should work on the
architectures it does today. That is more than x86_64. We *know* we
have significant interest from multiple parties around Server on other
architectures. This comes from both the project sponsor and from
parties representing those architectures. They are even participating
members in the Server WG. So while you may not hold a Fedora release
for it, I do not think it is out of line to come into a Modular Server
release with the intention of it actually working across multiple CPU
architectures.
Well, there is of course potentially a gap between "the intention of it
actually working" and...actually working :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:54 a.m.
On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
>
> I cannot argue with the criteria as you have set forth. However, I
> never said we should block the release. I said it should work on the
> architectures it does today. That is more than x86_64. We *know* we
> have significant interest from multiple parties around Server on other
> architectures. This comes from both the project sponsor and from
> parties representing those architectures. They are even participating
> members in the Server WG. So while you may not hold a Fedora release
> for it, I do not think it is out of line to come into a Modular Server
> release with the intention of it actually working across multiple CPU
> architectures.
Well, there is of course potentially a gap between "the intention of it
actually working" and...actually working :)
One we bridge well today, given that it works on things other than x86_64.
josh
9:06 a.m.
On 28 June 2017 at 07:54, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
>>
>> I cannot argue with the criteria as you have set forth. However, I
>> never said we should block the release. I said it should work on the
>> architectures it does today. That is more than x86_64. We *know* we
>> have significant interest from multiple parties around Server on other
>> architectures. This comes from both the project sponsor and from
>> parties representing those architectures. They are even participating
>> members in the Server WG. So while you may not hold a Fedora release
>> for it, I do not think it is out of line to come into a Modular Server
>> release with the intention of it actually working across multiple CPU
>> architectures.
>
> Well, there is of course potentially a gap between "the intention of it
> actually working" and...actually working :)
One we bridge well today, given that it works on things other than x86_64.
But does it work by design or accident on those. And I don't mean that
snarkily but in a "we actually haven't looked at making it work and
focused on other parts versus looking at it at all."
In the end, we need to make this a concrete proposal. What resources
are we going to get to make sure that it can work on whatever other
architectures are being added to the list? Will these people be
dedicated to make this work and what are all the groups outside of
either modularity or server group which might be needed to make it
work? And what architectures are we talking about as must haves?
josh
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
9:20 a.m.
On Wed, Jun 28, 2017 at 10:06 AM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 28 June 2017 at 07:54, Josh Boyer
<jwboyer(a)fedoraproject.org> wrote:
> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
> <adamwill(a)fedoraproject.org> wrote:
>> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
>>>
>>> I cannot argue with the criteria as you have set forth. However, I
>>> never said we should block the release. I said it should work on the
>>> architectures it does today. That is more than x86_64. We *know* we
>>> have significant interest from multiple parties around Server on other
>>> architectures. This comes from both the project sponsor and from
>>> parties representing those architectures. They are even participating
>>> members in the Server WG. So while you may not hold a Fedora release
>>> for it, I do not think it is out of line to come into a Modular Server
>>> release with the intention of it actually working across multiple CPU
>>> architectures.
>>
>> Well, there is of course potentially a gap between "the intention of it
>> actually working" and...actually working :)
>
> One we bridge well today, given that it works on things other than x86_64.
But does it work by design or accident on those. And I don't mean that
snarkily but in a "we actually haven't looked at making it work and
focused on other parts versus looking at it at all."
We have people that test it on all the architectures it is produced,
and report and try to resolve bugs found.
In the end, we need to make this a concrete proposal. What resources
are we going to get to make sure that it can work on whatever other
architectures are being added to the list? Will these people be
Nothing is being added. We already produce Server on these architectures.
dedicated to make this work and what are all the groups outside of
either modularity or server group which might be needed to make it
work? And what architectures are we talking about as must haves?
Everyone seems to be misunderstanding what I'm saying. I am not
saying we need to make all architectures release blocking. I am
saying that we should aim to preserve status quo today, where Server
is produced across all architectures and issues preventing it from
being produced are clearly reported. That way people that are
interested in these architectures can work towards keeping the Server
Edition a viable option, irregardless of whether it is release
blocking or not.
Now, I would *love* to make Server release blocking on x86_64,
ppc64le, and aarch64. However, that's a discussion that needs to
happen with the Server WG in terms of what criteria are required, etc.
I believe that may have started for aarch64 in some way, which is
great. But that's orthogonal from modularity.
josh
8:35 p.m.
On Wed, 2017-06-28 at 07:54 -0400, Josh Boyer wrote:
On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2017-06-27 at 22:07 -0400, Josh Boyer wrote:
> >
> > I cannot argue with the criteria as you have set forth. However, I
> > never said we should block the release. I said it should work on the
> > architectures it does today. That is more than x86_64. We *know* we
> > have significant interest from multiple parties around Server on other
> > architectures. This comes from both the project sponsor and from
> > parties representing those architectures. They are even participating
> > members in the Server WG. So while you may not hold a Fedora release
> > for it, I do not think it is out of line to come into a Modular Server
> > release with the intention of it actually working across multiple CPU
> > architectures.
>
> Well, there is of course potentially a gap between "the intention of it
> actually working" and...actually working :)
One we bridge well today, given that it works on things other than x86_64.
Well, sure. I don't really know what the point of this is any more? I
don't think anyone disagrees about anything. The only point I really
wanted to raise is that we aren't at present actually committed to
ensuring Server works on arches other than x86_64 at the level of the
release process, and this might potentially mean that we wouldn't
commit to ensuring modular Server is fully functional on other arches
as part of the F27 release. I don't think there's any question that we
want the whole modularity process to fundamentally work on all arches,
though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3 p.m.
On Sun, 2017-06-25 at 13:44 -0400, langdon wrote:
OVERVIEW
========
As the modularity work starts to enter Fedora with the Fedora 27
release, a typical Change Proposal did not seem to do justice on
capturing the moving parts and dependencies for the work to successfully
land. As a result, this document attempts to capture, at a high level,
the goals and deliverables for F27. We are also providing links to the
details to most aspects. Some of the details are still in progress and
will change over the F26 lifecycle (e.g. which modules will be included
for F27 Server).
THE GOAL
========
The Modularity and Server Working Groups plan, with the help of many
other groups in Fedora, to deliver a fully modularized version of the
Fedora Server Edition. As an equal and complementary goal, the tooling
for module creation/development, deployment and automatic testing will
be as simple and automated as possible.
[*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
CAVEATS
=======
- Although modularity allows for lifecycle changes, there is no plan
for anything besides the normal 13 month lifecycle at this point.
Has there yet been any consideration given to *schedule* changes? One
thing this mail makes abundantly clear is that a lot of work is going
to be involved in even a minimally viable '1.0' implementation of the
Modularity concept. Are we confident that this work can be carried out
to a reasonable standard within a typical Fedora release cycle, and if
not, are we considering changing the Fedora 27 release schedule?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:20 p.m.
On Tue, Jun 27, 2017 at 01:00:33PM -0700, Adam Williamson wrote:
Has there yet been any consideration given to *schedule* changes?
One
thing this mail makes abundantly clear is that a lot of work is going
to be involved in even a minimally viable '1.0' implementation of the
Modularity concept. Are we confident that this work can be carried out
to a reasonable standard within a typical Fedora release cycle, and if
not, are we considering changing the Fedora 27 release schedule?
I'm not confident, but I know there a lot of people in the Factory 2.0,
Rel-Eng, Modularity, and Server WG teams working on it and planning to
make the deadlines.
If we hold to the standard schedule framework, F28 will be May 2018. If
we were to adjust the F27 schedule... December and January aren't great
for releases, so we might look at going to February, but if we do that,
May's not far off anyway. Modularity team (and everyone involved), does
that three months in either direction make a big difference?
Personally, I really like the predictable schedule for planning
reasons*, and I'd rather see a solid contingency plan which allows us to
_really_ back out if it's not 100% ready by Beta (September 5). If that
happens, we can decide to try again for F28 the next May and hopefully
be really solid. Or, if that doesn't seem like it's going to work out,
retool with another approach.
* and, candidly, with the Fedora-Red Hat liason part of my job-hat on,
so does Red Hat, and so do a lot of our other stakeholders like
upstream projects who count on Fedora releases to get their stuff to
users.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2493
days inactive
2497
days old
40 comments
16 participants
participants (16)
-
Adam Williamson -
Ben Rosser -
Igor Gnatenko -
Josh Boyer -
Kevin Fenzi -
langdon -
langdon -
Langdon White
-
Langdon White
-
Matthew Miller -
Neal Gompa -
Peter Robinson -
Petr Šabata -
Stephen Gallagher -
Stephen John Smoogen -
Tomasz Torcz