[modularity] First round of Boltron feedback published

[Adam Samalik]

The Modularity team has published a first round of Boltron feedback:
https://docs.pagure.org/modularity/prototype/boltron/feedback.html

Feedback is still being collected using the Boltron Walkthrough and UX
feedback form: http://bit.ly/mod-walkthrough

-- 

Adam Šamalík
---------------------------
Software Engineer
Red Hat

[Matthew Miller]

On Mon, Jul 31, 2017 at 01:47:28PM +0200, Adam Samalik wrote:
>  The Modularity team has published a first round of Boltron feedback:
>  https://docs.pagure.org/modularity/prototype/boltron/feedback.html 
From what I've seen on social media, response is largely positive.
Congratulations everyone! (And thanks!).

The thing that jumps out immediately is that respondents _really_
prefer the "dnf module install httpd" syntax — 73% love or like that,
while 7% dislike or hate it. 21% love or like "dnf install httpd" for
installing
modules, while 46% dislike or hate it. And a full half of that dislike
is hate, or in other words more people completely hate it than like or
love it _combined_. The "dnf install @httpd" syntax gets just a little
bit less hate, but also less love.

"dnf module install" is also seen as backwards compatible, although
weirdly by fewer people than who like it. (I guess the people that make
up the difference see the whole thing as not backwards compatible?
Maybe they're confused with _forward_ compatibility?)


Also, people are not particularly keen on but accepting of the idea
that multiple streams of a module can't be installed in parallel.


And people *definitely* love updates staying on the same stream, which
is good, because that's kind of the whole point.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Mon, Jul 31, 2017 at 10:59:58AM -0400, Matthew Miller wrote:
>  The thing that jumps out immediately is that respondents _really_
>  prefer the "dnf module install httpd" syntax — 73% love or like that,
>  while 7% dislike or hate it. 21% love or like "dnf install httpd" for
> installing
>  modules, while 46% dislike or hate it. And a full half of that dislike
>  is hate, or in other words more people completely hate it than like or
>  love it _combined_. The "dnf install @httpd" syntax gets just a little
>  bit less hate, but also less love. 
I talked to Langdon, who is a strong advocate of the "bare" `dnf
install httpd` syntax.

His argument is that modules should be seen as if they are
metapackages¹, and that it would be an odd extra step to have to
effectively first enable the ability to install packages and _then_
install them. I'll let Langdon make his own argument, but basically
akin to shipping Fedora split in different repos, some of them
disabled. That's because with the other options, if you install Modular
Fedora and don't have an enabled module containing the package you ask
for, you get "that doesn't exist".²

This did not convince me, exactly — but it did sway me in favor of the
`dnf install @httpd` syntax. That's because I think these are really
more like Super Comps Groups (with more and better metadata and
multi-stream powers!) than they are like virtual packages, and I still
think the bare syntax is confusing because behavior will be different
based on something you might not know before you run the command. And
we already _have_ the @whatever syntax for comps groups.

So that's now my revised personal opinion. :) In fact, I think we
should support a syntax like this:

   dnf install [rpm][@module[:stream]]

so you could do

   dnf install rpm            # install an rpm from any stream
   dnf install @module        # enable default stream of a module 
                              #   and also install default profile
   dnf install rpm@module     # enable module, install rpm from it
   dnf install *@module       # install all packages from module?
   dnf install @module:latest

It'd also be lovely to have a way to pick a profile as well as a
stream. I'm not sure of a great way to encode that. Maybe 

   dnf install {minimal}@module

with literal {}s?

This could all be backed by "dnf module install" commands, just like we
have "dnf install @compsgroup" and "dnf groupinstall compsgroup".

---

1. They're not literal RPM metapackages because 1) that would require
possibly-incompatible changes to RPM metadata and 2) this gives us the
flexibility to _possibly_ in the future integrate other packaging
formats, like native packages or containers or whatever, without
redesigning everything.

2. I guess DNF could learn to say "`foo` RPM isn't in any enabled
modules, but maybe you meant 1) a module named `foo` or 2) to enable
module `bar`, which contains RPM `foo`.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Peter Robinson]

