[opensuse-kde] Repo re-structuring: idea for the second step
Hello everyone! I'd like to share an idea I had when looking at other distro'S update mechanisms for KDE repos. This idea is not necessarily changing the plans for the repository restructuring but a second step in order to solve the issue of users getting confused by the repo structure, no matter which repo structure is agreed upon. There are just too many bits that cannot be solved or explained via the structure of the repos but need some more guidance. Sven --------- Proposal: Hide the repository structure from the user. There are two types of users, update users and testing users. Update users might want: - Only security updates (recommended) - Backports only (minor risk) - minor KDE version updates (minor risk of regressions) - major KDE version updates (normal risk of regressions) + revert to KDE packages that came with [user's distro] Test users might want: (- help testing security updates) - help testing the next openSUSE version (risky) - help testing the next KDE version (very risky) The above options could be put into a systemsettings module. The user would not need to know anything about the repo structure, he just needs to know what he wants to do. The GUI enables the KDE Team to add more information and warnings while easing the testing and usage of KDE packages. And it does not have to worry about the repo structure being understandable by users. The systemsettings module would use kupdateapplet to check for changes and notify the user on KDE login. The actual repository structure could then be something like: (STABLE) KDE43 -- 11.1 -- 11.2 KDE44 -- 11.1 -- 11.2 KDE45 -- 11.1 -- 11.2 Backports -- 11.1 -- 11.2 Factory -- 11.1 -- 11.2 The module automatically picks the correct repo according to the user's settings and distro, i.e. it knows that openSUSE 11.2 was released with 4.3.5 and thus "minor updates" will always stay within KDE43 (unless the user picks scenario c)). A few scenarios: a) A 11.2 user picks "major updates", so currently he would get KDE44 and that repo would hold the 4.4.4 packages. As soon as KDE 4.5 is released, the systemsettings module package in KDE44 -- 11.2 is updated to regard KDE45 as the new repo for "major updates" and notify the user about this change on the next KDE login. If the user does not update he will stay on KDE44, i.e. be safe. b) Let's say KDE 4.5 will not work on openSUSE 11.1. Then the system settings module package in KDE44 -- 11.1 will never get updated to regard KDE45 as the repo for "major updates" and the user would be safe as well. c) A 11.2 user picks "major updates" and thus updates to KDE 4.4.4 from the KDE44 repo. After that he changes his choice to "minor updates". The systemsettings module now has to consider that although the user is on openSUSE 11.2 and has enabled "minor updates" he should still get the packages from KDE44. The same procedure would work if the user picks "help testing next KDE version" and thus updates to KDE45 but changes to "minor updates" before KDE46 is created. d) A 11.2 user wants to help testing the KDE packages for the next distro release without actually installing the new distro betas and thus picks "help testing the next openSUSE version" which will make the systemsettings module use the "Factory -- 11.2" repo. As soon as the KDE packages from Factory get released as part of a new distro version the systemsettings module package in that repo will also get updated and warn the user that the KDE version in Factory changed. e) A 11.2 user wants to help testing the next KDE version and thus picks the respective setting. He will then get KDE45 -- 11.2 and as soon as KDE SC 4.5 is released the systemsettings module package in that repo will get updated as well and warn the user. The systemsettings module cannot be part of 11.3 and I'm not sure it should be part of the distro because it might make "testing" packages too easy. So instead of it being part of the distro, the user can just install it via one- click. The GUI could look like this and include links to the wiki or another source of help and explanations: openSUSE KDE repository settings Current status and choice plus a button to execute that choice, e.g.: You are using KDE 4.4.4 and have enabled minor updates for KDE 4.4. [There are currently no new updates available] (This line depends on the user's choice below) or You are using KDE 4.3.5 and have enabled major updates for KDE [Click here to update to KDE 4.4.4] or You are using KDE 4.3.5 and have enabled updates for testing KDE for openSUSE 11.3 [Click here to update to KDE 4.4.3] or You are using KDE 4.5 RC1 and have enabled updates for testing the next KDE version. [Click here to update to KDE 4.5 RC2] or You are using KDE 4.5 RC1 and have chosen to revert to the packages that are part of openSUSE 11.2 [Click here to revert to KDE 4.3.5] If you want to update: [] Only security updates (recommended) [] Backports only, e.g. applications like amarok or digikam (minor risk) [] only minor KDE version updates, e.g. KDE 4.3.1 to KDE 4.3.5 (minor risk of regressions) [] inlcuding major KDE version updates, e.g. KDE 4.3 to KDE 4.4 (normal risk of regressions) [] revert to KDE packages that came with [user's distro] If you want to test KDE packages: ([] help testing security updates) [] help testing the next openSUSE version (risky) [] help testing the next KDE version (very risky) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 7. juni 2010 15:29:28 skrev Sven Burmeister:
There are two types of users, update users and testing users.
Update users might want: - Only security updates (recommended) - Backports only (minor risk) - minor KDE version updates (minor risk of regressions) - major KDE version updates (normal risk of regressions) + revert to KDE packages that came with [user's distro]
Test users might want:
(- help testing security updates) - help testing the next openSUSE version (risky) - help testing the next KDE version (very risky)
I also think there are two types of users: 1) "civilians" (90-95%) 2) geeks and fanboys (5-10%) Civilians will just use the kde version shipped, and maybe add Backports and Community/Extra - which is easily done with clicky, clicky in yast community repositories. Anyone who doesn't think this is good enough ceases to be a civilian by definition - and therefore in my mind the user immediately forfeits his handholding and whining privileges.
The above options could be put into a systemsettings module. The user would not need to know anything about the repo structure, he just needs to know what he wants to do. The GUI enables the KDE Team to add more information and warnings while easing the testing and usage of KDE packages. And it does not have to worry about the repo structure being understandable by users. The systemsettings module would use kupdateapplet to check for changes and notify the user on KDE login.
The actual repository structure could then be something like:
(STABLE) KDE43 -- 11.1 -- 11.2 KDE44 -- 11.1 -- 11.2 KDE45 -- 11.1 -- 11.2 Backports -- 11.1 -- 11.2 Factory -- 11.1 -- 11.2
I see a number of issues. * Who would package and maintain the 44 and 45 repos? * Who would write and maintain such a systemsettings module? * The average user would always underestimate the risks and inconveniences and select all kinds of updates he doesn't need, which will cause more problems than they solve * User support would be a impossible with such a large number of different kde versions and flavours in circulation In my opinion this would be using waaaaay too many resources to please small - albeit very loud - minority - with little benefit to the distro and the project. We need to be careful with resources, and I think what we already have is pretty great. Civilians can add Backports and Extra/Community easily. Geeks and fanboys should be able to figure out how to add Playground, Factory or Unstable manually, and if they can't, then they're probably better off not using these repos in the first place. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Monday 07 of June 2010, Martin Schlander wrote:
Mandag den 7. juni 2010 15:29:28 skrev Sven Burmeister:
There are two types of users, update users and testing users.
Update users might want: - Only security updates (recommended) - Backports only (minor risk) - minor KDE version updates (minor risk of regressions) - major KDE version updates (normal risk of regressions) + revert to KDE packages that came with [user's distro]
Test users might want:
(- help testing security updates) - help testing the next openSUSE version (risky) - help testing the next KDE version (very risky)
I also think there are two types of users:
1) "civilians" (90-95%) 2) geeks and fanboys (5-10%)
Civilians will just use the kde version shipped, and maybe add Backports and Community/Extra - which is easily done with clicky, clicky in yast community repositories.
Right. The rest of the cases can be handled using Wiki pages, which is both easier (for us, for users it can be considered an entry test) and more flexible. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 7. Juni 2010, 16:32:33 schrieb Martin Schlander:
I see a number of issues.
* Who would package and maintain the 44 and 45 repos?
Those repos do already exist. Dirk built KDE 4.4.4 in his home, so uploading the tarballs etc. has to be done anyway for every KDE release. Most issues of major KDE releases are already sorted out while they are in UNSTABLE. After that they would move to a KDExy repo and only need minor version updates every four weeks. I had the impression that minor updates of KDE versions and their packaging was quite smooth in the past, i.e. with KDE 4.3 and KDE 4.4.
* Who would write and maintain such a systemsettings module?
It would be a tool like ksuseinstall and written/maintained by openSUSE KDE devs if nobody else volunteers. If the information about which repo is what "update choice" for which distro version is kept in some kind of text file, this text file can also be maintained easily by the community, as it is a simple matter of editing a few lines every four weeks.
* The average user would always underestimate the risks and inconveniences and select all kinds of updates he doesn't need, which will cause more problems than they solve
Currently users exchange repo links for Qt and KDE via mailinglist or a forum which causes a lot of trouble. I do not see how this would get worse. I'd claim it gets better because with the GUI no wrong repo can be added which is one major source of trouble. On top of that the users can easily revert to the distro's KDE version which is another step to saving trouble in case things go wrong. So IMHO it only saves trouble and does not add any.
* User support would be a impossible with such a large number of different kde versions and flavours in circulation
There is no user support now, there won't be any then.
In my opinion this would be using waaaaay too many resources to please small - albeit very loud - minority - with little benefit to the distro and the project.
As I mentioned above, IMHO it would save resources in the middle and long term. I'm not sure what it's worth to count as a distro that enables the user to safer KDE updates than before. But updates would be a lot safer simply because no wrong repo can be added. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (3)
-
Lubos Lunak -
Martin Schlander -
Sven Burmeister