Funny it is. openSUSE plans to provide just another CentOS (SLE rebuild with Factory packages instead of RHEL/Fedora) but guys are arguing against the distro version! Are you kidding me? 9 month openSUSE releases were best of stable and fresh linux distributions. People decided to get them every year and it became more stable and less fresh. The balance was broken. Then Factory suddenly became cool but rolling distribution. And finally openSUSE releases are decides to be yep just another CentOS. Of course it should be again more stable but also it would provide too old base packages. Now SLE12 is rather fresh distro but it provides old gcc version 4.8 that provides ugly C++11/14 support. Ha you will say, we will add non-default gcc5 but OBS can't really use non-default gcc so it would be useless. Next year none of frequently updating software updates will be provided. So?.. -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.05.2015 21:23, Dmitriy Perlow wrote:

Now SLE12 is rather fresh distro but it provides old gcc version 4.8 that provides ugly C++11/14 support. Ha you will say, we will add non-default gcc5 but OBS can't really use non-default gcc so it would be useless. Next year none of frequently updating software updates will be provided. So?..

Why can't OBS use non-default gcc? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 23 May 2015 at 11:29, Wolfgang Rosenauer wrote:

Hi,

Am 22.05.2015 um 14:23 schrieb Stephan Kulow:

...

Hi,

As I'm away the next 2 weeks I wanted to share the progress so far. I setup openSUSE:42 with some source required to build SLE sources as openSUSE release. Those SLE sources are linked in a SLE12-Picks subproject to make it easier to see what's coming from where.

We have Ring 0 and Ring 1 building and Ring 1 has a DVD built too. It's not yet through openQA[¹], but I tried it locally and the installation looks like openSUSE 13.2 ;)

I don't think it makes sense to blend in Factory into this as both the life cycle and the use case of this release will be different, so I would actually start with a rather small distribution and accept inclusion requests independent from Factory (but sources will have to be in Factory too). But we need to make sure Factory copies within O:42 don't out-date too quickly.

I only understand half of what you wrote actually since OBS distro projects are black magic to me. My main question: - where to download the DVD image - and in which repo I get changes/updates?

;-)

Thanks, Wolfgang

I'll try and decode en_Coolo into en_GB We have the earliest Pre-Alpha, incomplete images built for openSUSE 42. They're probably useless for any 'real work', but are a good starting point for testing. They're using the SLE Sources with openSUSE branding and currently contain only what we know as 'Ring 1' (ie. Everything required to install a Minimal X installation, but no other packages) You can see the results of the first tests of this image in openQA - http://s.kulow.org/core-qa Where do we go from here? For Package Maintainers: Coolo's suggestion is to have openSUSE 42 as a separate project in OBS, and not automatically inherit anything from Factory, so people will need to submit to the openSUSE 42 Project in OBS - https://build.opensuse.org/project/show/openSUSE:42 . I don't know how ready we are for that just yet, with coolo on vacation I'd expect nothing will really move in this area for the next two weeks, but I think it's good that people consider this approach, give feedback, get used to how it'll work, etc. For Testers/Bugfixers: Please review the openQA results, file bugs and try and help fix the bugs - For example, it looks like the current image is inappropriately installing the Xen kernel and trying to use it by default - https://openqa.opensuse.org/tests/64041/modules/first_boot/steps/1 For anyone who wants the DVD to play with: You can get it from the 'Download ISO' button from any openQA test results, eg - https://openqa.opensuse.org/tests/64041/asset/3740 As for update repos - Paitence is a virtue, we probably want more of a complete distro before we worry too much about update repos and such ;) Hope this helps, (P.S. I'm also on vacation for the next 2 weeks, so don't be surprised if any replies are few and far between compared to usual) Thanks, Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 23.05.2015 um 12:02 schrieb Wolfgang Rosenauer:

I wasn't really talking about an update repo but the repo I need to add to follow the evolvement of 42. I cannot find anything on download.opensuse.org but that's probably because it also does not exist yet? Reinstalling/updating from a DVD image sounds not very efficient.

Something related: Is in coolo's :42 already a method to merge SLE updates? At some point we would freeze obviously but for the moment we probably want to have all released updates? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 24 of May 2015 08:08:42 Andrei Borzenkov wrote:

I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability.

I don't think so. If e.g. konversation crashes, it's definitely unfortunate and annoying but I still see it as a problem of much lower importance than a crashing kernel or a security bug in OpenSSL. So I do see some merit in having a stable base ("core" packages) from SLE (or based on it) and some (less stable) fancy stuff on top of it.

Another consideration - how are bug reports supposed to be handled? What happens if I report a bug against SLE package in openSUSE 42? Who is going to handle it? WIll it be merged back in SLE? I doubt very much, because at least some bugs will be caused by interaction with software versions that do not even exist in SLE.

If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.

But then it means the first problem will make SLE and openSUSE diverge and again mean that the same resources as today are required to maintain it.

Having one or two extra patches doesn't automatically mean you are on your own. Take the evergreen kernel as an example: there are few patches added and the configuration is very different but most of the time, the merge of SLE changes just works; and even if there are conflicts, resolving them is much less work than maintaining a set of kernel packages on my own would be.

Having CentOS like rebranded SLE will likely have its user base which is different from current openSUSE or TW, which can be considered as added value. Having mix and match won't be used by those needing SLE stability nor by those needing relatively modern versions openSUSE offers.

If the new release is going to be (rebranded) SLE packages as core and some non-core packages on top of it, it would actually be a superset of that "SLEntOS". In other words, if you want a "SLEntOS", you could have it by installing only those core packages and none of the extra ones. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 06:15 PM, Christian Boltz wrote:

Hello,

Am Montag, 25. Mai 2015 schrieb Michal Kubecek:

...

On Sunday 24 of May 2015 08:08:42 Andrei Borzenkov wrote:

...

I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability.

I don't think so. If e.g. konversation crashes, it's definitely unfortunate and annoying but I still see it as a problem of much lower importance than a crashing kernel or a security bug in OpenSSL. So I do see some merit in having a stable base ("core" packages) from SLE (or based on it) and some (less stable) fancy stuff on top of it.

What about updated core packages?

AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]).

I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.

That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZPXSAAoJEE4FgL32d2Ukw30H/RYM/47WIYAhxGpWeLs4swBw VJLMZ1vDIkyMPPKZE44Hp6+eyzRfW6hZqqDJulsuXNMRwmRXAJh9lukWpR7Aq7vv 7elpgnBUPegW1WUI1h6IGh6xSadWRlzh3sk816jAp1gWgRtktvvEaWZr0gtMOax7 n2ubJfa0O89M6q3kB8CeDXfGr/nvlmj3MoaeVSotx7PSfRHCEAEoXgdglk2aMyl5 mhZHLlIE/Sd+h/Pi5eJuVDQ6FDUtYDsX+KxVF6JMVk7Dx9DKaqE46fzyDGeTbbxP zpCakO1tQ3468BIO4Q94fj01uS+2U52Eli4vyhaEfY9da50eSgNXdxlYBae13Cg= =MFQo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. schrieb:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2015-05-27 00:38, Robert Schweikert wrote:

