openSUSE Project December 2013

project@lists.opensuse.org

71 participants
43 discussions

[opensuse-project] opensuse-user not on gmane any more?

by Jim Henderson

I just noticed today that the gmane.linux.suse.opensuse.user group is missing from gmane.org - did the project request the list be removed from gmane? Just wondering if it was intentional or if something went wrong somewhere. Thanks, Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

7 years, 5 months

[opensuse-project] SUSE capitalization

by Adam Spiers

Of course we still see people getting this wrong on a regular basis, but googling for "SUSE capitalization" doesn't reveal anything helpful. IMHO we need a wiki page covering the One Absolute Truth, and also a bit of the history behind it. I found this thread from 2005: http://lists.opensuse.org/opensuse/2005-08/msg00377.html but it didn't provide the full story. Additionally, https://en.wikipedia.org/wiki/SUSE https://en.wikipedia.org/wiki/SuSE are (somewhat depressingly) two entirely different articles, neither of which gives any real detail over the renaming from SuSE to SUSE. Shouldn't there be a page https://en.opensuse.org/Capitalization or something? -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

7 years, 11 months

[opensuse-project] Karma for all

by Ancor Gonzalez Sosa

Hi all, During the last days, the openSUSE Team has proposed several changes in the openSUSE processes and tools: http://lists.opensuse.org/opensuse-factory/2013-11/msg00920.html http://lists.opensuse.org/opensuse-factory/2013-12/msg00044.html http://lists.opensuse.org/opensuse-factory/2013-12/msg00132.html The main goal of this mail is to present another idea that was already discussed during the recent openSUSE Summit: the Karmafication of the openSUSE infrastructure. People there liked the idea and some related topics have already been raised in the last days on both Factory and Project mailing lists, so we bring the idea here for wider debate and especially to get input from you all. Where can Karmafication be useful? 1. Decision making. As you all know, most final decisions on the technical side rests in Coolo's shoulders. He plays the role of a benevolent dictator, working based on his perception of skills and dedication. Sure he is fair and experienced but still a single human being. 2. Guidance We lack a clear path from newbie to contributor and then to experienced contributor (like maintainer, reviewer etc). Also, we have a wide variety of guidelines which we'd like people to follow better but which aren't hard rules. 3. Motivation There are areas in openSUSE that do not get the love and attention they deserve in both technical and non-technical terms. People who work on them should be recognized and rewarded. How does Karmafication support the factory proposal goals in the above areas? The idea is to add certain 'social' features to our infrastructure to better track contributions and make them more visible. Contributors would earn AND lose karma points based on their actions (or lack of them), that's why we are calling it 'Karmafication'. We explicitly want to avoid the word 'gamification' because is not only about engaging people or motivating them. The main goal is to help our decision making processes: we're a meritocracy (or a do-ocracy, if you prefer) which is very much trust-based, and that trust is very much based on what you do and what you did in the recent past. Karma should have an impact in: 1. Decision making. Make contributions visible: credit where it is due. Having a profile page for every contributor in OBS would be useful in decision making at all levels. Is this person a good candidate to become technical reviewer? Should I accept this risky SR to factory? In the future, once the system is mature enough, a minimum of karma could even be required to perform some actions. 2. Guidance By defining tasks and rewards we could 'spell out' a path, or several, from beginner to more experienced contributor. Think for example a number of tasks around your first step to contributing; or tasks related to more advanced hackery like fixing certain type of bugs. It could also be used as a way of define best practices for OBS and encourage people to follow them. 3. Motivation Motivate people and visibly reward them for working on things which usually fly below the radar. It would be great to have openSUSE contributors pointing to their OBS profile pages as a reference of their skills and experience, in the same way that most open source developers points to their github page. We could make this recognition more tangible with some special gifts (what about a "I take care of stuff!" t-shirt?). A big benefit of Karmafication over other ways of reaching the same goals is that most alternatives require making rules, commitees and bureaucracy and require much more work. Soft motivation through Karmafication brings us these benefits in a much nicer and more flexible way, hopefully without the downsides of rigorous rules. See this video for some insights in rules vs 'soft nudging': http://vimeo.com/54434167 What do you think about the whole idea? Would you like openSUSE to be the first distribution with a karma-driven development process? -- Ancor González Sosa openSUSE Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] openSUSE board elections 2013 results

by Harisankar P S

The openSUSE board elections 2013 ended last Sunday. We have 4 new members for the board, the first two positions will be serving a 2 year term, the third and fourth a one year term. Election results: We had 177 people voting. Bruno Friedmann, 75 Votes (42%) Andrew Wafaa, 70 Votes (40%) Richard Brown, 68 Votes (38%) Kostas Koudaras, 63 Votes (36%) Sascha Peilicke, 48 Votes (27%) Andres Betts, 37 Votes (21%) Jorg Stephan, 27 Votes (15%) Ish Sookun, 8 Votes (5%) Thanks for all candidates who stepped up and all members who casted their votes! Greetings from the election committee! (election-officials(a)opensuse.org) [1] https://connect.opensuse.org/pg/polls/read/digitaltomm/43818/opensuse-board… -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] Suggestion Concerning Repository Structure and Metadata

