April 2017 - openSUSE Project - openSUSE Mailing Lists

[opensuse-project] How we will use the GSoC money
by Vincent Untz 18 Jul '24

18 Jul '24

Hi, (let's see how a public discussion about money goes :-)) The Google Summer of Code brings us great students, but also means that the openSUSE project will get $8000 (if I'm not mistaken) at the end of the summer. That's $500 per student. A while ago, I requested comments on my blog about what to do with the money, but didn't get any feedback. So I take this as "do what you feel is best", and this mail is about the plan. As a reminder, the main issue is that we will likely not have the openSUSE Foundation created in time for this. For instance, Google would like us to get some form filled before the end of June; this is not a mandatory timeline, but I think it shows that we won't be ready with the Foundation for that. The current plan is to give that money to another organization we feel close to, and I have two candidates in mind: - the Software Freedom Conservancy (http://sfconservancy.org/) it's a really nice org that provides a home for various cool projects (see http://sfconservancy.org/members/current/) and those projects help make openSUSE a great project. - the Desktop Summit (https://www.desktopsummit.org/) it's one of the biggest event this year, and this would help us have some more visibility (since we'd be sponsors, I guess). I'm sure they would welcome this to secure their budget. Note that an alternative solution would be to leave the money to Google for a future GSoC or similar program, but I feel it's better to use the money where it can make a difference today. Now, it's not too late to change the plan. If you have a better suggestion, please tell us. There's no need to argue forever about it, just explain why you think it's good. Keep in mind that if we cannot receive the money ourselves, this also means that we cannot use it to buy stuff for openSUSE. Pavol and I will take the final decision since we are the GSoC admins for openSUSE. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

22 38

[opensuse-project] openSUSE Members retirement
by Michal Hrusecky 27 May '17

27 May '17

Hi everybody, as you all know, we have the openSUSE Members, a group of contributors through their sustained and substantial contributors that are eligible to participate in elections, have @opensuse.org mail and other perks. We have now about 600 of them, but as you can see[1] in last openSUSE Board elections only 150 of them voted. This could mean two things - either most of the members are not interested in elections or plenty of them are simply no longer around. I guess the truth is somewhere in middle. This is something we need to know when we take project wide decisions in order to correctly assess the communities interest in the topic. This is a recurring topic that has been discussed at the openSUSE Board Face to Face meeting last year, oSC 15, and on this list several times over the last few years. Taking these into consideration, we (in the board) think it would be a good idea to implement something to help with ensuring our Membership list accurately reflects our current Membership. I have put together a tool which attempts to detect an openSUSE Members activity on mailing lists, OBS, bugzilla, maybe more. This tool will remember when we last saw openSUSE Member on any of those channels and if they doesn't show for 6 months, we will send them an e-mail asking whether they still wants to be a member. A response to that email will automatically count as activity and preserve the Members status. If there is no response within 30 days of the notification, the Member will be 'retired' and be considered a 'Member emeritus'. If someone is retired incorrectly, or a 'Member emeritus' returns to the Project and wants a restoration of their voting privilege, they will be unretired without question by the Membership Committee. There are few implementation details to be worked out, so we don't expect this to go live overnight but consider this a "statement of intent" and an explanation of how we expect things to work before we start testing the process. ==== To answer some of the obvious questions: Q: Shouldn't we retire inactive members anyway after measuring and evaluating their activity? A: No, that would be too hard, too subjective and it could bother people that we cannot measure automatically. Automatic measurement is just an indicator that those people are no longer interested, but they might be just working on project aspects we cannot measure. openSUSE Members are members until THEY no longer want to be. We believe this system preserves that principle. Q: Wouldn't it offend active contributors if they will be falsely accused of not being interested? A: I hope not. If period will be long enough (6 months) and if we monitor even mailing lists, people will usually show up somewhere. We intend to word the 'ping' email in a way that is not judgemental, but just makes it clear that we have failed to automatically find evidence of contribution so want to make sure they are still interested in remaining a Member. Q: Doesn't it change the meaning of the openSUSE Member? A: Not really. So far once you got a membership status, it was forever without question. Now it would be forever as long as you are interested. No big change, just a little difference. Q: What if mail with warning gets lost? A: If you lose your membership by accident by losing an e-mail, you can still contact membership committee and as a retired member you will be reinstated immediately without voting/verification that takes time. And you should fix your e-mail in connect.opensuse.org in that case ;-) Q: Will retired members retain their email & IRC cloak perks? A: No, the intention is that retired members will no longer be eligible for @opensuse.org email addresses and Freenode IRC cloaks. [1] https://connect.opensuse.org/pg/polls/read/pluskalm/49480/opensuse-board-el… -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

19 44

[opensuse-project] Re: [opensuse-factory] openSUSE Leap's Next Major Version Number
by Richard Brown 09 May '17

09 May '17

On 24 April 2017 at 07:16, Neal Gompa <ngompa13(a)gmail.com> wrote: > On Sat, Apr 22, 2017 at 7:37 AM, Richard Brown <RBrownCCB(a)opensuse.org> wrote: >> There are only a few packages in our distribution that reference the >> 42.x versioning, and they should be easily handled as part of a zypper >> dup, so we are not concerned about this decision impacting users >> upgrading. > > > This statement concerns me more than anything else. What about all the > people who build solutions around openSUSE or for it? We *just* > managed to figure out the new mess that is SUSE versioning, and now > you want to break us again? > > The number of conditionals I need for supporting the SUSE platform > keeps growing with each release, and that's extremely aggravating. Yes, I understand that, but one of the benefits of this change means you'll be able to get rid of some of those conditionals when Leap 42.3 reaches end of life, as opposed to needing to keep conditionals around for 4x.y forever -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

10 13

[opensuse-project] openSUSE Booth at FrOSCon
by ddemaio 27 Apr '17

27 Apr '17

Hi all, If anyone wants to help out at the booth at FrOSCon, please let me know. v/r Doug -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] openSUSE Leap's Next Major Version Number
by Richard Brown 25 Apr '17