...

That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting.

Another point of interest, is that bugzillas against SLE are private by default. Many more bugzillas than currently will have to cross the "frontier" now...

That's a good point. I personally think that it would be good for SUSE to adopt a rule similar to what Mozilla uses, "everything (bug reports in this case) is open [by default], unless there is a really good argument why it should be (temporarily?) hidden from the public". That rule is pretty flexible, and at Mozilla we tend to err on the side of openness when there is doubt, but that can be handled as needed. But I don't see any good reason why bug reports on common and/or FLOSS packages need to be kept closed by default - unless they are security issues, which should be kept closed until a public advisory is published. All that said, the openSUSE community can't decide the policies of SUSE, of course. I'm just saying that I think such a rule would make sense. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 27.05.2015 um 15:32 schrieb Richard Brown:

In the past, putting this information in 'Private Comments' in bugzilla was felt to be insufficient, as lots of non-employees also had access to Private Comments, so the only viable option was to make the entire bug Private.

That's wrong. It's the other way round. Private comments are only seen by "internal" accounts (basically "@novell.com" login), while private bugs can sometimes be seen by partners and by everyone who is on CC: list.

However, with the recent changes to SUSE's Bugzilla, this was changed so Private Comments are now only visible to employees.

This was always the case. And I know, as I'm using bugzilla with three accounts: external, partner and internal (subcontractor). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 27 of May 2015 00:15:31 Christian Boltz wrote:

What about updated core packages?

AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]).

I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.

IMHO in the end it will always be up to the package maintainer(s) to decide if the benefits (both functional and maintenance) of newer package version outweigh losing the easier life of consuming SLE updates. (For leaf packages, that is. For packages others depend on, interest of those will have to be taken into account.)

...

If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.

Nice if condition ;-)

What happens if the bug is caused by a package that was updated in openSUSE 42, but not in SLE? (The above example shows that this is something that can happen in practise.)

I have a problem with the construct of "a bug in package A caused by package B". I suppose you what you really mean is a bug in core package A that didn't manifest until non-core package B was used with it". I'm afraid there can't be a general rule for this. It will always depend on seriousness of the bug, intrusiveness of the fix and some other factors. After all, we (1) often fix bugs in SLE packages that need third-party software to manifest and (2) sometimes don't fix acknowledged bugs (even those not requiring any extra SW to manifest) with known fix if there are good reasons not to. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24 May 2015 at 17:11, Wolfgang Rosenauer wrote:

So yes, the DVD installation does not boot because the xen package is missing but the kernel-xen package is installed.

Even worse is that kernel-xen is the only kernel package on the DVD while the remainder of xen is missing. Since I have no idea what needs to happen now and not even know where to report bugs about it I'm pretty much stuck already.

Wolfgang

https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE%20Distribution the Version number would be incorrect, so I'd recommend any bugs filed about the 'next version of the distro' should be tagged with [openSUSE 42] in the Summary field for now -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 23 May 2015 at 14:24, Richard Brown wrote:

Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)

I managed to click send without finishing this thought.. ..we could have called it openSUSE 12.4, and kept on just adding 0.1 forever, so we'd be openSUSE 12.7 or so now) at least the proposed new numbering, starting at 42 and keeping in sync with the version of SLE sources used by adding 30 (eg 42.1 would be based on SLE 12 SP1 sources) would mean users would know when there is a major codebase change (43 would be based on SLE 13) and that's going to be something important for people to know going forward. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.05.2015 um 14:43 schrieb Carlos E. R.:

I have no idea what the number 42 means. See:

http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Ga... and: https://en.opensuse.org/S.u.S.E._Linux_4.2 Stefan -- www.invis-server.org Stefan Schäfer Ludwigstr. 1-3 63679 Schotten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. schrieb:

Well,

...

thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)

Actually, it's in complete congruence with the seriousness displayed in the book this is sourced from. And yes, it's just as crazy as some discussions here. If you like those, you surely adore the book.

...

https://en.opensuse.org/S.u.S.E._Linux_4.2

Well, the wikipedia disagrees, says the first version was 3/94.

No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I kind of like the openSUSE 42.1 naming/release number. I also like Hitchhiker's Guide to the Galaxy and the tie-in with the history of SUSE and YaST. On Sat, May 23, 2015 at 7:52 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-05-24 02:16, Robert Kaiser wrote:

...

Carlos E. R. schrieb:

...

Well,

...

thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)

Actually, it's in complete congruence with the seriousness displayed in the book this is sourced from. And yes, it's just as crazy as some discussions here. If you like those, you surely adore the book.

Mmm.

...

...

...

https://en.opensuse.org/S.u.S.E._Linux_4.2

Well, the wikipedia disagrees, says the first version was 3/94.

No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins

And in http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Versions it clearly shows 3/94 as the first one, Slackware based, kernel 1.0

- -- Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlVhINUACgkQja8UbcUWM1xZQQEAmTpY2/P1tzO+9mCK1dXV9JEB WVx5WXRFFkfZJmVjvHoA/RBNA8kmbguNoJ+hLnKdTrTfSswrEf2jFfdPRf5FGuBO =2IVL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Sincerely, Bob Martens Webmaster/Technician Martin Luther College http://mlc-wels.edu -- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2015-05-23 14:24, Richard Brown wrote:

...

On 23 May 2015 at 14:06, Angelos Tzotsos wrote:

...

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward

Why? What is the reasoning behind those statements?

I would like the openSUSE numbers be the same or very similar to the SLES numbers of the release they base on. That would really mean something and be useful.

...

I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.

I have no idea what the number 42 means.

And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known. /Per -- Per Jessen, Zürich (15.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-23 20:48, Per Jessen wrote:

Carlos E. R. wrote:

...

I have no idea what the number 42 means.

And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.

I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhBkAACgkQja8UbcUWM1yhhgD+LK22apLeIFmPto7B++h74Fjp i1nN0U4ga5tcggKBMgYA/jSaFUmkJOM06jgHGU2ryRgEUi8QcFaHwpeilNY/CoFy =mlTX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 23 May 2015 19:06:24 -0400 Roman Bysh wrote:

On 05/23/2015 06:59 PM, Carlos E. R. wrote:

...

On 2015-05-23 20:48, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

I have no idea what the number 42 means.

And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.

I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know.

Great book. Very entertaining movie.

And, first of all, possibly best of all, a great radio serial. Also TV serial. -- Graham Davis [Retired Fortran programmer - now a mere computer user] openSUSE Tumbleweed (64-bit); KDE 4.14.6; Kernel: 4.0.0; Processor: AMD Phenom II X2 550; Video: nVidia GeForce 210 (using nouveau driver); Sound: ATI SBx00 Azalia (Intel HDA) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Not in Spain. Totally unknown.

It is only known is some parts of the world, and by certain people.

just google for: the answer to life the universe and everything -- Victor Pereira SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:

...

And, first of all, possibly best of all, a great radio serial. Also TV serial.

Not in Spain. Totally unknown.

I find that hard to believe, actually. You are not "all of Spain". There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole. And now you know about it. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2015-05-26 23:27, victorhck wrote:

El 26/05/15 a las 23:10, Jim Henderson escibió:

...

On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:

...

I find that hard to believe, actually. You are not "all of Spain".

...

There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole.

Obviously :-)

