Re: User Visible Terminology
On 09/21/2016 03:08 PM, Honza Silhan wrote: Hi On Fri, Sep 16, 2016 at 5:02 PM, Petr Šabata wrote: On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote: On Thu, Sep 15, 2016 at 02:25:52PM -, Mary Clarke wrote: * enable vs install vs select select is the worst :) It's what I half-jokingly suggested during the last WG meeting :) The reason was it's a verb we often use when talking about modularity -- users "selecting" what modules they want on their system. Selecting/enabling/installing a module doesn't necessarily mean something will get installed on your system. I don't like "install" much for that reason. In the "enable" description is written: "Enable: enables the latest version and/or release of a module and installs the rpms listed in the default profile" so does it install something or not? Can you please provide example when the module prepared for use does not need to be installed? There might be modules which contain just shared libraries which other modules would depend on. Such modules do not need to have any installation profile, so no RPM would be installed when the module is installed - the installation of its RPMs would be done as a result of dependencies from another module. Even when there might be modules like that, I would personally vote for staying compatible with DNF subcommands as much as we can - so use "install". I presume that installation of majority of modules will result in some RPM being installed from the module. Modules which do not install any RPM during their installation are kind of special (like shared dependencies, shared services and so on) and they won't be installed by the end users in common cases. I would personally start with list of DNF commands described here http://dnf.readthedocs.io/en/latest/command_ref.html and try to describe their Modularity equivalents similarly as Jan did in the last paragraph of his email I'm replying to. Also keep in mind that when modules support is implemented in DNF it will not be in conflict with the new terminology. i.e. "dnf install httpd" == enable httpd module == install rpms of httpd module. So please reconsider "install" again. * Install: performs actions to prepare modules to run Is install a subset of enable, or does enable simply call install as a convenience if you try to enable something that's not installed? /me shrugs. Until very recently, I thought install and enable were just different verbs for the same action. I don't really understand what "install" means now either. Could someone knowledgable elaborate? * Run: run the module What does that mean? Do I *need* to run a module? Is this like "scl enable"? And how does this interact with "enable", for that matter? +1 I would like to also hear what "install" and "run" means in module terminology. It should be IMO explained before "enable" is decided to be used as a reference word. Would it be possible to provide more information about the commands and in best case provide use cases for commands? Something like: "Admin has module of version X installed. In the the same stream this module has a security fix. Admin will use "check-upgrade" which will ..., then he will ... to ... Honza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Regards, Jan Kaluza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On 09/22/2016 09:04 AM, Garrett Holmstrom wrote: On 2016-09-16 08:43, Matthew Miller wrote: On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: This is for the labeling of, for example, separate PHP 5, 6, and 7 modules? Yes. Or even variations of the same upstream version. I'm really pro-stream here because these identifiers have nothing to do with upgrade paths and some modules or module stacks wouldn't even have any concept of numbered, progressive builds/releases. It's just a label. I would save the word "version" to identify updates within these "streams". I agree on not using "version" for this. I'm not completely sold on "stream", partly because we talk about "upstream" and "downstream" so much, and this is unrelated to that. How about "branch"? That fits with the idea of "rebase" for switching between them How about "series", as in "the PHP 7 series"? Some people around modularity started using "generation" recently, this is imho also good word. Jan Kaluza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On 2016-09-16 08:43, Matthew Miller wrote: On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: This is for the labeling of, for example, separate PHP 5, 6, and 7 modules? Yes. Or even variations of the same upstream version. I'm really pro-stream here because these identifiers have nothing to do with upgrade paths and some modules or module stacks wouldn't even have any concept of numbered, progressive builds/releases. It's just a label. I would save the word "version" to identify updates within these "streams". I agree on not using "version" for this. I'm not completely sold on "stream", partly because we talk about "upstream" and "downstream" so much, and this is unrelated to that. How about "branch"? That fits with the idea of "rebase" for switching between them How about "series", as in "the PHP 7 series"? -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On Fri, Sep 16, 2016 at 11:43:35AM -0400, Matthew Miller wrote: > On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: > > > This is for the labeling of, for example, separate PHP 5, 6, and 7 > > > modules? > > > > Yes. Or even variations of the same upstream version. > > > > I'm really pro-stream here because these identifiers have > > nothing to do with upgrade paths and some modules or module > > stacks wouldn't even have any concept of numbered, progressive > > builds/releases. It's just a label. > > > > I would save the word "version" to identify updates within > > these "streams". > > I agree on not using "version" for this. I'm not completely sold on > "stream", partly because we talk about "upstream" and "downstream" so > much, and this is unrelated to that. How about "branch"? That fits with > the idea of "rebase" for switching between them "Branch" is also fine, I'd say. Especially if you consider that's exactly how these are going to be developed -- branches in dist-git. Hmm... 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: User Visible Terminology
Hi On Fri, Sep 16, 2016 at 5:02 PM, Petr Šabata wrote: > On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote: >> On Thu, Sep 15, 2016 at 02:25:52PM -, Mary Clarke wrote: >> > * enable vs install vs select >> >> select is the worst :) > > It's what I half-jokingly suggested during the last WG meeting :) > > The reason was it's a verb we often use when talking about > modularity -- users "selecting" what modules they want on > their system. > > Selecting/enabling/installing a module doesn't necessarily > mean something will get installed on your system. I don't like > "install" much for that reason. In the "enable" description is written: "Enable: enables the latest version and/or release of a module and installs the rpms listed in the default profile" so does it install something or not? Can you please provide example when the module prepared for use does not need to be installed? Also keep in mind that when modules support is implemented in DNF it will not be in conflict with the new terminology. i.e. "dnf install httpd" == enable httpd module == install rpms of httpd module. So please reconsider "install" again. >> > * Install: performs actions to prepare modules to run >> >> Is install a subset of enable, or does enable simply call install as a >> convenience if you try to enable something that's not installed? > > /me shrugs. > > Until very recently, I thought install and enable were just > different verbs for the same action. I don't really understand > what "install" means now either. Could someone knowledgable > elaborate? > >> > * Run: run the module >> >> What does that mean? Do I *need* to run a module? Is this like "scl >> enable"? And how does this interact with "enable", for that matter? > > +1 I would like to also hear what "install" and "run" means in module terminology. It should be IMO explained before "enable" is decided to be used as a reference word. Would it be possible to provide more information about the commands and in best case provide use cases for commands? Something like: "Admin has module of version X installed. In the the same stream this module has a security fix. Admin will use "check-upgrade" which will ..., then he will ... to ... Honza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On 09/16/2016 11:43 AM, Matthew Miller wrote: > On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: >>> This is for the labeling of, for example, separate PHP 5, 6, and 7 >>> modules? >> >> Yes. Or even variations of the same upstream version. >> >> I'm really pro-stream here because these identifiers have >> nothing to do with upgrade paths and some modules or module >> stacks wouldn't even have any concept of numbered, progressive >> builds/releases. It's just a label. >> >> I would save the word "version" to identify updates within >> these "streams". > > I agree on not using "version" for this. I'm not completely sold on > "stream", partly because we talk about "upstream" and "downstream" so > much, and this is unrelated to that. How about "branch"? That fits with > the idea of "rebase" for switching between them > What about "flow" or "journey"? With "flow", we could use the term "reflow" for switching between them as well. 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: User Visible Terminology
On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: > > This is for the labeling of, for example, separate PHP 5, 6, and 7 > > modules? > > Yes. Or even variations of the same upstream version. > > I'm really pro-stream here because these identifiers have > nothing to do with upgrade paths and some modules or module > stacks wouldn't even have any concept of numbered, progressive > builds/releases. It's just a label. > > I would save the word "version" to identify updates within > these "streams". I agree on not using "version" for this. I'm not completely sold on "stream", partly because we talk about "upstream" and "downstream" so much, and this is unrelated to that. How about "branch"? That fits with the idea of "rebase" for switching between them -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On Thu, Sep 15, 2016 at 06:41:10PM +0300, Alexander Ploumistos wrote: > On Thu, Sep 15, 2016 at 5:25 PM, Mary Clarke wrote: > > > > The Modularity working group is looking to standardize terminology that > > users use to interact with functionality around modules. > > > Perhaps it would be better if someone provided some examples for the > functions described here - at least for the vaguest terms. Is there a > wiki page, mailing list thread, irc log or something to get a better > idea about them? > > Also, if > > > * Upgrade: updates the module to the latest release but the same version of > > the module > > what would upgrading/updating to a higher version of a module be called? This is exactly why I'm against the "version" keyword here :) Just because another "version"/"stream" provides newer upstream version of your software doesn't mean it's really an upgrade for you. It might, it might not be. You need to consider other module metadata too. Anyway, the verb we've been using for switching between module "versions"/"streams" so far is "rebase", AFAIC. I believe that's also open for discussion. 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: User Visible Terminology
On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote:
> On Thu, Sep 15, 2016 at 02:25:52PM -, Mary Clarke wrote:
> > The Modularity working group is looking to standardize terminology that
> > users use to interact with functionality around modules. There are some
> > generally accepted terms, but there are also some that have multiple
> > choices for common functions. Some of the more debated options include:
> > * version vs stream
>
> This is for the labeling of, for example, separate PHP 5, 6, and 7
> modules?
Yes. Or even variations of the same upstream version.
I'm really pro-stream here because these identifiers have
nothing to do with upgrade paths and some modules or module
stacks wouldn't even have any concept of numbered, progressive
builds/releases. It's just a label.
I would save the word "version" to identify updates within
these "streams".
> > * enable vs install vs select
>
> select is the worst :)
It's what I half-jokingly suggested during the last WG meeting :)
The reason was it's a verb we often use when talking about
modularity -- users "selecting" what modules they want on
their system.
Selecting/enabling/installing a module doesn't necessarily
mean something will get installed on your system. I don't like
"install" much for that reason.
> > * Enable: enables the latest version and/or release of a module and
> >installs the rpms listed in the default profile
> > * Install: performs actions to prepare modules to run
>
> Is install a subset of enable, or does enable simply call install as a
> convenience if you try to enable something that's not installed?
/me shrugs.
Until very recently, I thought install and enable were just
different verbs for the same action. I don't really understand
what "install" means now either. Could someone knowledgable
elaborate?
> > * Run: run the module
>
> What does that mean? Do I *need* to run a module? Is this like "scl
> enable"? And how does this interact with "enable", for that matter?
+1
> > * Check-upgrade
>
> list-security? (And/or check-security)?
>
> > * Install profile
> > * System profile: a config file that lives with the machine
>
> What do profiles do?
The installation profiles would list components that would
get installed if that particular profile was selected by the
user, for example with permanent configuration, GUI buttons or
command line options. These could also be used for [container]
image generation. Later we'd also like to extend these with
recipes for automatic component configuration.
System profiles are something else entirely -- they define what
modules and module variants ("streams"/"versions") should be
chosen when installing new content or [automatically] upgrading
your system. How exactly that would work isn't defined yet but
the idea is that you could select modules by their "API", their
life cycle, licenses or pretty much any metadata they provide.
P
> --
> Matthew Miller
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
"Mary Clarke" wrote: > * List-enabled: lists all enabled modules If this is terminology to be displayed in a user interface, not technical identifiers, then this hyphen is wrong. "List enabled" is a verb applied to an object, and is a reasonable short form of "list all enabled modules". "List-enabled" is a compound adjective that means something like "enabled for listing". Presumably modules that aren't list-enabled are omitted from the list. > * Check-upgrade > * Check-rebase If these are supposed to mean "check whether something can be upgraded/rebased", then these hyphens are also wrong. To "check-upgrade" something means either to upgrade it in a "check" way, or else to first check it and then upgrade it. If, on the other hand, these terms can't contain spaces because they're command line parameters, then they should be written in all lowercase. And if I'm completely off base, then perhaps you should have provided a little more context. Björn Persson pgpwk4F7qXxu3.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On Thu, Sep 15, 2016 at 5:25 PM, Mary Clarke wrote: > > The Modularity working group is looking to standardize terminology that users > use to interact with functionality around modules. Perhaps it would be better if someone provided some examples for the functions described here - at least for the vaguest terms. Is there a wiki page, mailing list thread, irc log or something to get a better idea about them? Also, if > * Upgrade: updates the module to the latest release but the same version of > the module what would upgrading/updating to a higher version of a module be called? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: User Visible Terminology
On Thu, Sep 15, 2016 at 02:25:52PM -, Mary Clarke wrote: > The Modularity working group is looking to standardize terminology that users > use to interact with functionality around modules. There are some generally > accepted terms, but there are also some that have multiple choices for common > functions. Some of the more debated options include: > * version vs stream This is for the labeling of, for example, separate PHP 5, 6, and 7 modules? > * enable vs install vs select select is the worst :) > * Enable: enables the latest version and/or release of a module and >installs the rpms listed in the default profile > * Install: performs actions to prepare modules to run Is install a subset of enable, or does enable simply call install as a convenience if you try to enable something that's not installed? > * Run: run the module What does that mean? Do I *need* to run a module? Is this like "scl enable"? And how does this interact with "enable", for that matter? > * Check-upgrade list-security? (And/or check-security)? > * Install profile > * System profile: a config file that lives with the machine What do profiles do? -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
User Visible Terminology
The Modularity working group is looking to standardize terminology that users use to interact with functionality around modules. There are some generally accepted terms, but there are also some that have multiple choices for common functions. Some of the more debated options include: * version vs stream * enable vs install vs select All terms for discussion include: * List: lists all modules * List-enabled: lists all enabled modules * Info: shows detailed information about a module * Summary: provides a summary * Enable: enables the latest version and/or release of a module and installs the rpms listed in the default profile * Install: performs actions to prepare modules to run * Search: use to search for modules * Run: run the module * Disable: disables the module and the modules depending on that module * Refresh * Upgrade: updates the module to the latest release but the same version of the module * Check-upgrade * Rebase: to switch between major versions of a module * Check-rebase * Install profile * System profile: a config file that lives with the machine * Select: alternative option to enable or install * Version * Stream Take a few minutes and add terms to this list as new items or alternatives as well as respond with which ones you prefer. We will take input from everyone until EOD Friday 9/23/16. At that point, the working group will make some decisions to finalize our terms. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