25 Apr '17

Hi all, On behalf of the openSUSE Board and Leap Release Management I am pleased to announce the next version of openSUSE Leap after 42.3 will be: openSUSE Leap 15 As with Leap 42.x, minor releases are expected annually for at least 3 years, so you can expect a Leap 15.1 to follow, then 15.2 and onwards. Obviously this is quite a dramatic change from the current version number of 42.x, so I will explain what justifies this change in some detail below. First, some history. When we started openSUSE Leap, the version number was an issue that needed addressing. openSUSE at that time was at 13.2, but SUSE Linux Enterprise (SLE) was at 12 and heading towards 12 SP1. As the main unique selling point of Leap compared to every other distribution is the fact it is based on SLE sources. We wanted to reflect that in the version number. This was particularly important when you consider that a major version in SLE really means something ("major architectural changes from the last version are introduced here") whereas minor versions/service packs have a very different message ("easy to upgrade to, no major workflow breaking changes"). Leap follows a similar philosophy, so we wanted a versioning scheme to reflect SLEs. But openSUSE had already had versions starting with 12, so we couldn't sync up with SLE. This is where 42.x came from. It gave us the opportunity to establish a relationship with SLE versions (SLE Version + 30 = Leap Version), reflect the major/minor nature of Leap releases, and avoid clashes with version numbers we'd already used. The choice of 42 doubled as a humorous nod to hitchhikers guide to the galaxy and the first version numbers of SuSE Linux and YaST (4.2 and 0.42 respectively). The plan was therefore for the next version of Leap to be 43 with it's release aligned with SLE 13, followed by Leap 43.1 (with SLE 13 SP1), Leap 43.2 (w. SP2), etc However, like all good plans, things change. SUSE have decided that their next version of SLE will be 15, not 13. Upon learning of SUSE's plans the Board and Leap release team have been considering our options. This included ignoring the changes to SLE and releasing Leap 43 as planned, at the cost of the link between SLE versions and Leap versions. 45 was also considered, as were some frankly hilarious ideas that made me worry about my own sanity and that of my fellow contributors. After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version. SUSE's decision to skip SLE 13 and 14 gave us a perfect opportunity to sync up with SLE versions like we always wanted to originally with Leap. It's an opportunity we will not be able to take so easily a few years from now if we continued with Leaps current versioning. There are only a few packages in our distribution that reference the 42.x versioning, and they should be easily handled as part of a zypper dup, so we are not concerned about this decision impacting users upgrading. We are aware that this decision could be a minor annoyance for users of Leap with configuration management tools like saltstack and puppet, but the long term opportunity to simplify such configuration (by being able to treat SLE and Leap similarly) outweighed our desire to avoid a 'one-time' effort for people currently handling the overly complicated situation caused by Leap being at 42.x and SLE being at 12 SPx. Packagers should be able to look forward to an easier time of things as a result of this change. We intend to deprecate the 0%{leap_version} macro and simplify the current complex nest of suse_version and sle_versions that can make it very frustrating to build packages appropriately for Tumbleweed, Leap and SLE. 0%{suse_version} should continue to be available as a simple indicator of the major version of Leap & SLE for packagers (eg, 0%{suse_version} == 1500 is the expected value for SLE 15 and Leap 15 and all of their minor versions/service packs). 0%{sle_version} should remain as a more precise indicator when packagers need to handle specific versions of Leap and SLE (eg. 0%{sle_version} == 150000 is the expected value for SLE 15 & Leap 15, with 150100 being the expected value for SLE 15 SP1 & Leap 15.1) 0%{is_opensuse} will continue for those times when packagers need to distinguish between Leap and SLE even though they will now more closely share their versions. The above examples and what the future suse_version number will be for Tumbleweed is not yet final, so expect to see emails from ludwig in opensuse-factory(a)opensuse.org when they are set. Thanks to everyone involved in this so far, I'm looking forward to seeing what we make out of Leap 15, and even though I cross-posted this I would like to ask that any followup conversation is kept to the opensuse-project(a)opensuse.org thread. Regards, Richard Brown on behalf of the openSUSE Board -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