...

And now you know about it.

I still do not know if it is about science fiction or politics.

Not totally unkown in Spain.

I'm from Spain and I hear about it, and many other Geekos in spanish IRC channel, and other bloggers...

Well, I asked my friends and they don't :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Wed, 27 May 2015 05:28:54 +0200, Carlos E. R. wrote:

On 2015-05-26 23:27, victorhck wrote:

...

El 26/05/15 a las 23:10, Jim Henderson escibió:

...

On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:

...

...

I find that hard to believe, actually. You are not "all of Spain".

...

There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole.

Obviously :-)

...

...

And now you know about it.

I still do not know if it is about science fiction or politics.

Then you should read the book or listen to the radio series.

...

Not totally unkown in Spain.

I'm from Spain and I hear about it, and many other Geekos in spanish IRC channel, and other bloggers...

Well, I asked my friends and they don't :-p

Not exactly a representative sampling of the entire population of Spain. And a stupid thing to be arguing about, too. If we came up with a sequential series of numbers, there's be someone who "didn't get it" or "didn't like it". Version numbers are generally all about bikeshedding and not much else. Contribute something meaningful rather than a debate about what number we should use for the next release. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 18:59, Jim Henderson wrote:

On Wed, 27 May 2015 05:28:54 +0200, Carlos E. R. wrote:

And a stupid thing to be arguing about, too. If we came up with a sequential series of numbers, there's be someone who "didn't get it" or "didn't like it". Version numbers are generally all about bikeshedding and not much else. Contribute something meaningful rather than a debate about what number we should use for the next release.

I don't care much what number system is used, as long as it is decided on a vote, because the current scheme was decided by a vote. That's the main point. And yes, many people do not know what the number 42 stands for; do not assume that everybody has the same cultural background on Earth. That should have been explained in the proposal, and this part of the discussion would not have even started. You may think it is bikeshedding, but the current number scheme was agreed upon after much debate and a two phase vote. That decision can not be simply ignored. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmG80ACgkQtTMYHG2NR9U8iwCfVaW1m4hnhV52sEfJ5umY1c/5 migAnRYnIcOp8KGdeudKcSQyK5GbXrui =00eO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 21:57, Patrick Shanahan wrote:

* Carlos E. R. <> [05-27-15 15:37]:

iiuc, this portion of the thread is missing the point. The designation of "42" is a placeholder/temporary-identifying-mark/name-to-use-until-proven or anything it can be called *just* to identify a possible collection of applications until such time as future action can be determined. It doesn't need or have to be "voted" on as it doesn't exist as a distributed version, now or sometime in the future.

If that is so, it is acceptable. But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmJrAACgkQtTMYHG2NR9VXrQCdEIePpHatzIzW9ibB33/spjH8 ABgAnRNgnlE2BsNZVZbLCzQvJjhh3fOD =Jm/p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 22:44, Patrick Shanahan wrote:

* Carlos E. R. <> [05-27-15 16:22]:

...

But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable.

In the context it was presented, the "decided by ..." *is* acceptable as it means nothing other than a means to identify a ?project. Agree that when it is presented for distribution, the versioning scheme should be decided by committee/vote/coin-toss/or some agreed means even though that agreement *will* not satisfy the "loudest voices" :^) It is still just a project (or any other name for it, collection of works), not a distro, ie: project vs product. And still not worthy of argument. done/bye

If that is so, it is acceptable :-) But it is not what he said, or not what I understood... (and I have looked it up again to refresh my memory). - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmLacACgkQtTMYHG2NR9VAeACffPlFENCpcjHUJeF9XVzoxXIF 7WYAoJHx7IbigARUuShCboUB5dZDuoJ5 =bPoc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 23:37, Jim Henderson wrote:

On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:

So, shall we vote on each package's inclusion in the distro as well? Each version?

I never said that. Don't place words on my mouth that are not mine.

This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote.

Yes, it was. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmOkIACgkQtTMYHG2NR9V+hwCglKd5d3d/xpCHiFwrQMOTjxcU UugAn1mIZ3INOnUPdJKBgFthAfTf9b9L =RfuL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK people, On 05/27/2015 05:42 PM, Carlos E. R. wrote:

On 2015-05-27 23:37, Jim Henderson wrote:

...

On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:

...

So, shall we vote on each package's inclusion in the distro as well? Each version?

I never said that. Don't place words on my mouth that are not mine.

...

This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote.

Yes, it was.

Lets just say that a name/version discussion at some point, when there is a better defined direction, is probably prudent. However, as should be rather evident in the more technically oriented part of the thread, there is still no convergence on what is actually going to happen. There is of course also the possibility that no convergence will be achieved and then we have to figure out what that implies and how to move forward with that situation. For the most part the discussion has remained factual and focused on the issues that concern people w.r.t. the distribution, lets keep it that way. We should also acknowledge that there are voices in the community that are concerned about the naming and versioning of whatever is next and should not dismiss those concerns out of hand, even if the discussion about this topic may be a bit pre-mature. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZj8lAAoJEE4FgL32d2UkNz8H/jcMlvClPDJlD4H+VCZ03tVO 85UxwezZeCEpYLwbmCLOWfcJUriteh3ly73U0ffGt9n0Tt+BUxBxGUuR4UmmLM72 nQn/8c1dQltkNFAHjCa15UZS7XrDz1bxrkDM+B6BJjwxlrMucX+4yxFFX9G0XdD1 9RvFb4Vah+A+aIhlhBNQCwWVMBfzjvhHLc4NwFcpYQukrqoziFzOSZaWD5Qfqktk K7tEykFgrlJCmpmP/jzoF+GDLxUsVwlXHorhXO0LXLckqO1zFPfES0bFmXYlVGgJ 9H0m7ShqdqZGxEJEb0oP5DJSErCmEQZxz6NP7S5b0c1It8W7G4IBBzTkByekPzo= =yZNS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 27 May 2015 18:03:17 -0400, Robert Schweikert wrote:

We should also acknowledge that there are voices in the community that are concerned about the naming and versioning of whatever is next and should not dismiss those concerns out of hand, even if the discussion about this topic may be a bit pre-mature.

I can live with that. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op zaterdag 23 mei 2015 14:43:55 schreef Carlos E. R.:

On 2015-05-23 14:24, Richard Brown wrote:

...

On 23 May 2015 at 14:06, Angelos Tzotsos

wrote:

...

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward

Why? What is the reasoning behind those statements?

I would like the openSUSE numbers be the same or very similar to the SLES numbers of the release they base on. That would really mean something and be useful.

...

I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.