by Antoine Saroufim

Good day, Currently, we have a fair amount of software in the default repositories that the user can utilize. If a user wants to install software that isn't present in the default repositories, he/she can look for it on OBS. The user can then proceed to add the targeted repository to his/her system via 1-click install, zypper, or YaST2. The current system works, but isn't quite perfect due to the following reasons: - Users can't install packages not available in the enabled repositories. If a user wants to install an application or library that isn't in the default repositories, the user has to resort to searching for the package on software.opensuse.org through a browser and then installing it or to installing OSC, searching for the package, adding a repository, and then installing the package. - Users may have to add many repositories to get all their needs. Repositories on OBS may host a single desktop environment, a small collection of apps, a single app, or even a patch. Over time, the user might end up with a large number of repositories in order to keep all his/her apps updated. Refreshing repositories might take longer every time due to this and it might cause confusion. The user will have to regularly check the enabled repositories and think of whether they are needed or not. Refreshing a large number of repositories might also take a while. Repositories can get deleted or altered often and the user will have to modify them at each deletion/alteration. It's impossible for a user to pick up the work of another user on certain repositories. Thus the new maintainer will have to make a different repository. - Users might get confused when apps are offered by multiple repositories. Not all repositories are tagged and it might be difficult to tell which repository has the most updated yet stable package. Zypper will warn the user if the added repository and package will rewrite anything that is already existing as it does whenever a vendor change is required. However, users might not heed the warning and they might not be able to tell if something actually works or not before installing it. What we currently have is not a broken structure. On the contrary, our current system works. However, even if it is not broken, and doesn't require fixing, it can be improved. I'll further demonstrate the limitations of the system by providing user cases. - Daniel wants to install package XYZ. However, package XYZ is not in the default repositories. Daniel goes to software.opensuse.org and searches for package XYZ but finds it listed under several repositories. Some have higher version than others. Daniel wants the highest stable version from a trusted repository. Which one of the repositories should Daniel choose? - Michael is a heavy gamer. He wants to play video games on his desktop. He adds games:tools to install Steam. He then proceeds to add Emulators to install ZSNES, and finally adds games to install SuperTux2. However, he notices that another game he wants is further updated on a home repository and has to add that too. Michael ends up with having too many repositories in order to get a few applications. - Christine is a fan of music. She has thoroughly tested most music applications but is dissatisfied with them. She adds KDE:Extra in order to update Clementine to a higher version, then downloads the .rpm of Rhythmbox from Factory so she can install it without adding the repo, and then adds GNOME:Apps to use an updated mplayer. Lastly, she adds Geeko123's repo because he created his own music player and uploaded it to his home project. One day, she wants to install Wayland dev packages. Unknown to her, Geeko123 has added his own unstable Wayland packages. Zypper pulls the Wayland packages from Geeko123's repo and Christine ends up with a broken Wayland because she had assumed that Geeko123's repo was solely for his music player and did not read the warnings. As such, I propose the following improvements: 1 - Create larger repositories and merge similar ones together. Games, game:tools, emulators, Documentation:Tools, KDE:Extra, GNOME:Apps, LibreOffice:Stable, Network, Network:Chromiun, Mozilla, Mozilla:Beta, Mozilla:Alpha, Utilites, Network:Utilities, Utilities, and other similar repositories can be merged together into one repository that offers extra software. We can call it "OSS Extra". The proprietary packages, like Steam, can be added to the Non-OSS repository. This can include different desktop environments as well instead of having to place XFCE, LXDE, MATE, and other desktop environments in their own repositories so long as their packages don't conflict. Naturally, certain projects have conflicting packages. For instance, Ayatana's packages override GNOME. For those projects we can make an alternative repository of their own. We'd cut down a large number of repositories and aggregate them into three separate ones. Multimedia libraries, security packages, server-oriented packages, and debugging and development tools can be added to a repository of their own. GNOME:Next, KDE:Unstable, KF5, and all the similar unstable packages can be kept in an Unstable repo. Factory can be aggregated into a Factory repo. Packages that are being tested can have their own Testing repo. If someone wants to submit a package to these repositories directly, he/she has to have permission to. Users can submit their packages but they won't appear unless the maintainers review them. Instead of having Calibre listed in 10 different repositories and each of them having a version, the packager who wants to update the software can silently submit the package and the maintainer can approve it or disapprove of it. This will save the maintainers some work if they don't have to package everything themselves. This also means that we can have more maintainers. Some people are willing to test but can't package stuff. Submitted packages can be tagged (GNOME, KDE, GTK, etc.) so maintainers can pick a tag to work on that follows their preferences. 2 - Create Community repository that is managed and run by the community. Home projects can remain a playground for packages and app developers. When their apps are ready, they can be moved into the Community repository. Instead of having one repository for Budgie, one for Elegance-colors, and one for Corebird, packages and builders can submit their packages to Community. If someone decides to quit maintaining a package, another maintainer can seamlessly take his/her place without setting up a new repository and forcing the user to update their sources. The community repository will be collaborative at its heart. - Add Reputation system. Installing packages from the Community repo can be a unsafe. However, if the uploader has been praised before, then the user might feel more trusting. That way, the user will have a better idea what is all right to install and what isn't. This will also give motivation to people. - Let the community maintain its own repository. By giving this repository a rating system, we can let the community maintain this repository on its own. Alternative Suggestions: 1 - Make zypper utilize smarter metadata. Zypper can be updated to read all the metadata from all the repositories and could suggest adding a repository if the desired package isn't in the currently enabled repository. People should be able to use zypper to find packages instead of having to resort to a browser to search through OBS. This way, users can use gnome-software to access all the software on OBS (in the future when a zypper plugin is written for gnome-software). 2 - Visibly tag repositories to show their stability. In order to help users choose the most stable repository, visible tags should be provided to indicate the stability before the user adds the repository. 3 - Make repositories collaborative. By allowing collaborative work we may end up seeing less repositories in general. If person X creates repo for package Y, person X is asked if repo is to be open for collaboration to everyone. If person X decides to quit, another maintainer can pick up the work on the same repository. 4 - Allow user to hide all "home" repositories. I firmly believe that we should make everything simpler. It isn't a matter of what can or can't be done, it's more about how easy it is to get things done. By clearing confusion and allowing collaborative work, we can help the users save precious time, give them an easier system, and help them make better decisions. With front-end GUIs for package managers, like Apper and gnome-software, on the rise, the traditional method of installing software is changing. The shortest distance between two points is a straight line. Thus, we should reduce the steps and complications of installing and managing software in order to appeal to more users and to further satisfy the ones we have. Improvement is what keeps projects interesting. I for one do not want a system that works. I want a system that works better than it did before. I hope you all consider my suggestions before judging them and think of the average users, not just of the advanced ones. Thank you for your time and I hope we can keep this thread civil. Sincerely, Antoine Saroufim (Vagrant232)" -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] FOSDEM 2014

