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
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/SUSEhttps://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
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.htmlhttp://lists.opensuse.org/opensuse-factory/2013-12/msg00044.htmlhttp://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
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
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
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
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…
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
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