On Tue, Aug 1, 2017 at 11:47 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Jul 31, 2017 at 10:59:58AM -0400, Matthew Miller wrote:
> > The thing that jumps out immediately is that respondents _really_
> > prefer the "dnf module install httpd" syntax — 73% love or like that,
> > while 7% dislike or hate it. 21% love or like "dnf install httpd" for
> installing
> > modules, while 46% dislike or hate it. And a full half of that dislike
> > is hate, or in other words more people completely hate it than like or
> > love it _combined_. The "dnf install @httpd" syntax gets just a little
> > bit less hate, but also less love.
>
>  I talked to Langdon, who is a strong advocate of the "bare" `dnf
>  install httpd` syntax.
>
>  His argument is that modules should be seen as if they are
>  metapackages¹, and that it would be an odd extra step to have to
>  effectively first enable the ability to install packages and _then_
>  install them. I'll let Langdon make his own argument, but basically
>  akin to shipping Fedora split in different repos, some of them
>  disabled. That's because with the other options, if you install Modular
>  Fedora and don't have an enabled module containing the package you ask
>  for, you get "that doesn't exist".²
>
>  This did not convince me, exactly — but it did sway me in favor of the
>  `dnf install @httpd` syntax. That's because I think these are really
>  more like Super Comps Groups (with more and better metadata and
>  multi-stream powers!) than they are like virtual packages, and I still
>  think the bare syntax is confusing because behavior will be different
>  based on something you might not know before you run the command. And
>  we already _have_ the @whatever syntax for comps groups. 
How does it distinguish between comps groups and modules, how does it
resolve conflcits between the two? I think a designator makes sense
but I don't think that should be @

Peter

[Matthew Miller]

On Tue, Aug 01, 2017 at 11:56:38PM +0100, Peter Robinson wrote:
>  How does it distinguish between comps groups and modules, how does
> it
>  resolve conflcits between the two? I think a designator makes sense
>  but I don't think that should be @ 
In my imagination, we'd supplant comps groups entirely, but fall back
to any provided comps groups if they are available for backwards
compatibility. We could create modules for every existing Fedora comps
group, so the compatibility would be for end-user-created groups and
third-party repos. 

I assume anaconda and compose tooling already needs to be module-aware
in order to build/create a modular release — but I may be very wrong
about that.

Using another character is okay, but the hard thing is that there's not
a lot of characters that make sense. It needs to be typable on most
keyboards without contortions, and shouldn't need a shell escape. And I
actually kind of like the conceptual idea that modules area like comps
groups, but with added fancy features like separate streams. That's a
story that's pretty easy to explain to people.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Aug 1, 2017 at 6:48 PM Matthew Miller  wrote:
> On Mon, Jul 31, 2017 at 10:59:58AM -0400, Matthew Miller wrote:
> > The thing that jumps out immediately is that respondents _really_
> > prefer the "dnf module install httpd" syntax — 73% love or like that,
> > while 7% dislike or hate it. 21% love or like "dnf install httpd" for
> installing
> > modules, while 46% dislike or hate it. And a full half of that dislike
> > is hate, or in other words more people completely hate it than like or
> > love it _combined_. The "dnf install @httpd" syntax gets just a little
.> bit less hate, but also less love.

>  I talked to Langdon, who is a strong advocate of the "bare"
> `dnf
>  install httpd` syntax. 

>  His argument is that modules should be seen as if they are
>  metapackages¹, and that it would be an odd extra step to have to
>  effectively first enable the ability to install packages and _then_
>  install them. I'll let Langdon make his own argument, but basically
>  akin to shipping Fedora split in different repos, some of them
>  disabled. That's because with the other options, if you install Modular
>  Fedora and don't have an enabled module containing the package you ask
>  for, you get "that doesn't exist".² 

I'm going to step up and argue in favor of the bare `dnf install httpd` syntax.

I think it makes a lot of sense to keep existing scripts and methods
of operation as similar as possible (look at how much chaos followed
the yum->dnf rename). If nothing else, we should be striving to reduce
the impact on existing users to as little as possible.

We're looking to get to a world where *everything*  is in a module of
some kind. In this world, does it really make any sense from a user
perspective to care how the software is partitioned under the hood?

My view is that the action of `dnf install httpd` should essentially
be (under the hood):
* Look up which modules provide the 'httpd' package
* Check the metadata for which is the "default" module stream for this
installation
* Enable the default module stream.
* Install the default profile from that module.

We then reserve the `dnf module` command for anyone who is attempting
to install a module or stream that is non-default. The benefit to this
approach is that users who are used to the way Fedora operates today
will get *exactly the same behavior*, except that additional metadata
and options are available if they realize they need or want to be on
another stream of particular software.

Furthermore, existing tools that interact with the DNF CLI will be
able to invoke it with exactly the same commands and get the same
output (well, a proper superset, anyway).

> -----BEGIN PGP SIGNATURE-----
> Version: Mailvelope v1.8.0
> Comment: https://www.mailvelope.com
>
> wkYEAREIABAFAlmBK7oJEHolVWI2uqOjAAB9kQCgkxDrVpujdzIYutJv+19u
> q1g4lG8AoJVRHt1YBWtntLDD+PCLH8pSCi8A
> =llkB
> -----END PGP SIGNATURE-----

[Subhendu Ghosh]

Well done on Boltron - still kicking the tires.

I for one, still want multi-version install capability for full modularity

