Looking for a Code stream name
Hi, I like to discuss the upcomming single common name for repositories for "Code 15-3". Given that we use the Jump concept now with Leap 15.3, it makes no sense that we offer by default SUSE_SLE_15_SP3 SLE_15_SP3_Backports openSUSE_Leap_15.3 repositories in parallel for each OBS project anymore. The content should be identical and it contradicts the purpose of having a binary compatible base. So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name. The big question is, what should this repository name be? People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation. Do you have any suggestions? thanks adrian -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
On Mon, 2021-06-21 at 13:34 +0200, Adrian Schröter wrote:
Hi,
I like to discuss the upcomming single common name for repositories for "Code 15-3".
Given that we use the Jump concept now with Leap 15.3, it makes no sense that we offer by default
SUSE_SLE_15_SP3 SLE_15_SP3_Backports openSUSE_Leap_15.3
repositories in parallel for each OBS project anymore. The content should be identical and it contradicts the purpose of having a binary compatible base.
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions?
My suggestion is to keep it simple. I like reference to Codestream 15. We should think outside of our standard terms and make it easy to understand to e.g. Debian community. Recent distrowatch review showed us that our terminology is not very well understood when they compared lifecycles of Leap and Ubuntu or Debian. Where they compared 18 vs 60. So my only wish is something that doesn't confuse outsiders from lifecycle point of view. Our current terminlogy is not a way to go.
thanks adrian
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions? My suggestion is to keep it simple. I like reference to Codestream 15.
I second that opinion. My proposals: - "scr" e.g. "SUSE-compatible repository" - "iscr" e.g. "Inter-SUSE-compatible repository" - "disr" e.g. "Distribution-branch independent SUSE/Software repository" pick one. :p as mentioned before: should be simple, the acronym should not be burned, and the acronym for itself should explain it by standing for itself. Also, I believe the S should be in there for SUSE. RH has something called SCL (Software Compatibility Lists), don't mix them up, they are a nightmare. - mike
On Montag, 21. Juni 2021, 17:01:45 CEST Michael Kromer wrote:
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions? My suggestion is to keep it simple. I like reference to Codestream 15.
I second that opinion.
My proposals: - "scr" e.g. "SUSE-compatible repository" - "iscr" e.g. "Inter-SUSE-compatible repository" - "disr" e.g. "Distribution-branch independent SUSE/Software repository"
pick one. :p
The problem I see is that people won't understand that they can use eg. "scr_15.3" repository instead of openSUSE_Leap_15.3 when they look at places like this one: http://download.opensuse.org/repositories/openSUSE:/Tools/ -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
Hey, On 21.06.21 17:07, Adrian Schröter wrote:
On Montag, 21. Juni 2021, 17:01:45 CEST Michael Kromer wrote:
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions? My suggestion is to keep it simple. I like reference to Codestream 15.
I second that opinion.
My proposals: - "scr" e.g. "SUSE-compatible repository" - "iscr" e.g. "Inter-SUSE-compatible repository" - "disr" e.g. "Distribution-branch independent SUSE/Software repository"
pick one. :p
The problem I see is that people won't understand that they can use eg. "scr_15.3" repository instead of openSUSE_Leap_15.3 when they look at places like this one:
Maybe determining if something is a variant of $CODE_STREAM by the name of the repository is not such a good idea? We can determine this inside OBS in some other way (relationship probably) and use speaking repository names like - SUSE_SLE_15_SP3 - SLE_15_SP3_Backports - openSUSE_Leap_15.3 depending on what the people chose? No need need for "consumers" of repositories to understand some new concept. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
Hey, On 21.06.21 17:07, Adrian Schröter wrote:
On Montag, 21. Juni 2021, 17:01:45 CEST Michael Kromer wrote:
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions? My suggestion is to keep it simple. I like reference to Codestream 15.
I second that opinion.
My proposals: - "scr" e.g. "SUSE-compatible repository" - "iscr" e.g. "Inter-SUSE-compatible repository" - "disr" e.g. "Distribution-branch independent SUSE/Software repository"
pick one. :p
The problem I see is that people won't understand that they can use eg. "scr_15.3" repository instead of openSUSE_Leap_15.3 when they look at places like this one:
Maybe determining if something is a variant of $CODE_STREAM by the name of the repository is not such a good idea? We can determine this inside OBS in some other way (relationship probably) and use speaking repository names like - SUSE_SLE_15_SP3 - SLE_15_SP3_Backports - openSUSE_Leap_15.3 depending on what the people chose? No need need for "consumers" of repositories to understand some new concept. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
Hi Adrian, On 21.06.21 13:34, Adrian Schröter wrote:
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
Just make it short. openSUSE_Leap_15.3 and friends always make me cringe. I always manually named my repos "Factory", "TW" and "Leap_15.2" etc. but it's additional hassle, especially as you cannot use "zypper ar obs:///..." easily with them. What about just naming it 15.3
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Everyone out there calls that beast SLES15.3 anyway, so it would fit naturally. Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
Just make it short.
openSUSE_Leap_15.3 and friends always make me cringe. I always manually named my repos "Factory", "TW" and "Leap_15.2" etc. but it's additional hassle, especially as you cannot use "zypper ar obs:///..." easily with them.
What about just naming it
15.3
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Everyone out there calls that beast SLES15.3 anyway, so it would fit naturally.
very good point, however I wouldn't use 15.3 alone, you might at some point end up with collisions with some other distro (yes, there is still quite some room, but never forget the factor of time, and OBS is quite around now) Then how about just simply: SUSE_15.3
On 21.06.21 17:22, Michael Kromer wrote:
Then how about just simply:
SUSE_15.3
Also good and still short enough. Or we go the other way: openSUSE_Leap_15.3_or_SLE_15_SP3_Backports_or_SUSE_SLE_15_SP3_or_whatever_is_related_to_SLES15_SP3 :-P -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan Seyfried composed on 2021-06-21 17:45 (UTC+0200):
Michael Kromer wrote:
Then how about just simply:
SUSE_15.3
Not so simple....
Also good and still short enough. Or we go the other way: openSUSE_Leap_15.3_or_SLE_15_SP3_Backports_or_SUSE_SLE_15_SP3_or_whatever_is_related_to_SLES15_SP3
Where does the fascination developers have with underscores and dots come from? Would anyone not know what it meant if it was SUSE153? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Monday 2021-06-21 20:29, Felix Miata wrote:
Would anyone not know what it meant if it was SUSE153?
Yes there is a problem. Example: Our gcc package used to be called "gcc33", and lo and behold, gcc went to increment its major version numbers by a factor of 10. We are now already at gcc11.
On Mon 2021-06-28, Jan Engelhardt wrote:
Would anyone not know what it meant if it was SUSE153? Yes there is a problem. Example: Our gcc package used to be called "gcc33", and lo and behold, gcc went to increment its major version numbers by a factor of 10. We are now already at gcc11.
That could be address by adding a dot, i.e. SUSE15.3? Though, realistically, even if SUSE/openSUSE did one release per month, going from 15 to 153 would take us more than a decade. ;-) Gerald
On Monday 2021-06-28 21:16, Gerald Pfeifer wrote:
On Mon 2021-06-28, Jan Engelhardt wrote:
On Monday 2021-06-21 20:29, Felix Miata wrote:
Would anyone not know what it meant if it was SUSE153? Yes there is a problem. Example: Our gcc package used to be called "gcc33", and lo and behold, gcc went to increment its major version numbers by a factor of 10. We are now already at gcc11.
That could be address by adding a dot, i.e. SUSE15.3?
https://lists.opensuse.org/archives/users/ed8d325308dc4b28816f8fe3711d6d43/
On 28.06.21 21:16, Gerald Pfeifer wrote:
On Mon 2021-06-28, Jan Engelhardt wrote:
Would anyone not know what it meant if it was SUSE153? Yes there is a problem. Example: Our gcc package used to be called "gcc33", and lo and behold, gcc went to increment its major version numbers by a factor of 10. We are now already at gcc11.
That could be address by adding a dot, i.e. SUSE15.3?
Though, realistically, even if SUSE/openSUSE did one release per month, going from 15 to 153 would take us more than a decade. ;-)
Told you so. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... Or, to phrase it less politely: Leap 15.x was a braindead idea IMNSHO from the beginning. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Mon, Jun 21, 2021 at 7:34 AM Adrian Schröter <adrian@suse.de> wrote:
Hi,
I like to discuss the upcomming single common name for repositories for "Code 15-3".
Given that we use the Jump concept now with Leap 15.3, it makes no sense that we offer by default
SUSE_SLE_15_SP3 SLE_15_SP3_Backports openSUSE_Leap_15.3
repositories in parallel for each OBS project anymore. The content should be identical and it contradicts the purpose of having a binary compatible base.
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions?
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I personally track things in my personal tracker as SUSE Linux versions and tag things as "openSUSE" or "SLE" depending on what I have to interface with. -- 真実はいつも一つ！/ Always, there's only one truth!
I did not want to be the one mentioning :-) On Mon, 2021-06-21 at 11:20 -0400, Neal Gompa wrote:
On Mon, Jun 21, 2021 at 7:34 AM Adrian Schröter <adrian@suse.de> wrote:
Hi,
I like to discuss the upcomming single common name for repositories for "Code 15-3".
Given that we use the Jump concept now with Leap 15.3, it makes no sense that we offer by default
SUSE_SLE_15_SP3 SLE_15_SP3_Backports openSUSE_Leap_15.3
repositories in parallel for each OBS project anymore. The content should be identical and it contradicts the purpose of having a binary compatible base.
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions?
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3
I personally track things in my personal tracker as SUSE Linux versions and tag things as "openSUSE" or "SLE" depending on what I have to interface with.
On 21.06.21 17:20, Neal Gompa wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3
I'd drop the "Linux" word in there. Short is beautiful. Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue 2021-06-22, Stefan Seyfried wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I'd drop the "Linux" word in there.
Short is beautiful.
Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant,
Hmm, at one point SUSE Manager is set to reach version 15, even if at the current version trajectory that might be decades (plural) out. :-) And there's openSUSE Kubic (which alas doesn't use regular version numbers at this point I believe). And openSUSE MicroOS which describes itself as "Micro Service OS built by the openSUSE community. I do agree that short is beautiful. Just "openSUSE $VERSION" or "SUSE $VERSION" may be too general. Gerald
On 22.06.21 18:18, Gerald Pfeifer wrote:
On Tue 2021-06-22, Stefan Seyfried wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I'd drop the "Linux" word in there.
Short is beautiful.
Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant,
Hmm, at one point SUSE Manager is set to reach version 15, even if at the current version trajectory that might be decades (plural) out. :-)
Is SUSE Manager a project/product you build against in OBS? Or is it just a package? (Maybe an overcomplicated set of packages, fortunately I did not have to look at it for many years :-P)
And there's openSUSE Kubic (which alas doesn't use regular version numbers at this point I believe).
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
And openSUSE MicroOS which describes itself as "Micro Service OS built by the openSUSE community.
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
I do agree that short is beautiful.
Just "openSUSE $VERSION" or "SUSE $VERSION" may be too general.
I still vote for just $VERSION :-P These other projects just have to find non-conflicting $VERSION patterns ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue, Jun 22, 2021 at 1:06 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
On 22.06.21 18:18, Gerald Pfeifer wrote:
On Tue 2021-06-22, Stefan Seyfried wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I'd drop the "Linux" word in there.
Short is beautiful.
Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant,
Hmm, at one point SUSE Manager is set to reach version 15, even if at the current version trajectory that might be decades (plural) out. :-)
Is SUSE Manager a project/product you build against in OBS? Or is it just a package? (Maybe an overcomplicated set of packages, fortunately I did not have to look at it for many years :-P)
It's a project with a bunch of packages and weird configs of its own.
And there's openSUSE Kubic (which alas doesn't use regular version numbers at this point I believe).
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
It is a project for SUSE, the openSUSE version is integrated with Factory (mostly).
And openSUSE MicroOS which describes itself as "Micro Service OS built by the openSUSE community.
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
It is a project for SUSE, the openSUSE version is integrated with Factory (mostly).
I do agree that short is beautiful.
Just "openSUSE $VERSION" or "SUSE $VERSION" may be too general.
I still vote for just $VERSION :-P
These other projects just have to find non-conflicting $VERSION patterns ;-)
Hah... -- 真実はいつも一つ！/ Always, there's only one truth!
Hello team, we've discussed this topic on yesterday's release team meeting and agreed that we'll make it a community's decision. I just sent email to openSUSE Marketing and looped in SUSE marketing for review of candidates proposed in this thread. Next steps will be a poll at survey.opensuse.org during the next week. Stay tuned and thank you for your creativity! Lubos On Tue, 2021-06-22 at 13:22 -0400, Neal Gompa wrote:
On Tue, Jun 22, 2021 at 1:06 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
On 22.06.21 18:18, Gerald Pfeifer wrote:
On Tue 2021-06-22, Stefan Seyfried wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I'd drop the "Linux" word in there.
Short is beautiful.
Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant,
Hmm, at one point SUSE Manager is set to reach version 15, even if at the current version trajectory that might be decades (plural) out. :-)
Is SUSE Manager a project/product you build against in OBS? Or is it just a package? (Maybe an overcomplicated set of packages, fortunately I did not have to look at it for many years :-P)
It's a project with a bunch of packages and weird configs of its own.
And there's openSUSE Kubic (which alas doesn't use regular version numbers at this point I believe).
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
It is a project for SUSE, the openSUSE version is integrated with Factory (mostly).
And openSUSE MicroOS which describes itself as "Micro Service OS built by the openSUSE community.
Is this a project/project you build against in OBS? Or "just" a compilation of SUSE_15.3/Factory/Tumbleweed/whatever packages plus some glue / configuration?
It is a project for SUSE, the openSUSE version is integrated with Factory (mostly).
I do agree that short is beautiful.
Just "openSUSE $VERSION" or "SUSE $VERSION" may be too general.
I still vote for just $VERSION :-P
These other projects just have to find non-conflicting $VERSION patterns ;-)
Hah...
On Tue, Jun 22, 2021 at 12:56 PM Gerald Pfeifer <gp@suse.com> wrote:
On Tue 2021-06-22, Stefan Seyfried wrote:
I'm going to throw out the "crazy" suggestion: SUSE Linux 15.3 I'd drop the "Linux" word in there.
Short is beautiful.
Unless SUSE starts to also build and ship other operating systems, "Linux" is just redundant,
Hmm, at one point SUSE Manager is set to reach version 15, even if at the current version trajectory that might be decades (plural) out. :-)
And there's openSUSE Kubic (which alas doesn't use regular version numbers at this point I believe).
And openSUSE MicroOS which describes itself as "Micro Service OS built by the openSUSE community.
I do agree that short is beautiful.
Just "openSUSE $VERSION" or "SUSE $VERSION" may be too general.
SUSE Linux $VERSION (or in OBS-speak: SUSE:Linux:$VERSION) is my proposal. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Hello Adrian, Am Montag, 21. Juni 2021, 13:34:24 CEST schrieb Adrian Schröter:
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Having an openSUSE-hat on it should *of course* be called openSUSE_Leap_15.3 - just for consistency. But that does not help the SLE people, so cant SUSE_SLE_15_SP3 not just be an alias to the above? Backports as attempt to pull more Leap into SLE is IMO obsolent on between - but for sake of consistency it may point to the above as well My 2c Axel
On Dienstag, 22. Juni 2021, 08:38:45 CEST Axel Braun wrote:
Hello Adrian,
Am Montag, 21. Juni 2021, 13:34:24 CEST schrieb Adrian Schröter:
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Having an openSUSE-hat on it should *of course* be called openSUSE_Leap_15.3 - just for consistency.
But that does not help the SLE people, so cant SUSE_SLE_15_SP3 not just be an alias to the above?
Alias (symlink?) on the stage server are not really working for the mirrors. We could have that on software.opensuse.org though (still multiple options, but all leading to the same repo). Also the entire purpose of the Jump project was to have an identical base of SLE and openSUSE. IMHO it is important to make this also visible here for all users. From that perspective I do indeed like SUSE_15.3 most as one could openSUSE seen as included here. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
Dne úterý 22. června 2021 9:10:35 CEST, Adrian Schröter napsal(a):
Also the entire purpose of the Jump project was to have an identical base of SLE and openSUSE. IMHO it is important to make this also visible here for all users.
Fool-proof openSUSE_SLE_15.3 ? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On 22.06.21 09:14, Vojtěch Zeisek wrote:
Dne úterý 22. června 2021 9:10:35 CEST, Adrian Schröter napsal(a):
Also the entire purpose of the Jump project was to have an identical base of SLE and openSUSE. IMHO it is important to make this also visible here for all users.
Fool-proof openSUSE_SLE_15.3 ?
What about SLES4SAP? Is it included, too? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 22.06.21 08:38, Axel Braun wrote:
Having an openSUSE-hat on it should *of course* be called openSUSE_Leap_15.3 -
Please not, this pattern was plain wrong from the beginning IMVHO. These are build service repo "tags" / URL components. Make them short. The UI can show whatever it wants, no matter how long. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Mon, 2021-06-21 at 13:34 +0200, Adrian Schröter wrote:
Hi,
I like to discuss the upcomming single common name for repositories for "Code 15-3".
Given that we use the Jump concept now with Leap 15.3, it makes no sense that we offer by default
SUSE_SLE_15_SP3 SLE_15_SP3_Backports openSUSE_Leap_15.3
repositories in parallel for each OBS project anymore. The content should be identical and it contradicts the purpose of having a binary compatible base.
So, in near future OBS will change it's interface and allow basically only to select one repository for "Code 15-3". You can decide to include Backports or Leap packages on top of SLE 15 SP3 as build and install dependencies, but no matter how you configure it as OBS user, the resulting repository name should have the same name.
The big question is, what should this repository name be?
People need to understand that they can use it on openSUSE Leap 15.3 or on any SUSE SLE 15 SP3 installation.
Do you have any suggestions?
thanks adrian
I think the most 'correct' suggestion would be to use the term that both SUSE and openSUSE have used for quite some time to describe what we're doing in this area "Common Code Base" So something like "CCB_153" or "CCB_15.3" would be valid shortnames This avoids the problematic trademark/product issues - we can't call something SLE when it isn't SLE, we cant call something openSUSE when it isn't openSUSE, but you need something for the shared whole. Variations with "*SUSE" or "allSUSE" might be a valid option also, to reflect it's applicability to both the commercial and community SUSE SLE/openSUSE entities. "allSUSE_15.3" has a certain ring to it for me I have some more fun suggestions including "Monolith" or "SLElephant" but I was trying to keep things sensible :) Regardsm -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Hi all, Per the conversation kicked off by Adrian there is now a survey available at https://survey.opensuse.org/ on this topic. Please submit your preference. The survey is set to close this Friday at 13:00 UTC. v/r Doug
participants (15)
-
Adrian Schröter -
Axel Braun -
Douglas DeMaio -
Felix Miata -
Gerald Pfeifer -
Henne Vogelsang -
Jan Engelhardt -
Lubos Kocman -
Luna Jernberg -
Michael Kromer -
Neal Gompa -
Richard Brown -
Robert Munteanu -
Stefan Seyfried -
Vojtěch Zeisek