10 11

[opensuse-project] Proposal: a sensible versioning scheme for ALL openSUSE/SuSE products
by Mathias Homann 24 Apr '17

24 Apr '17

Hi all, i get it... openSUSE Leap 15, because SLES 15. So how about this scheme which should be BINDING for ALL products from now on: First lets get rid of that silly "Leap". Second, as of the next release, the major release number for openSUSE, SLES and SLED is 15, the minor will be 0. after that, the following conditions will be applied: A interim release ("service pack") increases the minor version. A release where either the kernel has a new minor or at least three other base components have a new major number will get the major version increased and the minor reset to 0. That would give us: openSUSE 15.0 SuSE Linux Enterprise Server 15.0 SuSE Linux Enterprise Desktop 15.0 openSUSE Tumbleweed (since TW is a rolling release version numbers on the distro are utter BS) and for the next versions: if the KERNEL gets a higher minor number (e.g. 4.11 -> 4.12), nothing else matters, and the new release would become 16.0 if three major base components (e.g. for a Desktop distro, the X server AND GNOME AND KDE/Plasma, for a Server Distro for example Samba, Postfix, Courier IMAP), get a new version with the MAJOR number being higher (GNOME 4, KDE 6, that kind of stuff) the new one would also become 16.0 If the new release does not have a new kernel, or less than three of the core coponents have a new major version, the new version would be the same major, minor increased by one. So by all probability and previous experience we'd have 15.0, 15.1, 15.2, and possibly 15.3 before getting to 16.0. on OBS that would be 1500, 1501, 1502, 1503 and 1600. and all is well. cheers MH -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

3 2

[opensuse-project] Re: [opensuse-factory] openSUSE Leap's Next Major Version Number
by Michal Kubecek 24 Apr '17

24 Apr '17

On Sunday, 23 April 2017 0:51 Jan Engelhardt wrote: > Of the projects which went to skyrocketing version numbers > (controversial in their own right), such as firefox, systemd, ... > none have dared to jump backwards. Because it'd fuck up version > comparisons everywhere. Right. Just one thing from the top of my head: mike@lion:~> rpm -qa --queryformat '%{VERSION}\n' | egrep '^42\.[12](\..*)?$' | wc -l 23 I'm pretty sure there will be others, more subtle and harder to work around (IIRC "zypper dup" is quite happy to downgrade a package if the installed version is no longer available in any active repository). Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Re: [opensuse-factory] openSUSE Leap's Next Major Version Number
by PatrickD Garvey 23 Apr '17

23 Apr '17

On Sat, Apr 22, 2017 at 1:41 PM, Mathias Homann <Mathias.Homann(a)opensuse.org> wrote: > my wife was just looking over my shoulder.... her comment: "If they can't even be > consistent about the version number scheme, what about the software?" +1 -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] oSC17 IRC Meeting - Week 8
by ddemaio 19 Apr '17

19 Apr '17

Hi all, We will have a half hour meeting today at 1600 UTC on the openSUSE-project IRC Channel on freenode to discuss the status of the openSUSE Conference. If you are giving a presentation at oSC17, please use the following template: 16x9 https://github.com/openSUSE/artwork/raw/master/Marketing%20Materials/openSU… v/r Doug Links for previous meetings Week 1 - https://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proj… Week 2 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 3 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 4 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 5 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 6 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 7 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] oSC17 IRC Meeting - Week 7
by ddemaio 12 Apr '17

12 Apr '17

Hi all, We will have a half hour meeting today at 1600 UTC on the openSUSE-project IRC Channel on freenode to discuss the following topics for the openSUSE Conference. Status T-Shirts Status Scheduling If you are giving a presentation at oSC17, please use the following template: 16x9 https://github.com/openSUSE/artwork/raw/master/Marketing%20Materials/openSU… cya v/r Doug Links for previous meetings Week 1 - https://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proj… Week 2 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 3 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 4 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 5 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje… Week 6 - http://community.opensuse.org/meetings/opensuse-project/2017/opensuse-proje…

1 0