scl, docker, flatpacks are journeys towards that destination - backend
build infra just has to be a lot smarter.

-subhendu
​

[Adam Samalik]

Hey Subhendu,

Glad that you like Boltron! Parallel instalation using containers, and in
the future flatpaks, is on the plan.

Adam



On Wed, 2 Aug 2017 at 05:45, Subhendu Ghosh <sghosh151(a)gmail.com&gt; wrote:

>  Well done on Boltron - still kicking the tires.
>
>  I for one, still want multi-version install capability for full modularity
>
>  scl, docker, flatpacks are journeys towards that destination - backend
>  build infra just has to be a lot smarter.
>
>  -subhendu
>  ​
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  
-- 

Adam Šamalík
---------------------------
Software Engineer
Red Hat

[Stephen John Smoogen]

On 1 August 2017 at 21:32, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>
>  On Tue, Aug 1, 2017 at 6:48 PM Matthew Miller  wrote:
>  >On Mon, Jul 31, 2017 at 10:59:58AM -0400, Matthew Miller wrote:
>  >> The thing that jumps out immediately is that respondents _really_
>  >> prefer the "dnf module install httpd" syntax — 73% love or like that,
>  >> while 7% dislike or hate it. 21% love or like "dnf install httpd" for
> installing
>  >> modules, while 46% dislike or hate it. And a full half of that dislike
>  >> is hate, or in other words more people completely hate it than like or
>  >> love it _combined_. The "dnf install @httpd" syntax gets just a
> little
>  .> bit less hate, but also less love.
>
>  > I talked to Langdon, who is a strong advocate of the "bare" `dnf
>  > install httpd` syntax.
>
>
>  > His argument is that modules should be seen as if they are
>  > metapackages¹, and that it would be an odd extra step to have to
>  > effectively first enable the ability to install packages and _then_
>  > install them. I'll let Langdon make his own argument, but basically
>  > akin to shipping Fedora split in different repos, some of them
>  > disabled. That's because with the other options, if you install Modular
>  > Fedora and don't have an enabled module containing the package you ask
>  > for, you get "that doesn't exist".²
>
>
>  I'm going to step up and argue in favor of the bare `dnf install httpd` syntax.
>
>  I think it makes a lot of sense to keep existing scripts and methods of operation as
> similar as possible (look at how much chaos followed the yum->dnf rename). If nothing
> else, we should be striving to reduce the impact on existing users to as little as
> possible.
>
>  We're looking to get to a world where *everything*  is in a module of some kind. In
> this world, does it really make any sense from a user perspective to care how the software
> is partitioned under the hood?
>
>  
The issue I am seeing with this is that people who want to keep existing
scripts are also wanting to keep existing package mechanism. If I say yum
install httpd I am expecting to get the RPMs and setup I have for N years.
I am not expecting to get a profile and modular set of tools decided by
someone else who came up with a name httpd which matches a different case
need. The same with WordPress or some other toolkit.

If the module WordPress pulls in maria-db and my site has been using
PostgreSQL, I am not just going to be confused.. I am going to be angry
because my other scripts to seed the database aren't working. The quick
answer is "Well write a profile which makes a module you want.." but that
isn't what we were striving for... that existing scripts and methods are as
similar as possible. Instead we have now forced someone at probably 2 am
when a system had to be redeployed for an emergency to learn that they have
nonworking scripts.

We keep harping on "surprise is the opposite of engagement" and then we
jump down the "surprise!" route every time we want to make a new technology
because it seems faster to get people up to speed.

>  My view is that the action of `dnf install httpd` should essentially
> be (under the hood):
>  * Look up which modules provide the 'httpd' package
>  * Check the metadata for which is the "default" module stream for this
> installation
>  * Enable the default module stream.
>  * Install the default profile from that module.
>
>  We then reserve the `dnf module` command for anyone who is attempting to install a module
> or stream that is non-default. The benefit to this approach is that users who are used to
> the way Fedora operates today will get *exactly the same behavior*, except that additional
> metadata and options are available if they realize they need or want to be on another
> stream of particular software.
>
>  Furthermore, existing tools that interact with the DNF CLI will be able to invoke it with
> exactly the same commands and get the same output (well, a proper superset, anyway).
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: Mailvelope v1.8.0
> >  Comment: https://www.mailvelope.com
> >
> >  wkYEAREIABAFAlmBK7oJEHolVWI2uqOjAAB9kQCgkxDrVpujdzIYutJv+19u
> >  q1g4lG8AoJVRHt1YBWtntLDD+PCLH8pSCi8A
> >  =llkB
> >  -----END PGP SIGNATURE----- 
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>  

-- 
Stephen J Smoogen.

[Matthew Miller]