I have no idea what the number 42 means.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) Google "42". Also, the first S.u.S.E. was 4.2 for the same reason your google search will explain :) -- Gertjan Lettink, a.k.a. Knurpht

Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Richard, On 05/23/2015 03:24 PM, Richard Brown wrote:

On 23 May 2015 at 14:06, Angelos Tzotsos wrote:

...

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward Why? What is the reasoning behind those statements?

Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)

...

2. It confuses users I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem. It will lead to questions from our users "Why the big change? What is the difference from 13.2 and before?" and these are *exactly* the kind of questions we want to have our users ask, so we can answer them with very clear messages about the change to the Regular Release, how it will now be based on SLE Sources, how it'll be more stable, with a new schedule, with a new way of being built.

I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.

The surprise factor is a good point, but I would expect this not to work for a second time in the future :) I would prefer people talking about how good openSUSE is and not why the new version is +30 from SLE.

...

4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1? Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)

As long as we clearly explain the logic and meaning (or lack thereof) behind the openSUSE version numbering scheme, I don't think we're limited in what we can do if an idea like this crops up again.

3 years ago there was a *big* discussion about changing versioning model and it was followed by a vote by members. Are we going to ask members this time? Did the board decide already? Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/23/2015 04:36 PM, Richard Brown wrote:

On 23 May 2015 at 15:17, Angelos Tzotsos wrote:

...

Hi Richard,

On 05/23/2015 03:24 PM, Richard Brown wrote:

...

On 23 May 2015 at 14:06, Angelos Tzotsos wrote:

...

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward Why? What is the reasoning behind those statements?

Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning) Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..

Thanks for the effort but not convincing: Factory never had a release version, just release branches. Tumbleweed was initially based on 12.x and then 13.x before turning into a full rolling distribution. It was never officially named "Tumbleweed 13.1". Date-based release numbers make sense for Tumbleweed, 42.1 does not.

...

The surprise factor is a good point, but I would expect this not to work for a second time in the future :) I would prefer people talking about how good openSUSE is and not why the new version is +30 from SLE. Then lets focus the marketing on talking about how good openSUSE is.. that''s irrelevant to this discussion about version numbering though, unless you think one of the reasons openSUSE is good is because we used to increment the version numbers by 0.1 every 12 months ;)

I don't and never said such a thing.

...

3 years ago there was a *big* discussion about changing versioning model and it was followed by a vote by members. Are we going to ask members this time? Did the board decide already? The project doesn't make every decision based on democratic votes. We want to encourage the approach of "Those who do, decide", leave the decisions to the people actually putting stuff together for the Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release.

It is unfortunate to categorize people as "those who work on next release" and "those who don't". We have people (members) working on this project according to their available free time and skills i.e. maintaining packages, working on translations, documentation etc. Yes, there are also people working on core stuff and development of next release, and we are very grateful for their work, but it is not fair to compare everyone to Stefan ;)

We've been discussing on this list for some weeks now about the new approach for creating openSUSE releases based on the newly available SLE sources. A side effect of that requires us to reconsider the version number. I think this is a very different circumstance from 3 years ago, so I don't think that precedent from the past should be followed.

Yes, discussion is taking place on the mailing lists. But how are the decisions reached? I would prefer to see a board statement (or board meeting minutes or a vote result) each time a crucial decision is reached. Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2015 07:17 PM, Carlos E. R. wrote:

On 2015-05-23 16:42, Angelos Tzotsos wrote:

...

...

Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..

...

Thanks for the effort but not convincing: Factory never had a release version, just release branches. Tumbleweed was initially based on 12.x and then 13.x before turning into a full rolling distribution. It was never officially named "Tumbleweed 13.1". Date-based release numbers make sense for Tumbleweed, 42.1 does not.

Absolutely.

...

...

Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release. It is unfortunate to categorize people as "those who work on next release" and "those who don't".

Indeed.

I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier.

Fair enough. However, would you not agree that a major change in the source base of the "regular" openSUSE release should be accompanied by a change in numbering? If we end up with a SLE source based regular release because those that do the release work decide that's the way to go should this not be called something different than 13.3? If the answer to those two questions is yes, then I would say it is fair to say that the starting point of a new version number is arbitrary. Thus, 42 is a good or bad as any number. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZHC+AAoJEE4FgL32d2UkAF4H/2Xv/EmU0MSsfCp2CPRaXroZ 6dzgVh1QSwj6xxZyxzlEOxtOnwP/rfwSEpENjGhSDwewh/TiriuPIUwAZbzYDKuu TpQKnO9kiZBrq0Zuy4kRzAiExzaYorkVM3mIqW1GaTLNOlXp0keHmPaW7lce3Flp gTZrjFodLrZRaboaj3/3qcoXk/OvwvOG/dZHHnoO0AyZXpOFjwKptdJ1th3/YZaD qCSoVKeloTHa5AGZjrabgHWA3/33+9aGWT3mYJ6MphAzZ+JDwTpCww2Gsm3ZWVKe a31MED8zAVw1urijfcOElCaZdY4rGNxoP0E/xCNXm8hR9snqIgTwbh98xsz8yzo= =/E6U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 09:41 AM, Carlos E. R. wrote:

On 2015-05-26 15:10, Robert Schweikert wrote:

...

On 05/23/2015 07:17 PM, Carlos E. R. wrote:

...

...

I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier.

...

Fair enough.

...

However, would you not agree that a major change in the source base of the "regular" openSUSE release should be accompanied by a change in numbering?

Perhaps.

...

If we end up with a SLE source based regular release because those that do the release work decide that's the way to go should this not be called something different than 13.3?

...

If the answer to those two questions is yes, then I would say it is fair to say that the starting point of a new version number is arbitrary. Thus, 42 is a good or bad as any number.

Perhaps.

I don't oppose to call the new release "42", if that is what a vote decides.

I don't like it, though, the number 42 doesn't mean anything to me (I had to read it up), so the pun, joke or whatever is lost on me. That guide to the galaxy thing is not universally known.

Fair enough, but the number 13, that we have currently is equally arbitrary and meaningless. As stated elsewhere, and I paraphrase, version numbers are meaningless but necessary.

Me, I would prefer a numbering system that clearly shows the SLES version the work is derived from. If it comes from SLES 12 SP 2, it would have to be something wit 12 2 in the name.

But the dilemma is that we already had 12.2 and we can probably all agree that 13.2 -> 12.1 -> 12.2 -> 12.3/13.1 is probably not a good transition as it repeats very recent version numbers.

However, I will accept any voted decision. That's my main point. :-)

