Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-29 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Adam Williamson 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Adam Williamson 
On Wed, 2017-06-28 at 07:54 -0400, Josh Boyer wrote:
> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Josh Boyer 
On Wed, Jun 28, 2017 at 10:06 AM, Stephen John Smoogen  wrote:
> On 28 June 2017 at 07:54, Josh Boyer  wrote:
>> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>>  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Stephen John Smoogen 
On 28 June 2017 at 07:54, Josh Boyer  wrote:
> On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
>  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-28 Thread Josh Boyer 
On Tue, Jun 27, 2017 at 11:20 PM, Adam Williamson
 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Adam Williamson 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Josh Boyer 
On Tue, Jun 27, 2017 at 6:06 PM, Adam Williamson
 wrote:
> On Tue, 2017-06-27 at 08:30 -0400, Josh Boyer wrote:
>> On Sun, Jun 25, 2017 at 1:44 PM, 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)
>>
>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread langdon 

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Adam Williamson 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Adam Williamson 
On Tue, 2017-06-27 at 08:30 -0400, Josh Boyer wrote:
> On Sun, Jun 25, 2017 at 1:44 PM, 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)
> 
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Adam Williamson 
On Mon, 2017-06-26 at 16:55 +0100, Peter Robinson wrote:
> On Mon, Jun 26, 2017 at 4:49 PM, Matthew Miller
>  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Adam Williamson 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Matthew Miller 
On Tue, Jun 27, 2017 at 02:58:04PM +, 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Langdon White 
On Tue, Jun 27, 2017, 10:54 Josh Boyer  wrote:

> On Tue, Jun 27, 2017 at 10:44 AM, langdon  wrote:
> > On 06/27/2017 08:30 AM, Josh Boyer wrote:
> >>
> >> On Sun, Jun 25, 2017 at 1:44 PM, 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)
> >>
> >> 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,

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Josh Boyer 
On Tue, Jun 27, 2017 at 10:44 AM, langdon  wrote:
> On 06/27/2017 08:30 AM, Josh Boyer wrote:
>>
>> On Sun, Jun 25, 2017 at 1:44 PM, 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)
>>
>> 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

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread langdon 

On 06/27/2017 08:30 AM, Josh Boyer wrote:

On Sun, Jun 25, 2017 at 1:44 PM, 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)

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/Bodhi)
-

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Neal Gompa 
On Mon, Jun 26, 2017 at 9:13 PM, Matthew Miller
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-27 Thread Josh Boyer 
On Sun, Jun 25, 2017 at 1:44 PM, 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)

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/Bodhi)
> -   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
>

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Tomasz Torcz 
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: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Petr Šabata 
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@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Igor Gnatenko 
-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
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread langdon 

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Stephen John Smoogen 
On 26 June 2017 at 13:55, 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.
>

Compared to the email from  Petr Šabata  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread langdon 

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Petr Šabata 
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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Stephen Gallagher 
On Mon, Jun 26, 2017 at 1:33 PM Kevin Fenzi  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Kevin Fenzi 
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




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Langdon White 
On Mon, Jun 26, 2017, 12:06 Ben Rosser  wrote:

> On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Ben Rosser 
On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Peter Robinson 
On Mon, Jun 26, 2017 at 4:49 PM, Matthew Miller
 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Petr Šabata 
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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

2017-06-26 Thread Matthew Miller 
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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org