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
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org