If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?

Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes. Every contributor has to decide for themselves whether they are going to submit the packages they maintain to the new project. Maybe the result is that the new thing is a lot smaller than our current releases. Who knows. Personally I have not yet come to terms with all of it. So far I have not heard one argument that would make me embrace the SLE source based release in the way that motivates me to do extra work. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZH1lAAoJEE4FgL32d2UkUEAIALvzEzosvTPsmvv23FLUod+o HyzBHHklP/HgXSsVKSJSCfBnm1uzYtoGa5m+NQTpCQTnv9h12WqfPaz4/gpcmXX2 thGWODFLRZx6K/jCRfCgh7pmAyok9g/PoFvMJFWba4hh0KG9vj5Zws9WDux7IwS8 3XRQUlWw40eWo+Lwa3Eov0XgGmQRHb4DvH4y/LiT43KOdSDgKR9PYx+KXvOrtpOM RneOgMSUd0Dg1cgU/ehafyj6ObuHrPw1W6ByhyQAMlXS5Ucty8ce0eWG0xtPdOzz q849ZnRNpNrFMWzh1qJ5BYuhh241y1y8y2QeRZ2baFDFx51yyF2yx3kvznsx3Z0= =d+/6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 10:40 AM, Guido Berhoerster wrote:

* Robert Schweikert [2015-05-26 16:04]:

...

...

If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?

Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.

Every contributor has to decide for themselves whether they are going to submit the packages they maintain to the new project. Maybe the result is that the new thing is a lot smaller than our current releases. Who knows. Personally I have not yet come to terms with all of it. So far I have not heard one argument that would make me embrace the SLE source based release in the way that motivates me to do extra work.

I think this has an even bigger impact than that since this initiative has the potential to completely change the rules of the game. So far maintainers had to submit to and maintain packages in Factory where they were regularly branched into stable releases, that is Factory was the means to an end of having up-to-date packages in a stable release every 8 or 12 months. Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.

I agree. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZI/1AAoJEE4FgL32d2UkuvgH/2ENHYtwF3pvslX0m2xStNW0 9+ridQ84NiinU4LUd7heWRqtNkat4Twck7anpxC0Ml7eyNII7WaFWTw03UYSD704 UFaG0R2xpj0Tif6uoVEbmddHvldq354JsC05KggmTkYFfH2+d8mopcEXdqr17abg vxZUbewOg6JkDLrKXlkQIVhCGYTZVhM7Bx1Dcbc3fzTQr57OnDylXj9jPR9YiaQH D8f6pBKvQ5OYKekav+SFqzEbfW1lasYd6gQbIySW9NVWirF/apyIweRD+C6u07lF WqsD34uVSOwcm24OhiiNINfVIgrw4LPyQvBkkj/n1uU+hj+aP5LxScnN/N+gxSc= =qsz+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:

So far maintainers had to submit to and maintain packages in Factory

Basically yes, but my understanding is that they should also maintain them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)

Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.

That could in theory happen. In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory. Regards, Christian Boltz [1] lots of things will break at once if you do this - which means a bigger pain than doing incremental updates -- Insgesamt denke ich, dass es einfacher ist, sich eine Pistole anzuschaffen und sich in den Fuß zu schiessen. Das Ergebnis ist das gleiche, aber wenigstens belästigst du nicht andere dabei. (^-^) [Sandy Drobic in postfixbuch-users über a-s-k.sourceforge.net] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Robert Schweikert [2015-05-27 00:34]:

On 05/26/2015 06:03 PM, Christian Boltz wrote:

...

Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:

...

Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.

That could in theory happen.

In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.

It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.

Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 27.05.2015 um 16:56 schrieb Dmitriy Perlow:

Guido Berhoerster Wed, 27 May 2015 10:40:34 +0300:

...

* Robert Schweikert [2015-05-27 00:34]:

...

On 05/26/2015 06:03 PM, Christian Boltz wrote:

...

Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:

...

Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.

That could in theory happen.

In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.

It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.

Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).

+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory.

An interesting statement since I don't see any real difference between "openSLE" and openSUSE releases as of today. Does that mean that you also do not fix runtime issues of your packages for openSUSE 13.x? And if you do is it just because you use it? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 27 May 2015 at 19:28, Robert Schweikert wrote:

For :42 one has to create extra requests, one has to be prepared to support packages longer, and if newer versions of core packages are needed than those that come with "free maintenance" from SUSE one has to enter into negotiations with the maintainer of that package to override the package that comes from SLE.

Where does this come from? Who said that in order for a newer version of a package to end up in openSUSE it will be required that an openSUSE contributor will need to 'enter into negotiations' with the SLE package maintainer? Sure, I hope that this whole exercise leads to more openSUSE contributors talking to more SLE engineers and visa versa, but I think you're grossly misrepresenting the nature of that collaboration with the way you present your argument here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Rosenauer Wed, 27 May 2015 19:57:38 +0300:

Am 27.05.2015 um 16:56 schrieb Dmitriy Perlow:

...

Guido Berhoerster Wed, 27 May 2015 10:40:34 +0300:

...

* Robert Schweikert [2015-05-27 00:34]:

...

On 05/26/2015 06:03 PM, Christian Boltz wrote:

...

Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:

...

Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.

That could in theory happen.

In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.

It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.

Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).

+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory.

An interesting statement since I don't see any real difference between "openSLE" and openSUSE releases as of today. Does that mean that you also do not fix runtime issues of your packages for openSUSE 13.x? And if you do is it just because you use it?

Wolfgang

I maintain all releases and Factory because I am interested in the next release. But if openSMTH is based on outdated SLE not Factory openSMTH will be useless for me because of old default (read as the only at OBS) compiler, X and other things. So what will be the reason to maintain useless releases basing on SLE and useless (since rolling doesn't suite me) Factory? -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mercredi 27 mai 2015 à 08:45 +0930, Simon Lees a écrit :

On 05/27/2015 07:33 AM, Christian Boltz wrote:

...

Hello,

...

So far maintainers had to submit to and maintain packages in Factory Basically yes, but my understanding is that they should also maintain

Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster: them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)

Hi all,

My main concern with all this as the maintainer of enlightenment and co is that currently I rely on several packages that won't be in SLE core such as luajit and bullet physics so i'm left hoping that the existing maintainers of those packages will also feel like pushing to the new openSUSE release, as it would be a significant amount of extra effort for me to start tracking extra upstreams which could much better be spent working on enlightenment related packaging. I only have so much spare time around work family etc.

Well, this will be mostly a "bootstrapping" issue for most major projects (GNOME:Factory has the same problem currently). I suggest you add a openSUSE:42 build target to your Devel project, to be able to easily track what is currently missing. And once coolo is back from vacations, some conversation will be needed on how to get the "packages missing from SLE source to oS:42". Once this initial bootstrap will be done, this extra work shouldn't be needed anymore.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 10:57 AM, Carlos E. R. wrote:

On 2015-05-26 16:04, Robert Schweikert wrote:

...

On 05/26/2015 09:41 AM, Carlos E. R. wrote:

...

On 2015-05-26 15:10, Robert Schweikert wrote:

...

On 05/23/2015 07:17 PM, Carlos E. R. wrote:

...

Fair enough, but the number 13, that we have currently is equally arbitrary and meaningless. As stated elsewhere, and I paraphrase, version numbers are meaningless but necessary.

As long as whatever number or letter system is supported by a vote, I'll be happy. This is very different from saying that this or the other system is better.

...

...

If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?

