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)"
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
On Fri, 2013-12-20 at 10:00 +0100, Michal Hrusecky wrote:
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
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.
On Fri, 2013-12-20 at 15:01 +0000, Antoine Saroufim wrote:
On Fri, 2013-12-20 at 10:00 +0100, Michal Hrusecky wrote:
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
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.
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�����Ǩ�
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 :-)
On Fri, 2013-12-20 at 17:33 +0100, Bruno Friedmann wrote:
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 :-)
Thanks :)
--
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.
Bruno Friedmann - 17:33 20.12.13 wrote:
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 :-)
+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...
On Fri, 2013-12-20 at 18:35 +0100, Michal Hrusecky wrote:
Bruno Friedmann - 17:33 20.12.13 wrote:
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 :-)
+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...
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 :)
-- 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.
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 :-)
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
jdd - 16:28 20.12.13 wrote:
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...
http://en.opensuse.org/Communication :-)
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 :-)
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?
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.
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky wrote:
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?
On Fri, 2013-12-20 at 19:50 +0000, Antoine Saroufim wrote:
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky wrote:
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?
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.
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!
On Fri, 2013-12-20 at 19:21 +0100, Michal Hrusecky wrote:
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 ;-)
Ehm, that as well! Terrible example but yes, factory :)
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 :-)
Indeed, need to encourage send-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 :-)
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)
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!
Awesome :)
-- 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.
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:
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky wrote:
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?
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Ǩ
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 20:04 +0000, Antoine Saroufim wrote:
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:
On Fri, 2013-12-20 at 18:29 +0100, Michal Hrusecky wrote:
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?
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Ǩ
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.
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.
Antoine Saroufim antoine.saroufim@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
Greg Freemyer - 13:24 20.12.13 wrote:
Antoine Saroufim antoine.saroufim@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?
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.
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.
* Antoine Saroufim antoine.saroufim@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.
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
* jdd jdd@dodin.org [2013-12-20 12:55]:
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?
You can simply check whether a package in an OBS project is a link to openSUSE:Factory.
Le 20/12/2013 13:04, Guido Berhoerster a écrit :
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.
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
* jdd jdd@dodin.org [2013-12-20 13:12]:
Le 20/12/2013 13:04, Guido Berhoerster a écrit :
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.
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
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.
Le 20/12/2013 13:35, Guido Berhoerster a écrit :
- jdd jdd@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
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
* jdd jdd@dodin.org [2013-12-20 14:27]:
Le 20/12/2013 13:35, Guido Berhoerster a écrit :
- jdd jdd@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
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.
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
jdd - 16:24 20.12.13 wrote:
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?
It needs review - it has to be reasonably well packaged and legally distributable. No other restrictions AFAIK.
...
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 :-)
On 20.12.2013 18:42, Michal Hrusecky wrote:
jdd - 16:24 20.12.13 wrote:
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?
It needs review - it has to be reasonably well packaged and legally distributable. No other restrictions AFAIK.
...
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 :-)
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
-
Antoine Saroufim -
Bruno Friedmann -
Greg Freemyer -
Guido Berhoerster -
jdd -
Michael Ikey Doherty -
Michal Hrusecky -
Stephan Kulow