On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote: > > There are module streams named 'latest', 'stable', or 'master', but it's not quite clear what exactly those mean. Some modules even have the 'master' and the 'latest' streams at the same time which feels quite confusing. > > In a similar manner, there are various unclear profile names, too. Especially the one called 'default', not always being the default profile. I see a module having three profiles called 'default', 'client' and 'server', and the 'server' is the default. What does the one named 'default' represent, then? > > We need to bring some order into this. > > The Modularity team has published naming guidelines [1] covering some of the cases, but we've recognized it doesn't cover all the cases and that it needs an overall refresh. > > So let's start with identifying different cases that should have a unified name — let's say by Monday 18 March. And then, when we see all of them listed, we can name them in a clear and consistent manner. > > I've started a list below, let's add to it and discuss. Some of them might get merged into one, others might get split into more. > > == Streams > > A) Nightly developer builds > B) The latest stable release, automatically switching to the next latest stable when available > C) Stable rolling release for projects without a clear versioning scheme > D) Devel/unstable rolling release for projects without a clear versioning scheme > > I'm leaving out the version-specific streams such as X or X.Y or even X.Y.Z, as well as the 'calver' ones as they work fine and we're not changing these. > > == Profiles Something that we really need to make clear: Profiles are essentially installation groups that are meant to be described by their use-case. When users look at the available profiles, the ideal case is for the name to indicate to them what problem it will solve. I like to use Samba as an example here because, being a large and complicated project, it would have meaningful profiles for a variety of use-cases (the below are just examples): * mount_support: Packages needed to support mounting SMB shares as local paths * smb_client: Client tools like smbclient * file_server: Packages needed to share local files to other systems * domain_controller: Packages needed to run a Windows Domain Controller * devel: Packages needed to build software that depends on Samba libraries. > > a) The most common installation if there is one I think we ought to rephrase this. Generally speaking, since we can have multiple profiles be the default (e.g. 'server' and 'client'), it makes sense in most cases to just separate the profiles by their use-case. What we *do* need to do is agree on a name for those rare cases where there's no obvious use-case name to describe them. For example, with Node.js, you wouldn't really want to name the `nodejs` package a "server". You *might* call it an "interpreter", but that's limiting. So having a generic fallback name makes sense. To date, we've used the profile name "default", but that was a holdover from early in development when we thought that we'd have DNF implement a fallback such that if the module had a profile with the special-case name "default", we would use that if the user didn't specify one at the command-line. DNF doesn't actually implement this and we now have the much more flexible modulemd-defaults approach, so the name "default" is both vestigial and confusing. RHEL 8 Beta shipped with a number of modules using the profile name "common" to satisfy this case, mostly to avoid the confusion inherent in naming a profile "default". > b) The client-side installation > c) The server-side installation > d) Installation providing a development environment such as -devel packages > > > Any other common cases for streams or profiles that need a unified name? Let's try to find them all by Monday 18 March. > > Thanks, > Adam > > [1] https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/ > -- > > Adam Šamalík > --------------------------- > Senior Software Engineer > Red Hat > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