...

Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.

There are other contributors that don't package or develop.

Correct and those contributions matter as much as packaging and development.

Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us.

Well translating release notes for something that is called 13.3 or 42.1 should be about the same, taking the release notes as an example. Longer term the translation would potentially be more cyclic w.r.t. to the amount of translation needed. In a SLE-source based release idea there would be fewer changes between lets say 42.1, 42.2 than there will be 42.2 and 43.1 as within the 42 series changes to the "core" are expected to be very small while the transition to 43 would bring an "everything is new" distribution. Currently we get a ""everything is new" distribution with every "regular" release. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZI0pAAoJEE4FgL32d2Ukoj0H+gNFPsaMmjpd5QJSiq/HYRWg XnQUY2XCY0AEeAnrgldVutw+No5bcxpIqYNC1PqUnNmgsxWrThURP2Ebq1zCD0xD bvMKAdm5TkTNmVWeDDiIpApvshV+kAq6Y355DsnbWggyP80IP0wTcQXaYyVFuhyv WyNElKg6KgkE5/5F3TNKVVQZ4M0QqrZ5vNnyxNizfbSx39sQHtGxEExCw/UWoolf CB/AT2EdHmBNMvpKO927tXIVui+tM4bmduWTsfKxrklZSGrUVJoPZKPgVRwAkDc3 c6EkO3ToHN7EPlvTdHcVtjSxuA/mPIDT+by5nTa8B/M2jkq8puD4mHrs08J9NDQ= =JOxH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 11:23 PM, Carlos E. R. wrote:

On 2015-05-26 17:11, Robert Schweikert wrote:

...

On 05/26/2015 10:57 AM, Carlos E. R. wrote:

...

...

There are other contributors that don't package or develop.

...

Correct and those contributions matter as much as packaging and development.

Thanks :-)

...

...

Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us.

...

Well translating release notes for something that is called 13.3 or 42.1 should be about the same, taking the release notes as an example. Longer term the translation would potentially be more cyclic w.r.t. to the amount of translation needed. In a SLE-source based release idea there would be fewer changes between lets say 42.1, 42.2 than there will be 42.2 and 43.1 as within the 42 series changes to the "core" are expected to be very small while the transition to 43 would bring an "everything is new" distribution. Currently we get a ""everything is new" distribution with every "regular" release.

Translating release notes is almost trivial :-)

The problem is the translation of software. Currently we translate yast and zypper, and a number of programs for which openSUSE is upstream. We don't translate KDE, gnome, xfce, libreoffice, etc: that's done by their respective upstream projects.

Now, SLES is translated, at least some core languages, by paid translators. Often those same programs are translated differently by the openSUSE volunteer translators. And we dedicate more time and effort and love to it than the paid translators, I'm proud to say.

But with code ported from SLES, at least some of the openSUSE translators will be "out of a job".

It is not clear at all what we will do.

And no, we don't translate tumbleweed. Some individuals dedicate some time to it, but it is basically not done. We can't.

Makes sense. Well depending on what packagers decide they want to push into openSUSE based on SLE (openSUSE_EB EB == Enterprise Based) I am certain there will be stuff that needs translating. Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based). Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZeUHAAoJEE4FgL32d2UkjTwIAMH64krUOp4IWkzCiAOmHLrw omvB8w2Dte/Z+Yd3/9oZTjrVJ56loRxwLjwn2MCmZQAMv3pTD8d/2m8+OpwGLDrJ c2GHwvsGj6PuOAVEHlycsK5U0zbnNF8Vqay+ejjRx1m7Frb8vWzUn53Letrfxgp+ fz329qFgX4NKPiCZWlaeOOUneIiyIitkR5+EXkHF+svxpH/OlkdlTRSjQp/m1079 ng9yGFoKA+hy8fzFwd8WwugCo1bAHkhzFb4lcuMhx2wPG8MewDOeB65siwrKu59T Lslby3o66cA7vSQcrssFCyuQZqPNbpfT7YLIAVqWBUzp3AUtedK458iWnXxYInU= =L4Xx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 04:54 PM, Guido Berhoerster wrote:

* Robert Schweikert [2015-05-27 17:39]:

...

Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based).

I still don't get how this SLE base system is solving the "not enough people involved in release engineering" problem.

It doesn't and it also does not solve some of the other problems we have, IMHO, as was pointed out during one of the general sessions at oSC15. A SLE source based openSUSE release is something else to build, another approach to create a distribution. In how far this approach may or may not be interesting is, IMHO, the basis for this discussion. My point is that if those few that get the distribution out the door today decide to no longer care for a Factory snapshot based distribution release, then maybe another team will form that will pick this back up. We just have to see how this develops. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVZjkRAAoJEE4FgL32d2UkSX4H/jmt+3e0/en+YmK4kwR9a52B EtidDCCmyraIWJ/7+qMdEEyPhR2733e3783FIkFBWgk5bMumUuB8wlNC/pRLYpbE 6HNJ74N3nhJP0LjT9YHYqCKm1U8MF1pvp2myXDwBkvgIlnVpqWyVbtOI4llGd7wb XXVqEdag7OuTivJmDqGG/9QJsua8DPy1otDr9XztcBNjBD+IzNS2gQ/AFo439vZT e7+PZMCtdHbpGv7JgfPdT2o/mbeYdkN+T1h39Rgzy6B0Wq81mHX+dtWNClEfLSpm u61kQJvYbC7A0ZgWnjKjGanFCXEUYGp6PL97i265bMVcQrkdSIBova2lcU4e3tA= =idG0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 2015-05-23 15:36, Richard Brown wrote:

...

Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)

Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million,

That exactly just sucks, because it is on the edge of comparison two different things, even though I reckon that the date _is_ used as version number. A better example would be systemd, which jumped from 44 to 183 because it synced with udev. The version bump was not involved in making systemd/udev a success, and since openSUSE cannot even bring the synchronization argument, that's the result.

The project doesn't make every decision based on democratic votes. We want to encourage the approach of "Those who do, decide", leave the decisions to the people actually putting stuff together for the Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release.

It seems the definition of "working" seems to be limited to those doing OpenQA and ISO building. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.05.15 Robert Kaiser wrote:

