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@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org