20 Dec
2013
20 Dec
'13
2:43 a.m.
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
20 Dec
20 Dec
10 a.m.
Antoine Saroufim - 1:43 20.12.13 wrote:
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.
There used to be a YaST module to search and add stuff from OBS, but I guess it
was dropped at some point in time.
- 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.
Not really. In general if you have it in somewhere - not in home, anybody can
continue, send patches via OBS and there is project maintainer to act in case
package maintainer disappeared.
- 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?
Not home and then it should be repository the package belongs to. Packages have
one repository they belong to, but might be linked to another one as
dependency.
- 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.
He shouldn't add home repository, he should ask that guy to push his stuff to
the main repository. Maybe we should hide home repositories even deeper in
software search to make people push their changes?
- 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.
Yes, we should go further with discouraging the use of home projects somehow. I
wonder whether this karmification idea can help us. Make it more visible who
contributes to the common pool of packages and doesn't just play with things in
his home.
As such, I propose the following improvements:
1 - Create larger repositories and merge similar ones together.
...
Partially done with Tumbleweed for stuff in the distribution. But I agree that
having one big repo for the rest that will not be frozen and more relaxed than
release is a good idea. Maybe revive Contrib with different purpose? If we get
a stable enough factory, we may even put it there. I think we would get more
contributors for this kind of repo than for a release as maintaining software
for years scares people (at least me).
2 - Create Community repository that is managed and
run by the
community.
All of them are ;-)
- 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.
Yep, see karmification idea[1].
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).
I would say that it would be better if somebody stepped up and wrote again YaST
module for software.opensuse.org. YaST is nowadays in Ruby, so it shouldn't be
that hard for somebody interested and skilled in Ruby :-)
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.
Hard to judge the stability of repo, but what can be done with karmification is
show number of users which should be also helpful.
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.
Done already ;-)
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.
More like hide homes by default and add them once people ask for them. Like it
is by default in OBS. Something similar can be done in software search.
[1] http://lists.opensuse.org/opensuse-project/2013-12/msg00147.html
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:01 p.m.
On Fri, 2013-12-20 at 10:00 +0100, Michal Hrusecky wrote:
Antoine Saroufim - 1:43 20.12.13 wrote:
A Karma system and an OBS plugin for YaST would definitely help. However, we should also
consider doing something for gnome-software and apper. If we can make zypper collect
metadata from all repositories and intelligently analyze them, we can also benefit those
who use the previously mentioned applications as well. I realize that the community can
use as many home repositories as it wants to but I believe that this is core of the
problem in itself. We should point community packagers to a certain repo so the users can
use that repo instead of having to add several home projects. A Contrib repo would
definitely have lower grade packages. However, I believe that it can clear a lot of
confusion and would reduce the number of repositories a user might ultimately add. Like I
said, currently, the system works, but we can make it simpler and more stupid. The
benefits of a Contrib repo can outweigh the demerits.
--
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.
There used to be a YaST module to search and add stuff from OBS, but I guess it
was dropped at some point in time.
- 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.
Not really. In general if you have it in somewhere - not in home, anybody can
continue, send patches via OBS and there is project maintainer to act in case
package maintainer disappeared.
- 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?
Not home and then it should be repository the package belongs to. Packages have
one repository they belong to, but might be linked to another one as
dependency.
- 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.
He shouldn't add home repository, he should ask that guy to push his stuff to
the main repository. Maybe we should hide home repositories even deeper in
software search to make people push their changes?
- 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.
Yes, we should go further with discouraging the use of home projects somehow. I
wonder whether this karmification idea can help us. Make it more visible who
contributes to the common pool of packages and doesn't just play with things in
his home.
As such, I propose the following improvements:
1 - Create larger repositories and merge similar ones together.
...
Partially done with Tumbleweed for stuff in the distribution. But I agree that
having one big repo for the rest that will not be frozen and more relaxed than
release is a good idea. Maybe revive Contrib with different purpose? If we get
a stable enough factory, we may even put it there. I think we would get more
contributors for this kind of repo than for a release as maintaining software
for years scares people (at least me).
2 - Create Community repository that is managed
and run by the
community.
All of them are ;-)
- 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.
Yep, see karmification idea[1].
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).
I would say that it would be better if somebody stepped up and wrote again YaST
module for software.opensuse.org. YaST is nowadays in Ruby, so it shouldn't be
that hard for somebody interested and skilled in Ruby :-)
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.
Hard to judge the stability of repo, but what can be done with karmification is
show number of users which should be also helpful.
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.
Done already ;-)
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.
More like hide homes by default and add them once people ask for them. Like it
is by default in OBS. Something similar can be done in software search.
[1] http://lists.opensuse.org/opensuse-project/2013-12/msg00147.html
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz 
3:09 p.m.
On Fri, 2013-12-20 at 15:01 +0000, Antoine Saroufim wrote:
On Fri, 2013-12-20 at 10:00 +0100, Michal Hrusecky
wrote:
I believe this is why things like AppStream exist, and the application
metadata. However, this problem extends beyond a UI-specific
implementation. Whilst I agree plugins need to be developed for
gnome-software, it may make sense at first to implement this as a YaST
plugin, to test the concept.
Collection could be done via OBS itself. I also agree with making home
repositories far less important, I'd also suggest completely hiding them
by default, and add an option to enable viewing them. When a user is
searching for a package on software.opensuse.org, I'm pretty sure they
would prefer an "official" package as opposed to a 3rd party home repo.
What might be more appropriate, is adding a notification to repo owners
that either their package doesn't exist in the main repo, or their
version is newer, and they should consider sending a request to have it
merged.
This is merely a thought, but if the system itself encourages home
project owners to submit, and automatically tell them their published
version is higher than the base repository, or not available, we might
see more contributions going back to the main repository.
With regards to a plugin, I'm no ruby expert, but I don't mind
prototyping something for someone else to extend on.
Kind Regards,
Michael Ikey Doherty
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�����r��y隊Z)z{.��k�7��맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��k�7���0�����Ǩ�
Antoine Saroufim - 1:43 20.12.13 wrote:
A Karma system and an OBS plugin for YaST would definitely help. However, we should also
consider doing something for gnome-software and apper. If we can make zypper collect
metadata from all repositories and intelligently analyze them, we can also benefit those
who use the previously mentioned applications as well. I realize that the community can
use as many home repositories as it wants to but I believe that this is core of the
problem in itself. We should point community packagers to a certain repo so the users can
use that repo instead of having to add several home projects. A Contrib repo would
definitely have lower grade packages. However, I believe that it can clear a lot of
confusion and would reduce the number of repositories a user might ultimately add. Like I
said, currently, the system works, but we can make it simpler and more stupid. The
benefits of a Contrib repo can outweigh the demerits.
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.
There used to be a YaST module to search and add stuff from OBS, but I guess it
was dropped at some point in time.
- 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.
Not really. In general if you have it in somewhere - not in home, anybody can
continue, send patches via OBS and there is project maintainer to act in case
package maintainer disappeared.
- 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?
Not home and then it should be repository the package belongs to. Packages have
one repository they belong to, but might be linked to another one as
dependency.
- 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.
He shouldn't add home repository, he should ask that guy to push his stuff to
the main repository. Maybe we should hide home repositories even deeper in
software search to make people push their changes?
- 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.
Yes, we should go further with discouraging the use of home projects somehow. I
wonder whether this karmification idea can help us. Make it more visible who
contributes to the common pool of packages and doesn't just play with things in
his home.
As such, I propose the following improvements:
1 - Create larger repositories and merge similar ones together.
...
Partially done with Tumbleweed for stuff in the distribution. But I agree that
having one big repo for the rest that will not be frozen and more relaxed than
release is a good idea. Maybe revive Contrib with different purpose? If we get
a stable enough factory, we may even put it there. I think we would get more
contributors for this kind of repo than for a release as maintaining software
for years scares people (at least me).
2 - Create Community repository that is managed
and run by the
community.
All of them are ;-)
- 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.
Yep, see karmification idea[1].
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).
I would say that it would be better if somebody stepped up and wrote again YaST
module for software.opensuse.org. YaST is nowadays in Ruby, so it shouldn't be
that hard for somebody interested and skilled in Ruby :-)
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.
Hard to judge the stability of repo, but what can be done with karmification is
show number of users which should be also helpful.
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.
Done already ;-)
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.
More like hide homes by default and add them once people ask for them. Like it
is by default in OBS. Something similar can be done in software search.
[1] http://lists.opensuse.org/opensuse-project/2013-12/msg00147.html
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz 
5:33 p.m.
On Friday 20 December 2013 14.09:55 Michael Ikey Doherty wrote:
hat might be more appropriate, is adding a
notification to repo owners
that either their package doesn't exist in the main repo, or their
version is newer, and they should consider sending a request to have it
merged.
This is merely a thought, but if the system itself encourages home
project owners to submit, and automatically tell them their published
version is higher than the base repository, or not available, we might
see more contributions going back to the main repository.
Hey that's a good one, I like it :-)
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
5:59 p.m.
On Fri, 2013-12-20 at 17:33 +0100, Bruno Friedmann wrote:
On Friday 20 December 2013 14.09:55 Michael Ikey
Doherty wrote:
Thanks :)
hat might be more appropriate, is adding a
notification to repo owners
that either their package doesn't exist in the main repo, or their
version is newer, and they should consider sending a request to have it
merged.
This is merely a thought, but if the system itself encourages home
project owners to submit, and automatically tell them their published
version is higher than the base repository, or not available, we might
see more contributions going back to the main repository.
Hey that's a good one, I like it :-)
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
6:35 p.m.
Bruno Friedmann - 17:33 20.12.13 wrote:
On Friday 20 December 2013 14.09:55 Michael Ikey
Doherty wrote:
+1 although it might not be as simple as it seems as on one hand it would need
to know flow of packages - ignore released openSUSE and on other hand find the
best place for all the stuff. But if we get one big "Contrib" repo, it make
things a little bit easier...
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
hat might be more appropriate, is adding a
notification to repo owners
that either their package doesn't exist in the main repo, or their
version is newer, and they should consider sending a request to have it
merged.
This is merely a thought, but if the system itself encourages home
project owners to submit, and automatically tell them their published
version is higher than the base repository, or not available, we might
see more contributions going back to the main repository.
Hey that's a good one, I like it :-)
6:39 p.m.
On Fri, 2013-12-20 at 18:35 +0100, Michal Hrusecky wrote:
Bruno Friedmann - 17:33 20.12.13 wrote:
Well we can look at a home project repo targets. If
it targets openSUSE
13.1 on a build, has at least one valid build, we can look at the name
provided in the .spec (faster to look at the name of the .spec file
itself to be fair) and then cross-reference with the existing openSUSE
13.1 repo. So we already know where to look :)
On Friday 20 December 2013 14.09:55 Michael Ikey
Doherty wrote:
+1 although it might not be as simple as it seems as on one hand it would need
to know flow of packages - ignore released openSUSE and on other hand find the
best place for all the stuff. But if we get one big "Contrib" repo, it make
things a little bit easier... hat might be more appropriate, is adding a
notification to repo owners
that either their package doesn't exist in the main repo, or their
version is newer, and they should consider sending a request to have it
merged.
This is merely a thought, but if the system itself encourages home
project owners to submit, and automatically tell them their published
version is higher than the base repository, or not available, we might
see more contributions going back to the main repository.
Hey that's a good one, I like it :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
3:10 p.m.
Even if I'm not sure this discussion should happen right now, before we have a clear
vision about how factory & development process
will occur....
On Friday 20 December 2013 15.01:11 Antoine Saroufim wrote:
We should point community packagers to a certain repo
so the users can use that repo instead of having to add several home projects.
Well if packager keep their packages in their home repository, without one day thinks
about pushing them to the corresponding repository
that normal end-user could use. I don't see how it could become better.
Karmaid it or not I'm still totally blinded by how this could help.
The main concern & clean-up we can do (but then again who is the we?) could be the
following:
Decide and have clear statement about the status about some important repositories in the
end-user point of view
Edu, Games, Each desktop, Devel:Languages, etc and some server stuff to be safe repository
to add.
On those repository, once we got several maintainers on them, we could have a politics of
getting stable stuff in.
They serve as development home for factory submission.
When packager has stuff to develop (new version etc) this could happen in their home, and
or specialized "devel" repository
Now you will never never strict adherence from end-users. You can't imagine how
creative they can be in f**cking their system.
How few reflexion they do, when installing software.
Do we want to have a dummy place à la Google Play store?
Come on, it's a pity to find something there. Did you really think that a five start
(highest rated by end-user) text editor which want full access on your whole system
function and data is really trust-able ?
Then just revive the Contrib repository. Those of us who was using it years ago, know how
good it has disappear.
Did a number of end-users need an easier way to get latest great stuff available?
Then tumbleweed could (should) be the target.
Helping tumbleweed to pick the most requested / needed software integrated in it, and you
win!
No hard work to reorganize (now) the repository, cause who will do that work?
and you safely offer all what end-users are looking for.
What is missing the most is educational material for end users.
This is only valid until we got a ring distribution :-)
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:28 p.m.
Le 20/12/2013 15:10, Bruno Friedmann a écrit :
What is missing the most is educational material for
end users.
well... there I could help more.
what we lack is a way to ask for help. some visible place where people
that want to help can find up to date data, and may be somebody
(team?) that could ask directly for help when necessary...
some way to see what is important and what is not so important. Jos
did so with pretty good results for marketting when a new distro come :-)
jdd
--
http://www.dodin.org
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
6:31 p.m.
jdd - 16:28 20.12.13 wrote:
Le 20/12/2013 15:10, Bruno Friedmann a écrit :
http://en.opensuse.org/Communication :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
What is missing the most is educational material
for end users.
well... there I could help more.
what we lack is a way to ask for help. some visible place where
people that want to help can find up to date data, and may be
somebody (team?) that could ask directly for help when necessary...
3:35 p.m.
Antoine Saroufim - 15:01 20.12.13 wrote:
...
A Karma system and an OBS plugin for YaST would definitely help. However, we
should also consider doing something for gnome-software and apper. If we can
make zypper collect metadata from all repositories and intelligently analyze
them, we can also benefit those who use the previously mentioned
applications as well.
Definitely against zypper being "clever enough" to add some random
repositories. But I might be worth extending cnf to search
software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
5:48 p.m.
On Fri, 2013-12-20 at 15:35 +0100, Michal Hrusecky wrote:
Antoine Saroufim - 15:01 20.12.13 wrote:
I'm glad that I didn't actually ask you to write either of them :)
You're free to write whatever you want and not to write whatever you
want. Since this is a discussion about what we (as a project) could
possibly do about what we already have, let's stick to giving sound
arguments and counterarguments. If you're against zypper being "clever
enough" to suggest adding repositories, then you must certainly have a
reason to be against it. Could you please enlighten us about the
possible flaws of that?
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
...
A Karma system and an OBS plugin for YaST would definitely help. However, we
should also consider doing something for gnome-software and apper. If we can
make zypper collect metadata from all repositories and intelligently analyze
them, we can also benefit those who use the previously mentioned
applications as well.
Definitely against zypper being "clever enough" to add some random
repositories. But I might be worth extending cnf to search
software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
6:29 p.m.
Antoine Saroufim - 16:48 20.12.13 wrote:
On Fri, 2013-12-20 at 15:35 +0100, Michal Hrusecky
wrote:
Few points:
* cnf was made to help people find the package they want
* zypper is not used only in openSUSE
* zypper is cmd line tool for managing sw
** it's target audience are skilled sysadmins
** making suggestions will
*** take more time to search
*** make results a little confusing
*** if you make it user friendly, people can accidentally add repositories
Bottom line - zyppers target audience can search for sw using osc and add
repositories. Target audience you have in mind uses YaST.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Antoine Saroufim - 15:01 20.12.13 wrote:
I'm glad that I didn't actually ask you to write either of them :)
You're free to write whatever you want and not to write whatever you
want. Since this is a discussion about what we (as a project) could
possibly do about what we already have, let's stick to giving sound
arguments and counterarguments. If you're against zypper being "clever
enough" to suggest adding repositories, then you must certainly have a
reason to be against it. Could you please enlighten us about the
possible flaws of that?
...
A Karma system and an OBS plugin for YaST would definitely help. However, we
should also consider doing something for gnome-software and apper. If we can
make zypper collect metadata from all repositories and intelligently analyze
them, we can also benefit those who use the previously mentioned
applications as well.
Definitely against zypper being "clever enough" to add some random
repositories. But I might be worth extending cnf to search
software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
8:50 p.m.
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky wrote:
Antoine Saroufim - 16:48 20.12.13 wrote:
Fair enough. So far, we can all agree that:
1 - A reputation (Karma) system would help
2 - Hiding the home repositories by default has its merits
3 - Users should be encouraged to submit packages to the main
repositories
Anyone has any suggestions on how to encourage users to submit packages
to the main repositories? Also, is the idea of reviving Contrib out of
the question?
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
On Fri, 2013-12-20 at 15:35 +0100, Michal
Hrusecky wrote:
Few points:
* cnf was made to help people find the package they want
* zypper is not used only in openSUSE
* zypper is cmd line tool for managing sw
** it's target audience are skilled sysadmins
** making suggestions will
*** take more time to search
*** make results a little confusing
*** if you make it user friendly, people can accidentally add repositories
Bottom line - zyppers target audience can search for sw using osc and add
repositories. Target audience you have in mind uses YaST.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz Antoine Saroufim - 15:01 20.12.13 wrote:
I'm glad that I didn't actually ask you to write either of them :)
You're free to write whatever you want and not to write whatever you
want. Since this is a discussion about what we (as a project) could
possibly do about what we already have, let's stick to giving sound
arguments and counterarguments. If you're against zypper being "clever
enough" to suggest adding repositories, then you must certainly have a
reason to be against it. Could you please enlighten us about the
possible flaws of that?
...
A Karma system and an OBS plugin for YaST would definitely help. However, we
should also consider doing something for gnome-software and apper. If we can
make zypper collect metadata from all repositories and intelligently analyze
them, we can also benefit those who use the previously mentioned
applications as well.
Definitely against zypper being "clever enough" to add some random
repositories. But I might be worth extending cnf to search
software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
6:54 p.m.
On Fri, 2013-12-20 at 19:50 +0000, Antoine Saroufim wrote:
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky
wrote:
If for example I have weston in my repo, and its newer than
openSUSE:13.1 which is my target, the system could offer it if my
rpmlint is good and my karma is also good. Otherwise, tips should be
displayed, "Once you've fixed rpmlint issues, you shoulder consider
merging this into the main repository [Why link]"
If I have a higher karma, and a package thats not in my target, it
should offer it as well, and explanations on karma should be clearly
visible, with tips on improving it.
So if my package is a duplicate, it could hint that by branching the
factory package, (via metadata knowledge) I could improve my karma,
instead of having my little world over in home:bobhasnofriends.
Karma should be linked both to branch contributions, merged requests of
new packages (lets try to link home:'s and branching, its too separate
right now) and the system should be helpful in encouraging a
contribution back to main. Essentially, OBS should be viewed in a new
light: Work on your packages until they're good enough for submission to
the main repository.
My 2 cents.
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Antoine Saroufim - 16:48 20.12.13 wrote:
Fair enough. So far, we can all agree that:
1 - A reputation (Karma) system would help
2 - Hiding the home repositories by default has its merits
3 - Users should be encouraged to submit packages to the main
repositories
Anyone has any suggestions on how to encourage users to submit packages
to the main repositories? Also, is the idea of reviving Contrib out of
the question?
On Fri, 2013-12-20 at 15:35 +0100, Michal
Hrusecky wrote:
Few points:
* cnf was made to help people find the package they want
* zypper is not used only in openSUSE
* zypper is cmd line tool for managing sw
** it's target audience are skilled sysadmins
** making suggestions will
*** take more time to search
*** make results a little confusing
*** if you make it user friendly, people can accidentally add repositories
Bottom line - zyppers target audience can search for sw using osc and add
repositories. Target audience you have in mind uses YaST.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz Antoine Saroufim - 15:01 20.12.13 wrote:
> ...
>
> A Karma system and an OBS plugin for YaST would definitely help. However, we
> should also consider doing something for gnome-software and apper. If we can
> make zypper collect metadata from all repositories and intelligently analyze
> them, we can also benefit those who use the previously mentioned
> applications as well.
Definitely against zypper being "clever enough" to add some random
repositories. But I might be worth extending cnf to search
software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
I'm glad that I didn't actually ask you to write either of them :)
You're free to write whatever you want and not to write whatever you
want. Since this is a discussion about what we (as a project) could
possibly do about what we already have, let's stick to giving sound
arguments and counterarguments. If you're against zypper being "clever
enough" to suggest adding repositories, then you must certainly have a
reason to be against it. Could you please enlighten us about the
possible flaws of that?
7:21 p.m.
Michael Ikey Doherty - 17:54 20.12.13 wrote:
If for example I have weston in my repo, and its newer
than
openSUSE:13.1 which is my target, the system could offer it if my
rpmlint is good and my karma is also good. Otherwise, tips should be
displayed, "Once you've fixed rpmlint issues, you shoulder consider
merging this into the main repository [Why link]"
You meant Factory, right? :-) 13.1 is frozen, no new packages. With Factory, it
has to go through devel project, but that is automatically discoverable as
well... So I would change what you are checking against slightly ;-)
If I have a higher karma, and a package thats not in
my target, it
should offer it as well, and explanations on karma should be clearly
visible, with tips on improving it.
I karma thread some people complained that they don't want to have a karma and
it were not people that would have bad karma...
So if my package is a duplicate, it could hint that by
branching the
factory package, (via metadata knowledge) I could improve my karma,
instead of having my little world over in home:bobhasnofriends.
Well, branching is the same as having private world, what is different is
sending stuff back :-)
Karma should be linked both to branch contributions,
merged requests of
new packages (lets try to link home:'s and branching, its too separate
right now) and
You lost me here :-)
the system should be helpful in encouraging a
contribution back to main.
Essentially, OBS should be viewed in a new light: Work on your packages until
they're good enough for submission to the main repository.
Yep, agree!
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
7:23 p.m.
On Fri, 2013-12-20 at 19:21 +0100, Michal Hrusecky wrote:
Indeed, need to encourage send-back..
Ok, so if I have 10 contributions accepted (branched) I have
100 points,
etc. Karma directly related to repo actions. Also, I'm Irish. It's
partly my business to lose people :) (Not intentional. Just happens)
Awesome :)
Michael Ikey Doherty - 17:54 20.12.13 wrote:
Ehm, that as
well! Terrible example but yes, factory :)
If for example I have weston in my repo, and its
newer than
openSUSE:13.1 which is my target, the system could offer it if my
rpmlint is good and my karma is also good. Otherwise, tips should be
displayed, "Once you've fixed rpmlint issues, you shoulder consider
merging this into the main repository [Why link]"
You meant Factory, right? :-) 13.1 is frozen, no new packages. With Factory, it
has to go through devel project, but that is automatically discoverable as
well... So I would change what you are checking against slightly ;-) If I have a higher karma, and a package thats not
in my target, it
should offer it as well, and explanations on karma should be clearly
visible, with tips on improving it.
I karma thread some people complained that they don't want to have a karma and
it were not people that would have bad karma...
So if my package is a duplicate, it could hint
that by branching the
factory package, (via metadata knowledge) I could improve my karma,
instead of having my little world over in home:bobhasnofriends.
Well, branching is the same as having private world, what is different is
sending stuff back :-) Karma should be linked both to branch
contributions, merged requests of
new packages (lets try to link home:'s and branching, its too separate
right now) and
You lost me here :-) the system should be helpful in encouraging a
contribution back to main.
Essentially, OBS should be viewed in a new light: Work on your packages until
they're good enough for submission to the main repository.
Yep, agree!
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
9:04 p.m.
On Fri, 2013-12-20 at 17:54 +0000, Michael Ikey Doherty wrote:
On Fri, 2013-12-20 at 19:50 +0000, Antoine Saroufim
wrote:
I think that's decent enough. If the focus
can remain on the default
repositories then there won't be a need to add other ones. I like your
idea and I think it's cost-effective.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
On Fri, 2013-12-20 at 18:29 +0100, Michal
Hrusecky wrote:
If for example I have weston in my repo, and its newer than
openSUSE:13.1 which is my target, the system could offer it if my
rpmlint is good and my karma is also good. Otherwise, tips should be
displayed, "Once you've fixed rpmlint issues, you shoulder consider
merging this into the main repository [Why link]"
If I have a higher karma, and a package thats not in my target, it
should offer it as well, and explanations on karma should be clearly
visible, with tips on improving it.
So if my package is a duplicate, it could hint that by branching the
factory package, (via metadata knowledge) I could improve my karma,
instead of having my little world over in home:bobhasnofriends.
Karma should be linked both to branch contributions, merged requests of
new packages (lets try to link home:'s and branching, its too separate
right now) and the system should be helpful in encouraging a
contribution back to main. Essentially, OBS should be viewed in a new
light: Work on your packages until they're good enough for submission to
the main repository.
My 2 cents.
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Nry隊Z)z{.k7맲rz^ˬzN(֜^ ޭ隊Z)z{.k70Ǩ Antoine Saroufim - 16:48 20.12.13 wrote:
Fair enough. So far, we can all agree that:
1 - A reputation (Karma) system would help
2 - Hiding the home repositories by default has its merits
3 - Users should be encouraged to submit packages to the main
repositories
Anyone has any suggestions on how to encourage users to submit packages
to the main repositories? Also, is the idea of reviving Contrib out of
the question?
On Fri, 2013-12-20 at 15:35 +0100, Michal
Hrusecky wrote:
> Antoine Saroufim - 15:01 20.12.13 wrote:
> > ...
> >
> > A Karma system and an OBS plugin for YaST would definitely help. However, we
> > should also consider doing something for gnome-software and apper. If we can
> > make zypper collect metadata from all repositories and intelligently analyze
> > them, we can also benefit those who use the previously mentioned
> > applications as well.
>
> Definitely against zypper being "clever enough" to add some random
> repositories. But I might be worth extending cnf to search
> software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
>
> --
> Michal HRUSECKY SUSE LINUX, s.r.o.
> openSUSE Team Lihovarska 1060/12
> PGP 0xFED656F6 19000 Praha 9
> mhrusecky[at]suse.cz Czech Republic
> http://michal.hrusecky.net http://www.suse.cz
I'm glad that I didn't actually ask you to write either of them :)
You're free to write whatever you want and not to write whatever you
want. Since this is a discussion about what we (as a project) could
possibly do about what we already have, let's stick to giving sound
arguments and counterarguments. If you're against zypper being "clever
enough" to suggest adding repositories, then you must certainly have a
reason to be against it. Could you please enlighten us about the
possible flaws of that?
Few points:
* cnf was made to help people find the package they want
* zypper is not used only in openSUSE
* zypper is cmd line tool for managing sw
** it's target audience are skilled sysadmins
** making suggestions will
*** take more time to search
*** make results a little confusing
*** if you make it user friendly, people can accidentally add repositories
Bottom line - zyppers target audience can search for sw using osc and add
repositories. Target audience you have in mind uses YaST.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
7:09 p.m.
On Fri, 2013-12-20 at 20:04 +0000, Antoine Saroufim wrote:
On Fri, 2013-12-20 at 17:54 +0000, Michael Ikey
Doherty wrote:
Thank you :) Lets see what other people think though, I could be off :)
(Also, apologies for the weird squiggle signature on the end of my
mails, not sure what's happening there, not seeing it in gmail though)
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Fri, 2013-12-20 at 19:50 +0000, Antoine
Saroufim wrote:
I think that's decent enough. If the focus
can remain on the default
repositories then there won't be a need to add other ones. I like your
idea and I think it's cost-effective.
On Fri, 2013-12-20 at 18:29 +0100, Michal
Hrusecky wrote:
If for example I have weston in my repo, and its newer than
openSUSE:13.1 which is my target, the system could offer it if my
rpmlint is good and my karma is also good. Otherwise, tips should be
displayed, "Once you've fixed rpmlint issues, you shoulder consider
merging this into the main repository [Why link]"
If I have a higher karma, and a package thats not in my target, it
should offer it as well, and explanations on karma should be clearly
visible, with tips on improving it.
So if my package is a duplicate, it could hint that by branching the
factory package, (via metadata knowledge) I could improve my karma,
instead of having my little world over in home:bobhasnofriends.
Karma should be linked both to branch contributions, merged requests of
new packages (lets try to link home:'s and branching, its too separate
right now) and the system should be helpful in encouraging a
contribution back to main. Essentially, OBS should be viewed in a new
light: Work on your packages until they're good enough for submission to
the main repository.
My 2 cents.
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Nry隊Z)z{.k7맲rz^ˬzN(֜^ ޭ隊Z)z{.k70Ǩ Antoine Saroufim - 16:48 20.12.13 wrote:
> On Fri, 2013-12-20 at 15:35 +0100, Michal Hrusecky wrote:
> > Antoine Saroufim - 15:01 20.12.13 wrote:
> > > ...
> > >
> > > A Karma system and an OBS plugin for YaST would definitely help. However,
we
> > > should also consider doing something for gnome-software and apper. If we
can
> > > make zypper collect metadata from all repositories and intelligently
analyze
> > > them, we can also benefit those who use the previously mentioned
> > > applications as well.
> >
> > Definitely against zypper being "clever enough" to add some random
> > repositories. But I might be worth extending cnf to search
> > software.opensuse.org. But I'm not doing neither that nor YaST plugin :-)
> >
> > --
> > Michal HRUSECKY SUSE LINUX, s.r.o.
> > openSUSE Team Lihovarska 1060/12
> > PGP 0xFED656F6 19000 Praha 9
> > mhrusecky[at]suse.cz Czech Republic
> > http://michal.hrusecky.net http://www.suse.cz
>
> I'm glad that I didn't actually ask you to write either of them :)
> You're free to write whatever you want and not to write whatever you
> want. Since this is a discussion about what we (as a project) could
> possibly do about what we already have, let's stick to giving sound
> arguments and counterarguments. If you're against zypper being "clever
> enough" to suggest adding repositories, then you must certainly have a
> reason to be against it. Could you please enlighten us about the
> possible flaws of that?
>
Few points:
* cnf was made to help people find the package they want
* zypper is not used only in openSUSE
* zypper is cmd line tool for managing sw
** it's target audience are skilled sysadmins
** making suggestions will
*** take more time to search
*** make results a little confusing
*** if you make it user friendly, people can accidentally add repositories
Bottom line - zyppers target audience can search for sw using osc and add
repositories. Target audience you have in mind uses YaST.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
Fair enough. So far, we can all agree that:
1 - A reputation (Karma) system would help
2 - Hiding the home repositories by default has its merits
3 - Users should be encouraged to submit packages to the main
repositories
Anyone has any suggestions on how to encourage users to submit packages
to the main repositories? Also, is the idea of reviving Contrib out of
the question?
7:24 p.m.
Antoine Saroufim <antoine.saroufim(a)gmail.com> wrote:
<snip>
Also, is the idea of reviving Contrib out of
the question?
What is the value of the new contrib?
A place to submit packages you don't want to maintain?
Is the supposed idea is that packages could be pushed there until they get polished up
for factory and a maintainer found?
Then they get moved to a real development repo before submission to factory.
Thus it has a quality standard above home, but below devel or factory.
In that role I like it. I have packages that I have worked on but which aren't ready
to be submitted to a development project. Pushing them to contrib would let other
packagers know I think my work is worth leveraging.
Some tougher packages like suricata I've spent hours on. It still needs more work to
build cleanly, but the work I've done should be leveraged by the next person who wants
to work on it.
Greg
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
8:10 p.m.
Greg Freemyer - 13:24 20.12.13 wrote:
Antoine Saroufim <antoine.saroufim(a)gmail.com> wrote:
<snip>
Also, is the idea of reviving Contrib out of
No packages that you don't want to maintain per se, but packages that you don't
want to get frozen. It's big difference in effort and commitment as stuff can
be submitted anytime, bugs can be fixed by updating to latest version and once
nobody cares anymore, it can be dropped anytime.
the question?
What is the value of the new contrib?
A place to submit packages you don't want to maintain? Is the supposed idea is that packages could be pushed
there until they get
polished up for factory and a maintainer found?
That could be also the case.
Then they get moved to a real development repo before
submission to factory.
Thus it has a quality standard above home, but below devel or factory.
I would still keep quality maybe somewhere around devel repo...
In that role I like it. I have packages that I have
worked on but which
aren't ready to be submitted to a development project. Pushing them to
contrib would let other packagers know I think my work is worth leveraging.
Some tougher packages like suricata I've spent hours on. It still needs more
work to build cleanly, but the work I've done should be leveraged by the next
person who wants to work on it.
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
11:01 a.m.
* Antoine Saroufim <antoine.saroufim(a)gmail.com> [2013-12-20 00:43]:
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.
...
- Users may have to add many repositories to get all their needs.
...
- Users might get confused when apps are offered by multiple
repositories.
The real problem which you don't mention here is that most
(although there are some exceptions) OBS projects are a mixed
bag, there are packages that are in Factory, there are good
quality packages, there are packages with awful quality and there
are unmaintained packages.
Users (unless they are also package maintainers) are usually not
able to judge the quality of the package and packaged software,
if a package is popular it does not necessarily say much about
its quality, e.g. see the discussion about acroread removal from
Factory.
As such, I propose the following improvements:
1 - Create larger repositories and merge similar ones together.
...
2 - Create Community repository that is managed and run by the
community.
We already had that, it was called Contrib and originally created
when Factory wasn't open for submissions from non-SUSE packagers,
fortunately it is obsolete and dead now. It had lower review
standards than Factory and in the end it suffered from the same
quality problems as many OBS projects do.
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.
See above, if you mean packaging quality by "stability" then this
is in most cases not a characteristic of a whole project but
individual packages and currently our only way to measure a certain
quality level is whether a packages has passed Factory review.
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.
Projects should already be collaborative and open to participation,
anyone can send sr's to fix bugs or update version or a
maintainership request if a package is abandoned, provided there
are responsive project maintainers.
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.
I think putting effort into addressing the above is somewhat
misguided, it would be much better spent on adding capacities to
Factory review/maintenance so that it can deal with even larger
numbers of packages and to encourage packagers to maintain their
package in Factory which entails a review and thus a certain
quality standard.
That automatically alleviates users needs to add many additional
project repos in order to get a certain package. And for those who
want bleeding edge version we offer Tumbleweed and hopefully a more
stable Factory soon.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
12:55 p.m.
Le 20/12/2013 11:01, Guido Berhoerster a écrit :
See above, if you mean packaging quality by
"stability" then this
is in most cases not a characteristic of a whole project but
individual packages and currently our only way to measure a certain
quality level is whether a packages has passed Factory review.
I don't remember having seen the "factory" tag on OBS, is there one
and if not is it possible to add one?
ans there should be a link in yast/software to obs to avoid unfriendly
manipulations
right now on a fairly new 13.1 I have tumbleweed, I have special repos
for owncloud and multimedia (specially cdrecord)
jdd
--
http://www.dodin.org
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
1:04 p.m.
* jdd <jdd(a)dodin.org> [2013-12-20 12:55]:
Le 20/12/2013 11:01, Guido Berhoerster a écrit :
You can simply check whether a package in an OBS project is a
link to openSUSE:Factory.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
See above, if you mean packaging quality by
"stability" then this
is in most cases not a characteristic of a whole project but
individual packages and currently our only way to measure a certain
quality level is whether a packages has passed Factory review.
I don't remember having seen the "factory" tag on OBS, is there one
and if not is it possible to add one?
1:12 p.m.
Le 20/12/2013 13:04, Guido Berhoerster a écrit :
well... I just test with owncloud
I notice that factory is one of the options (not the one I have to
use). Is this the answer?
if yes I would vote for a tag "Factory approved" near the title. I
never undertood that this was a quality report :-(
It's probably obvious for developpers, but probably not for many of
the others users
thanks clarifying this
jdd
--
http://www.dodin.org
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
I don't
remember having seen the "factory" tag on OBS, is there one
and if not is it possible to add one?
You can simply check whether a package in an OBS project is a
link to openSUSE:Factory.
1:35 p.m.
* jdd <jdd(a)dodin.org> [2013-12-20 13:12]:
Le 20/12/2013 13:04, Guido Berhoerster a écrit :
well... I just test with owncloud
I notice that factory is one of the options (not the one I have to
use). Is this the answer?
What do you mean here? owncloud is one of the packages that is
not part of the distribution, it is only available from
third-party projects below isv:ownCloud
I
don't remember having seen the "factory" tag on OBS, is there one
and if not is it possible to add one?
You can simply check whether a package in an OBS project is a
link to openSUSE:Factory.
if yes I would vote for a tag "Factory
approved" near the title. I
never undertood that this was a quality report :-(
Being part of Factory, i.e. the official distribution is
currently the only "quality" measurement we have, it means the
package has been reviewed by the review team and meets the minium
quality standards (e.g. conforms to the packaging guidelines).
It's probably obvious for developpers, but
probably not for many of
the others users
Yes.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
2:26 p.m.
Le 20/12/2013 13:35, Guido Berhoerster a écrit :
when I type "owncloud" in the osb package search, I see a list, I
select owncloud, then I get a list of version of openSUSE the package
is available for, on top is "Factory", below are lot of distribution
(AFAIK owncloud is built on obs for all the distribution: the best
openSUSE thing ever :-))
thanks
jdd
--
http://www.dodin.org
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
* jdd <jdd(a)dodin.org> [2013-12-20 13:12]:
well... I just
test with owncloud
I notice that factory is one of the options (not the one I have to
use). Is this the answer?
What do you mean here? owncloud is one of the packages that is
not part of the distribution, it is only available from
third-party projects below isv:ownCloud
3:45 p.m.
* jdd <jdd(a)dodin.org> [2013-12-20 14:27]:
Le 20/12/2013 13:35, Guido Berhoerster a écrit :
when I type "owncloud" in the osb package search, I see a list, I
select owncloud, then I get a list of version of openSUSE the
package is available for, on top is "Factory", below are lot of
That means this it is built for Factory not that it is part of
the official distribution. If it were you probably wouldn't
search for it in the first place but simply "zypper install" it.
The reason why users make use of additional repositories seem to
be that either a package is not maintained as part of the
official distribution or because they want a newer version of it.
In case of the former we'd have to ask why that is and how to
encourage maintaining it in the distro since that is our main
product. In case of the latter a more stable Factory and
Tumbleweed may at least be a partial answer.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
* jdd <jdd(a)dodin.org> [2013-12-20 13:12]:
well... I
just test with owncloud
I notice that factory is one of the options (not the one I have to
use). Is this the answer?
What do you mean here? owncloud is one of the packages that is
not part of the distribution, it is only available from
third-party projects below isv:ownCloud
4:24 p.m.
Le 20/12/2013 15:45, Guido Berhoerster a écrit :
That means this it is built for Factory not that it is
part of
the official distribution.
sure. but I understood from the present discussion that to be accepted
in factory it needed some value test, is that right?
If it were you probably wouldn't
search for it in the first place but simply
"zypper install" it.
The reason why users make use of additional repositories seem to
be that either a package is not maintained as part of the
official distribution or because they want a newer version of it.
In case of the former we'd have to ask why that is and how to
encourage maintaining it in the distro since that is our main
product. In case of the latter a more stable Factory and
Tumbleweed may at least be a partial answer.
"ownCloud provides ready-to-deploy packages for popular Linux
distributions such as Debian, Ubuntu, Fedora, RedHat Enterprise Linux,
CentOS and openSUSE.
Clicking on “Continue” will forward you to the ownCloud community page
at the openSUSE Build Service, which hosts the repositories for all
distributions. Further instructions on how to install ownCloud for
your distribution are also provided there. For setup instructions,
please follow the ownCloud Admin manual."
http://owncloud.org/install/#repoModal
so owncould is officially (officially by ownclouyd) build on obs. So
why is it not in yast?
is it something an user can ask for?
sorry, this seems to diverge from the inital scope of the thread
jdd
--
http://www.dodin.org
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
6:42 p.m.
jdd - 16:24 20.12.13 wrote:
Le 20/12/2013 15:45, Guido Berhoerster a écrit :
It needs review - it has to be reasonably well packaged and legally
distributable. No other restrictions AFAIK.
That means this it is built for Factory not that
it is part of
the official distribution.
sure. but I understood from the present discussion that to be
accepted in factory it needed some value test, is that right? ...
so owncould is officially (officially by ownclouyd) build on obs. So
why is it not in yast?
is it something an user can ask for?
Two answers, depending on what you are asking for.
a) why it isn't in available in YaST software search without adding repositories
It is not part of the distribution, it wasn't integrated, nobody is maintaining
it there. User can became maintainer, maintain it in the distribution (probably
can reuse quite some of the upstream work) and than it will be in the
distribution.
b) why ownCloud is not in community repos offered by YaST
Don't know, probably can be added, try filling a feature request bug :-)
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.net http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
7 Jan
7 Jan
10:38 a.m.
On 20.12.2013 18:42, Michal Hrusecky wrote:
jdd - 16:24 20.12.13 wrote:
I won't add repos to the list by people asking. This list is in no
definition meant to be all inclusive - it's meant to be the most popular
to simplify tasks often done by users.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Le 20/12/2013 15:45, Guido Berhoerster a écrit :
It needs review - it has to be reasonably well packaged and legally
distributable. No other restrictions AFAIK.
That means this it is built for Factory not that
it is part of
the official distribution.
sure. but I understood from the present discussion that to be
accepted in factory it needed some value test, is that right? ...
so owncould is officially (officially by ownclouyd) build on obs. So
why is it not in yast?
is it something an user can ask for?
Two answers, depending on what you are asking for.
a) why it isn't in available in YaST software search without adding repositories
It is not part of the distribution, it wasn't integrated, nobody is maintaining
it there. User can became maintainer, maintain it in the distribution (probably
can reuse quite some of the upstream work) and than it will be in the
distribution.
b) why ownCloud is not in community repos offered by YaST
Don't know, probably can be added, try filling a feature request bug :-)
2568
days inactive
2586
days old
31 comments
8 participants
participants (8)
-
Antoine Saroufim -
Bruno Friedmann -
Greg Freemyer -
Guido Berhoerster -
jdd -
Michael Ikey Doherty -
Michal Hrusecky -
Stephan Kulow