In the end, I found it healthy to think about it that way, removes a lot of "but this is wrong" (as there is no right or wrong - remember, they're as irrelevant as necessary) and replaces it with "is it useful, can we work with this reasonably?" instead.

+1. Let's focus on what's inside the release, not how it is called... Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlVh9BEACgkQzi3gQ/xETbIRdQCgh8AKt38qmqFg07HW8pQp/X1B 8gcAn0S/7vDVSFhNBK6sFlNVR8SnT4To =fHMt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.05.2015 um 15:17 schrieb Angelos Tzotsos:

Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way?

Windows. Ok, they bumped 91.89 version numbers :-P

Version numbers should at least have a continuation (if not other meaning)

Why? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Brown schrieb:

I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.

And if it's released in Northern Hemisphere fall/autumn, it may just come with Firefox 42 out of the box! ;-) KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt composed on 2015-05-24 10:20 (UTC+0200):

Microsoft too once thought bumping version numbers bigtime is a good idea. By now, they ended up with (1, 2, 3, 95, 98, 2000, XP, Vista, 7), which messes with trivial sorting in all respectable ways, thanks to the switch from digits to letters and back again, and the breaking of strict ordering (7 > 2000?!). Please, let's learn something of that.

It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt composed on 2015-05-24 11:15 (UTC+0200):

Felix Miata wrote:

...

It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm

And, where is the problem?

Filename with version sorts do not match chronological sorts due to missing placeholders: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm should be Oct 22 2014 kernel-desktop-3.16.6-02.1.i686.rpm or maybe Oct 22 2014 kernel-desktop-3.16.602.1.i686.rpm and Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm should be Dec 21 06:54 kernel-desktop-3.16.7-07.1.i686.rpm or Dec 21 06:54 kernel-desktop-3.16.707.1.i686.rpm and Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm is OK or could be Apr 22 07:30 kernel-desktop-3.16.721.1.i686.rpm producing lists of equal digit counts like Oct 22 2014 kernel-desktop-3.16.6-02.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-07.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm and/or Oct 22 2014 kernel-desktop-3.16.602.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.707.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.721.1.i686.rpm -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt composed on 2015-05-24 12:07 (UTC+0200):

Felix Miata wrote:

...

...

...

It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm

...

...

And, where is the problem?

And instead of proceeding from 3.39 to 3.40 we got 4.0, 4.1, 4.2, etc. to get backwards again at 4.9 going to 4.10 in several months.

...

Filename with version sorts do not match chronological sorts

You know what to do for these rpms: sort -V

That's no help in a MC or FTP panel or after pasting a listing from a web browser into a spreadsheet. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2015-05-24 13:53, Stefan Seyfried wrote:

Am 24.05.2015 um 12:07 schrieb Jan Engelhardt:

...

The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7).

So what? They have an internal release number thats monotonically increasing and has not much to do with the marketing name.

So what? SLE12 is known as %suse_version==1315, but does that help? The argument always was about the marketing name - it too is desired to be monotonically increasing for one and the same product row. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2015-05-24 15:44:05 +0200, Stefan Seyfried wrote:

(Note that I don't complain about the "base it on SLES12" approach, not becaue I particularly like it, but becase *I* am not the one doing the work on this, and I heavily support the "those doing the work decide", even if it brings us stuff I don't like).

+1 darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/24/2015 07:37 PM, Jan Engelhardt wrote:

On Sunday 2015-05-24 11:35, Felix Miata wrote:

...

...

...

It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm And, where is the problem? Filename with version sorts do not match chronological sorts You know what to do for these rpms: sort -V

The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7). For this reason there is a pretty sane version number scheme behind the marketing crap that developers can use to figure out which version there running https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

It is sad to see that interesting thread was stolen by some absolutely irrelevan discussion about numbers. I still have some qeustions about how will it work exactly, hopefully Richard or someone else from the merging initiative will be able to answer it: 1. In context of SLE, what does SP1 means? Does it include only backports of fixes, or does it include version bump as well? Which effectively means, will the core of openSUSE N+0.1 be version updated with the release of SLE SP N+1 or will it stay the same? Good example will be higher Qt5 version requirement for plasma5. 2. How the important updates of core packages will be handled? Good example is recent release of GCC 5, it exposed lots of issues in different pieces of software, but lots of people would like to establish it for some reason. I would assume that the change will not go to SP in SLE, maybe only to next major version. Does it mean the same for openSUSE, or will openSUSE be used as a playground/nightly for SLE to get rid of all possible transition issues before the release of SLE? 3. Will it be possible to have different repos for core of the system (not sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the system? With some previous releases of openSUSE adding updated KDE repositories allowed the unholy mix of official/updated versions if there were any package name changes, which became obvious only much later. Would be great to have built-in defence against such cases by making it just separate repository. On Saturday 23 May 2015 14:24:46 Richard Brown wrote:

On 23 May 2015 at 14:06, Angelos Tzotsos wrote:

...

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward

Why? What is the reasoning behind those statements?

...

2. It confuses users

I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem. It will lead to questions from our users "Why the big change? What is the difference from 13.2 and before?" and these are *exactly* the kind of questions we want to have our users ask, so we can answer them with very clear messages about the change to the Regular Release, how it will now be based on SLE Sources, how it'll be more stable, with a new schedule, with a new way of being built.

I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.

...

4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1?

Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)

As long as we clearly explain the logic and meaning (or lack thereof) behind the openSUSE version numbering scheme, I don't think we're limited in what we can do if an idea like this crops up again.

-- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Frederic,

Thanx for the responses. Some follow-up questions below...

