On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote:
> On Thu, Sep 15, 2016 at 02:25:52PM -0000, 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