by Agustin Benito Bethencourt

Hi, deadline for lightning talks and stands at FOSDEM is 20th November: https://fosdem.org/2014/news/2013-09-17-call-for-participation-part-two/ Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe(a)suse.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] timeline and roadmap

by Jos Poortvliet

Dear community, The openSUSE team has presented and with you discussed some plans for a more sustainable development project➀. Proposals like working openQA in the openSUSE development workflow, implementing staging projects, making improvements to OBS - and implementing these things will cost a lot of time. Right now, the openSUSE team is or plans to be working on a wide range of things: the openSUSE Conference, the new merchandising program and of course we have the openSUSE release process on our plate. Especially the work on the release takes much time from our team, both in terms of ongoing effort (keep factory working, openQA testing) and of course around the release itself. To implement the proposals we made in a reasonable time frame, we think it makes most sense for us to focus on them. That means, the openSUSE team would work on OBS, openQA etc in a series of sprints over a period of 6-8 months. In that time, we spend little if any time on the release process. Of course, after these changes the team will be back on the job at full speed. What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible. Shoot. What do you think? - The openSUSE Team ➀ http://lists.opensuse.org/opensuse-factory/2013-12/msg00349.html and https://lizards.opensuse.org/2013/12/11/discussing-about-the-future-of-open…

8 years, 4 months

[opensuse-project] Junior Jobs

by Manu Gupta

Dear All Merry Xmas :) I stumbled across the https://en.opensuse.org/openSUSE:Junior_jobs page and found that it has excellent content, however a lot of data maybe obsolote now and may have to be revised. I plan to remove some projects name I know which are not active, the second thing I propose is have a link of the page as a footer of all our mailing lists, any ideas on it? -- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] Anyone have a contact for SUSE Studio?

by Jim Henderson

Studio is apparently currently not able to process builds - hasn't been able to for a few days from reports that I've read. Just wondering if there's an escalation procedure to get something like this looked at. Thanks! Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

[opensuse-project] [reminder] openSUSE Project Meeting tomorrow at 15:00 UTC

by openSUSE Meeting Reminder

Hello all, The biweekly project meeting will be held tomorrow at 15:00 UTC in #opensuse-project on freenode. Everybody is invited to join and participate! Find out what time the meeting will be in your timezone: http://timeanddate.com/worldclock/fixedtime.html?day=25&month=12&year=2013&… Agenda of the meeting: http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting If you cannot participate and want a specific question to be answered during the meeting, please add your question to: http://en.opensuse.org/openSUSE:Project_meeting#Questions_Section Minutes and logs of previous meetings can be found at: http://community.opensuse.org/meetings/opensuse-project/ Thanks, -- openSUSE Meeting Reminder -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Project December 2013