On Wednesday 27 May 2015 13:17:05 Frederic Crozat wrote:
> Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit :
> > 1. In context of SLE, what does SP1 means? Does it include only backports
> > of fixes, or does it include version bump as well? Which effectively
> > means, will the core of openSUSE N+0.1 be version updated with the
> > release of SLE SP N+1 or will it stay the same? Good example will be
> > higher Qt5 version requirement for plasma5.
> With my SLE Desktop release manager hat:
> - usually during a service pack, we try to only backport fixes but for
> some particular features request, we might do a version bump, usually
> because the feature we need can't be backported easily or the resulting
> package would be too difficult to maintain
> - during SLE12, for service pack, we might be a bit more flexible
> regarding version bump for some components (compared to SLE11)
> - so far, for SP1, there is no plan for big version bump (mostly because
> SP1 will try to stabilize even further SLE12 GA).
> 
> Regarding Qt5, we don't have plan to do a major version bump for SP1
> (because we don't have a need for it, feature wise) but doing a version
> bump in SP2 is kind of expected.
> 
> oh, and please, don't take those comments as "everything is set in
> stone" ;)

That makes sense. But that means that the gap between SLE and openSUSE will 
increase with number of SPs, increasing efforts for both parties, or is there 
some plan to keep sharing the effort in preparation for next major SLE 
release?

> > 2. How the important updates of core packages will be handled? Good
> > example is recent release of GCC 5, it exposed lots of issues in
> > different pieces of software, but lots of people would like to establish
> > it for some reason. I would assume that the change will not go to SP in
> > SLE, maybe only to next major version. Does it mean the same for
> > openSUSE, or will openSUSE be used as a playground/nightly for SLE to get
> > rid of all possible transition issues before the release of SLE?
> For gcc, this is different, because this will be a "toolchain" module
> for SLE customers (think of it as some additional repository) which will
> be in place and will update gcc stack on yearly basis, independent of
> the service pack. This is to allow customers who need a more recent gcc
> to get one, without replacing the "system" gcc.
> 
> SLE people are not recompiling and shipping the SLE codebase with the
> new gcc major version, because it might add new bugs and I'm not sure it
> would be a good idea to do this on openSUSE, since openSUSE would loose
> part of the stability gained by reusing SLE codebase at its core.
> 
> For smoothing transitions caused by a new gcc, I think TW is more
> appropriate.

Looking at packaging and buildservice mailing lists, looks like there are some 
issues when people are trying to use non-default gcc version for their 
projects. How do you think, will that be resolved, or will newer version of 
(for example) gcc be provided only for developers working on SLE/openSUSE and 
not for OBS-built packages?

> > 3. Will it be possible to have different repos for core of the system (not
> > sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the
> > system? With some previous releases of openSUSE adding updated KDE
> > repositories allowed the unholy mix of official/updated versions if there
> > were any package name changes, which became obvious only much later.
> > Would be great to have built-in defence against such cases by making it
> > just separate repository.
> 
> I guess it will be a matter of the various projects maintainers, not
> really "openSUSE:42" itself..

Ah, ok, this distinction is not yet clear to me.

-- 
Regards,
    Stas

-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 27 May 2015 14:07:33 Wolfgang Rosenauer wrote:

Am 27.05.2015 um 13:59 schrieb Stanislav Baiduzhyi:

...

That makes sense. But that means that the gap between SLE and openSUSE will increase with number of SPs, increasing efforts for both parties, or is there some plan to keep sharing the effort in preparation for next major SLE release?

Why would the gap increase with SLE SPs?

My understanding (which might also be wrong and stand corrected):

SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning.

Hm, that's right, I forgot to ask: what will be the goal of +0.1 releases of openSUSE? Will it be upgrade of WM/DE/apps on top of the same stable core of SLE, or some Ring 0/1 parts minght be affected as well? I would expect the gap increase for latter. -- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I’d like to shout “here, here” in response to Richard’s posts. It mirrors my own thoughts on the entire “let’s use SLE-sources to make something awesome” debate. Sincerely, Bob Martens Martin Luther College Webmaster/Technician http://mlc-wels.edu

On May 27, 2015, at 8:18 AM, Richard Brown wrote:

On 27 May 2015 at 14:24, Stanislav Baiduzhyi wrote:

...

Hm, that's right, I forgot to ask: what will be the goal of +0.1 releases of openSUSE? Will it be upgrade of WM/DE/apps on top of the same stable core of SLE, or some Ring 0/1 parts minght be affected as well? I would expect the gap increase for latter.

--

The 'goal' is a tough one to answer - if you haven't gathered from from Frederics answer, this is also a topic of some debate within SUSE when it comes to their Service Packs

I guess it's easier to talk about it in terms of 'opportunities' and 'expectations'

So, for SLE Service Packs, I would describe the expectations from SLE customers is that each SLE service pack will be 1) Easy to upgrade to 2) Compatible with everything they're running on top of the current Service Pack. 3) Include Fixes and Hardware enablement 4) Also include new features (either as backports, or as new versions, see #5) 5) Might also include new versions of stuff. And when I say 'stuff', I mean both 'userland' (DE/WM/apps stuff) and 'kernel-land' stuff, but still maintaining the compatibility expectation in #2.

So for SLE ,the 'goal' is to fulfil those expectations with each service pack.

For SLE 12 SP1, the current focus for SUSE seems to be on numbers 1-4. SLE 12 SP2 is likely to also include #5.

For openSUSE minor releases (based on those SLE Service Packs) I think those 'SLE Customer' expectations pretty much mirror what openSUSE user expectations will be for each minor release. So I would propose we think along the same lines for each openSUSE minor release.

However, the most contentious one seems to be around #5 - I think it's fair to say that some of our openSUSE users may wish new versions of stuff faster than SLE users expect it. (However, this is also getting a more diverse situation, with SLE customers having 'Modules' and the newly announced Backports project, both of which enable newer versions of stuff ontop of their SLE installations but with a lower support expectation)

And so, here's where I think openSUSE has opportunities. openSUSE has these SLE sources as a starting point. Somewhere for us to build from, and extend upon. If *we*, the community, decide to include more 'new stuff' in our minor versions, we can, and sometimes I think we should.

But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway.

Or to put it sufficiently, we have the opportunity to have the 'best of both worlds' with this approach, but exactly where that line is depends primarily on the work our maintainers are willing to do, the packages they submit, and the maintenance they're prepared to do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 27 May 2015 15:45:20 Richard Brown wrote:

On 27 May 2015 at 15:18, Richard Brown wrote:

...

But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway.

A little addition/addendum to this paragraph

Obviously, this situation is a little different for parts of openSUSE which are not present inside SLE, eg. KDE and all the other DE's besides GNOME.

In those cases, we don't have the SLE version and it's 'free' maintenance as a fallback, but I think the general philosophy as to what we include stays the same. Our maintainers have the opportunity to decide what they put in each openSUSE minor release

If they want to upgrade their packages in every minor release, I think that's certainly an option, but I would hope they do so in a way that is aligned with the general expectations our users are likely to have.. ie. that it's easy to upgrade to, and that it's broadly compatible with what they had in the last minor release.

Part of me is re-reading that paragraph I just wrote and realise that it is actually quite silly to read.. of course we only want to provide upgrades that work, we're openSUSE, but hey, hopefully you will all forgive my stating the obvious and get the point I'm trying to get across.

Thanx for such a wide and informative response, it's much clearer now. The only question that remains: where is the schedule or roadmap, and cool clunter on the main page? :) -- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 27 May 2015 at 14:07, Wolfgang Rosenauer wrote:

Why would the gap increase with SLE SPs?

My understanding (which might also be wrong and stand corrected):

SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning.

Wolfgang

+1 - This is exactly how I would also expect things to work out -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 23/05/2015 14:06, Angelos Tzotsos ha scritto:

On 05/22/2015 03:23 PM, Stephan Kulow wrote:

...

A word on the version: openSUSE:42 is basically the working title of this parallel code stream mixing SLE12 and openSUSE sources. But we would release snapshots of this as openSUSE releases, I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.

I would strongly suggest not to make such a version jump: 1. It is bad for marketing 2. It confuses users 3. It is awkward 4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1? +1

Please not, we don't need a big number syndrome. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi! On Fri, 2015-06-05 at 00:31 -0700, Atri Bhattacharya wrote:

On Fri, 22 May 2015 14:23:16 +0200, Stephan Kulow wrote:

...

I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.

Not to bikeshed, but personally, I like it. Notwithstanding the Hitchhiker's Guide reference, but the history of the numbers "42" in the SUSE world - SUSE Linux 4.2 being the first release, YaST's first version being 0.42 (which were, as I understand it, references to "The Answer"). Given this is a shift in release strategy, as a new generation of openSUSE releases, this variation on the traditional "starting point" for SUSE versioning makes sense.

Not to mention that it's SLE release + 30. I'm sure there are other numerological correlations that could be made as well, probably even including some that involve the numbers 6, 9 and possibly base 13. ;)

In the words of Douglas Adams (referring to the selection of "42"): "42 will do."

Enjoy the time off, and early Happy Towel Day. :)

Jim

Sorry, didn't mean to resend Jim's email, just hit the wrong button by mistake. Apologies! -- Atri Bhattacharya -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org