On Wed, Aug 02, 2017 at 09:23:05AM -0400, Stephen John Smoogen wrote:
>  The issue I am seeing with this is that people who want to keep
> existing
>  scripts are also wanting to keep existing package mechanism. If I say yum
>  install httpd I am expecting to get the RPMs and setup I have for N years.
>  I am not expecting to get a profile and modular set of tools decided by
>  someone else who came up with a name httpd which matches a different case
>  need. The same with WordPress or some other toolkit.
>  
>  If the module WordPress pulls in maria-db and my site has been using
>  PostgreSQL, I am not just going to be confused.. I am going to be angry
>  because my other scripts to seed the database aren't working. The quick 
Good examples, thanks.

Do you think that this problem is as bad if we overload / replace /
enhance comps groups and the @ syntax? Or do we need to find a
different character? (Uh, I guess % is sitting out there....)



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Stephen John Smoogen]

On 2 August 2017 at 09:34, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  On Wed, Aug 02, 2017 at 09:23:05AM -0400, Stephen John Smoogen
> wrote:
>  > The issue I am seeing with this is that people who want to keep existing
>  > scripts are also wanting to keep existing package mechanism. If I say yum
>  > install httpd I am expecting to get the RPMs and setup I have for N
>  years.
>  > I am not expecting to get a profile and modular set of tools decided by
>  > someone else who came up with a name httpd which matches a different case
>  > need. The same with WordPress or some other toolkit.
>  >
>  > If the module WordPress pulls in maria-db and my site has been using
>  > PostgreSQL, I am not just going to be confused.. I am going to be angry
>  > because my other scripts to seed the database aren't working. The quick
>
>  Good examples, thanks.
>
>  Do you think that this problem is as bad if we overload / replace /
>  enhance comps groups and the @ syntax? Or do we need to find a
>  different character? (Uh, I guess % is sitting out there....)
>
>
>  
Again, if my scripts are using the @ symbol, I am expecting that I am going
to get the @ syntax. As can be seen when the comps groups get broken in a
main release, there are people who rely on it for deploying the system and
expect that certain choices are 'made'. I would go with either a new symbol
or keyword.

This will also help that people will also expect that the commands
dnf list, dnf remove, dnf <> will give the same data as dnf install does.

dnf list wordpress gives me

[root@f26 ~]# dnf list wordpress
Last metadata expiration check: 0:39:22 ago on 2017-08-02T09:07:22 EDT.
Available Packages
wordpress.noarch        4.8-1.fc26        fedora

If I do an 'dnf install wordpress' I expect to get that. Even if there is a
wordpress group. I don't see that. I need a different syntax to see groups.

Available Modules
wordpress

section.. my script will now be confused. and I will definitely confused if
I get a wordpress module of a different version than what the dnf list gave
me.




>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  


-- 
Stephen J Smoogen.

[Matthew Miller]

On Wed, Aug 02, 2017 at 09:54:22AM -0400, Stephen John Smoogen wrote:
>  > Do you think that this problem is as bad if we overload /
> replace /
>  > enhance comps groups and the @ syntax? Or do we need to find a
>  > different character? (Uh, I guess % is sitting out there....)
>  Again, if my scripts are using the @ symbol, I am expecting that I am going
>  to get the @ syntax. As can be seen when the comps groups get broken in a
>  main release, there are people who rely on it for deploying the system and
>  expect that certain choices are 'made'. I would go with either a new symbol
>  or keyword. 
Even if, as in my imagination, we could make modules behave as a
superset of comps groups?



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Stephen John Smoogen]

On 2 August 2017 at 10:50, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  On Wed, Aug 02, 2017 at 09:54:22AM -0400, Stephen John Smoogen
> wrote:
>  > > Do you think that this problem is as bad if we overload / replace /
>  > > enhance comps groups and the @ syntax? Or do we need to find a
>  > > different character? (Uh, I guess % is sitting out there....)
>  > Again, if my scripts are using the @ symbol, I am expecting that I am
>  going
>  > to get the @ syntax. As can be seen when the comps groups get broken in a
>  > main release, there are people who rely on it for deploying the system
>  and
>  > expect that certain choices are 'made'. I would go with either a new
>  symbol
>  > or keyword.
>
>  Even if, as in my imagination, we could make modules behave as a
>  superset of comps groups?
>
>
>  
The issue here is again existing expectations and interaction. If the comps
superset doesn't replace the existing set of tools, then you aren't going
to see howls of anguish when people run into this the release or 2 after
you have put it in place. If my kickstart @base or @printing doesn't change
my box to be from what the rest of the scripts are expecting to set up and
configure.. I don't see a problem.

If however a @printing sets up a configured module which tries to discover
printers and other things because the printermodule for home use does
that.. then my enterprise security guy is going to have words with me for
deploying it.


>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  


-- 
Stephen J Smoogen.