KDE:Extra) Obviously this can't be done too frequently as it would annoy the user, but it is clear that there needs to be some communications channel to let them know what's going on.

Feature changed by: Pavol Rusnak (prusnak) Feature #310604, revision 4 Title: Push repository Status to Users Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Tejas Guruswamy (masterpatricko) Description: One of the major complaints from users of the OBS is that it is too hard to identify which package out of multiple available ones is the correct, "safe", one to install. Also repository changes have no way of being noticed except with zypp refreshes suddenly start failing. The OBS provides an amazing, amazing service but still little complications arise; repositories disappear, change content, etc. Three parts would need to be implemented: 1) A "status" or "stability" attribute for all repositories on the OBS. It could have values like * UNSTABLE - This repository contains unreleased software / alpha- quality, possibly direct from source control. Bugs are to be expected. (e.g. KDE:Unstable:Distro ) * FACTORY (or LATEST?) - This repository contains the latest released software from this upstream project, to be submitted to openSUSE Factory. Bugs are possible, please report them. (e.g. KDE:Distro: Factory) * STABLE - This repository contains software as it was in the last stable release of openSUSE, possibly with some additional bugfixes. Bugs should be infrequent. (e.g. KDE:Distro:Stable) * HOME(?) - This repository is someone's Home project. Packages may be added and removed at any time. (maybe not necessary) * VERSION(?) - This repository contains a snapshot of a specific released version of this software. (maybe not necessary) (e.g. KDE:SC: 45) I know the OBS supports attributes, so maybe that infrastructure can be used. The current solution of trying to explain it in the repository name is not sufficient as people have conflicting ideas of what "Factory" means, etc. With the explanations side-by-side, there can be no confusion. What would need to be added is * integration with software.opensuse.org and webpin - so repository state is clearly visible in search results, with the explanations of each state also visible on the same page. * integration with Yast2/zypper - in the repository configuration, the repository state should be shown (does it need to be updated every so often? will repositories ever change their state?) 2) A NEWS/ChangeLog file/attribute for every repository on the OBS. This allows the repository owner/maintainer to communicate with the users letting them know of important changes that affect them. This would be downloaded with the repository metadata. This would need to be integrated into: * OBS - easy way to edit this file should be possible (maybe it can be based on the repository description?) * Yast2/zypper/updateapplet - when refreshing a repository, if a changed NEWS is detected, inform the user. something like > zypper ref Repository "foobar" has updated its NEWS file. [Read/Ignore/Skip]: where you can choose to read the changes now, leave it till next time, or ignore it completely. Currently the build service project page is the only place where such information is put, but users never read that. Otherwise you have to resort to the mailing lists, but most users aren't subscribed there until they have a problem. The NEWS file would be used to pass on information including: * Significant changes to the purpose or content of the repository (e.g. KDE:Distro:Factory switching from KDE SC 4.5 to 4.6) * Repository renames, obsoletions, deletions (e.g. KDE:KDE4:Community - 3) Improved software search - software.opensuse.org and webpin could become a lot more new-user friendly. Some of my suggestions * Exclude HOME and UNSTABLE projects * Exclude debuginfo and debugsource packages by default * Exclude devel packages by default * Default to only searching for the current, released version of openSUSE. * Display repository status as detailed above I think this could make an absolutely huge difference to how users use the OBS, and most of all, make it a lot more safe - reducing complaints. I know that repository stability attributes have been mentioned by many people many times - but now the infrastructure is there - lets take it one step further... (BTW Forgive my KDE examples, it's just what I am familiar with) + Discussion: + #1: Pavol Rusnak (prusnak) (2010-09-27 11:52:17) + The 3rd item (software.o.o) is almost done already. Search already + excludes home projects and debug packages by default. Also by default + it searches in the latest released openSUSE version. -- openSUSE Feature: https://features.opensuse.org/310604

KDE:Extra) Obviously this can't be done too frequently as it would annoy the user, but it is clear that there needs to be some communications channel to let them know what's going on.

Feature changed by: Tejas Guruswamy (MasterPatricko) Feature #310604, revision 6 Title: Push repository Status to Users Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Tejas Guruswamy (masterpatricko) Description: One of the major complaints from users of the OBS is that it is too hard to identify which package out of multiple available ones is the correct, "safe", one to install. Also repository changes have no way of being noticed except with zypp refreshes suddenly start failing. The OBS provides an amazing, amazing service but still little complications arise; repositories disappear, change content, etc. Three parts would need to be implemented: 1) A "status" or "stability" attribute for all repositories on the OBS. It could have values like * UNSTABLE - This repository contains unreleased software / alpha- quality, possibly direct from source control. Bugs are to be expected. (e.g. KDE:Unstable:Distro ) * FACTORY (or LATEST?) - This repository contains the latest released software from this upstream project, to be submitted to openSUSE Factory. Bugs are possible, please report them. (e.g. KDE:Distro: Factory) * STABLE - This repository contains software as it was in the last stable release of openSUSE, possibly with some additional bugfixes. Bugs should be infrequent. (e.g. KDE:Distro:Stable) * HOME(?) - This repository is someone's Home project. Packages may be added and removed at any time. (maybe not necessary) * VERSION(?) - This repository contains a snapshot of a specific released version of this software. (maybe not necessary) (e.g. KDE:SC: 45) I know the OBS supports attributes, so maybe that infrastructure can be used. The current solution of trying to explain it in the repository name is not sufficient as people have conflicting ideas of what "Factory" means, etc. With the explanations side-by-side, there can be no confusion. What would need to be added is * integration with software.opensuse.org and webpin - so repository state is clearly visible in search results, with the explanations of each state also visible on the same page. * integration with Yast2/zypper - in the repository configuration, the repository state should be shown (does it need to be updated every so often? will repositories ever change their state?) 2) A NEWS/ChangeLog file/attribute for every repository on the OBS. This allows the repository owner/maintainer to communicate with the users letting them know of important changes that affect them. This would be downloaded with the repository metadata. This would need to be integrated into: * OBS - easy way to edit this file should be possible (maybe it can be based on the repository description?) * Yast2/zypper/updateapplet - when refreshing a repository, if a changed NEWS is detected, inform the user. something like > zypper ref Repository "foobar" has updated its NEWS file. [Read/Ignore/Skip]: where you can choose to read the changes now, leave it till next time, or ignore it completely. Currently the build service project page is the only place where such information is put, but users never read that. Otherwise you have to resort to the mailing lists, but most users aren't subscribed there until they have a problem. The NEWS file would be used to pass on information including: * Significant changes to the purpose or content of the repository (e.g. KDE:Distro:Factory switching from KDE SC 4.5 to 4.6) * Repository renames, obsoletions, deletions (e.g. KDE:KDE4:Community - 3) Improved software search - software.opensuse.org and webpin could become a lot more new-user friendly. Some of my suggestions * Exclude HOME and UNSTABLE projects * Exclude debuginfo and debugsource packages by default * Exclude devel packages by default * Default to only searching for the current, released version of openSUSE. * Display repository status as detailed above I think this could make an absolutely huge difference to how users use the OBS, and most of all, make it a lot more safe - reducing complaints. I know that repository stability attributes have been mentioned by many people many times - but now the infrastructure is there - lets take it one step further... (BTW Forgive my KDE examples, it's just what I am familiar with) Discussion: #1: Pavol Rusnak (prusnak) (2010-09-27 11:52:17) The 3rd item (software.o.o) is almost done already. Search already excludes home projects and debug packages by default. Also by default it searches in the latest released openSUSE version. #2: Ralph Ulrich (ulenrich) (2010-09-27 14:28:57) I think the mess with the repository tree is because a multidimensional problem was tried to implement in a one dimensional tree. The wise man says: "Make a solution as simple as can be but not any simpler". These dimensions we now have in one tree: 1) Distributions tree - 11.2 11.3 etc 2) Maturity - like stable unstable 3) Rolling or fixed - releases like factory 4) Version tree - bundles like kde4.5 5) Users - home 6) Software kategories 7) Media - iso or rpm 8) Arch 9) Dev, debug - implemented as dev packages names + #3: Tejas Guruswamy (masterpatricko) (2010-10-26 12:49:34) (reply to + #2) + I agree completely, all the information you list is necessary for the end- + user to know but there is no standard way to get it to them. + Compressing it all into the repository name is confusing as every + packaging group has a different idea of how it should be done. -- openSUSE Feature: https://features.opensuse.org/310604

KDE:Extra) Obviously this can't be done too frequently as it would annoy the user, but it is clear that there needs to be some communications channel to let them know what's going on.

Feature changed by: Tejas Guruswamy (MasterPatricko) Feature #310604, revision 8 Title: Push repository Status to Users Buildservice: Unconfirmed Priority Requester: Important openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Tejas Guruswamy (masterpatricko) Partner organization: openSUSE.org Description: One of the major complaints from users of the OBS is that it is too hard to identify which package out of multiple available ones is the correct, "safe", one to install. Also repository changes have no way of being noticed except with zypp refreshes suddenly start failing. The OBS provides an amazing, amazing service but still little complications arise; repositories disappear, change content, etc. Three parts would need to be implemented: 1) A "status" or "stability" attribute for all repositories on the OBS. It could have values like * UNSTABLE - This repository contains unreleased software / alpha- quality, possibly direct from source control. Bugs are to be expected. (e.g. KDE:Unstable:Distro ) * FACTORY (or LATEST?) - This repository contains the latest released software from this upstream project, to be submitted to openSUSE Factory. Bugs are possible, please report them. (e.g. KDE:Distro: Factory) * STABLE - This repository contains software as it was in the last stable release of openSUSE, possibly with some additional bugfixes. Bugs should be infrequent. (e.g. KDE:Distro:Stable) * HOME(?) - This repository is someone's Home project. Packages may be added and removed at any time. (maybe not necessary) * VERSION(?) - This repository contains a snapshot of a specific released version of this software. (maybe not necessary) (e.g. KDE:SC: 45) I know the OBS supports attributes, so maybe that infrastructure can be used. The current solution of trying to explain it in the repository name is not sufficient as people have conflicting ideas of what "Factory" means, etc. With the explanations side-by-side, there can be no confusion. What would need to be added is * integration with software.opensuse.org and webpin - so repository state is clearly visible in search results, with the explanations of each state also visible on the same page. * integration with Yast2/zypper - in the repository configuration, the repository state should be shown (does it need to be updated every so often? will repositories ever change their state?) 2) A NEWS/ChangeLog file/attribute for every repository on the OBS. This allows the repository owner/maintainer to communicate with the users letting them know of important changes that affect them. This would be downloaded with the repository metadata. This would need to be integrated into: * OBS - easy way to edit this file should be possible (maybe it can be based on the repository description?) * Yast2/zypper/updateapplet - when refreshing a repository, if a changed NEWS is detected, inform the user. something like > zypper ref Repository "foobar" has updated its NEWS file. [Read/Ignore/Skip]: where you can choose to read the changes now, leave it till next time, or ignore it completely. Currently the build service project page is the only place where such information is put, but users never read that. Otherwise you have to resort to the mailing lists, but most users aren't subscribed there until they have a problem. The NEWS file would be used to pass on information including: * Significant changes to the purpose or content of the repository (e.g. KDE:Distro:Factory switching from KDE SC 4.5 to 4.6) * Repository renames, obsoletions, deletions (e.g. KDE:KDE4:Community - 3) Improved software search - software.opensuse.org and webpin could become a lot more new-user friendly. Some of my suggestions * Exclude HOME and UNSTABLE projects * Exclude debuginfo and debugsource packages by default * Exclude devel packages by default * Default to only searching for the current, released version of openSUSE. * Display repository status as detailed above I think this could make an absolutely huge difference to how users use the OBS, and most of all, make it a lot more safe - reducing complaints. I know that repository stability attributes have been mentioned by many people many times - but now the infrastructure is there - lets take it one step further... (BTW Forgive my KDE examples, it's just what I am familiar with) + Business case (Partner benefit): + openSUSE.org: Using the OBS becomes safer for new users, because they + can + 1) Easily identify if it is safe to use packages from a repo + 2) Are notified when the repo changes + Therefore users will realise the huge number of packages available for + openSUSE outside the distro. Discussion: #1: Pavol Rusnak (prusnak) (2010-09-27 11:52:17) The 3rd item (software.o.o) is almost done already. Search already excludes home projects and debug packages by default. Also by default it searches in the latest released openSUSE version. #2: Ralph Ulrich (ulenrich) (2010-09-27 14:28:57) I think the mess with the repository tree is because a multidimensional problem was tried to implement in a one dimensional tree. The wise man says: "Make a solution as simple as can be but not any simpler". These dimensions we now have in one tree: 1) Distributions tree - 11.2 11.3 etc 2) Maturity - like stable unstable 3) Rolling or fixed - releases like factory 4) Version tree - bundles like kde4.5 5) Users - home 6) Software kategories 7) Media - iso or rpm 8) Arch 9) Dev, debug - implemented as dev packages names #3: Tejas Guruswamy (masterpatricko) (2010-10-26 12:49:34) (reply to #2) I agree completely, all the information you list is necessary for the end- user to know but there is no standard way to get it to them. Compressing it all into the repository name is confusing as every packaging group has a different idea of how it should be done. -- openSUSE Feature: https://features.opensuse.org/310604

KDE:Extra) Obviously this can't be done too frequently as it would annoy the user, but it is clear that there needs to be some communications channel to let them know what's going on.

Feature changed by: Karl Cheng (qantas94heavy) Feature #310604, revision 10 Title: Push repository Status to Users - Buildservice: Unconfirmed + Buildservice: New Priority Requester: Important - openSUSE Distribution: Unconfirmed + openSUSE Distribution: New Priority Requester: Desirable Requested by: Tejas Guruswamy (masterpatricko) Partner organization: openSUSE.org Description: One of the major complaints from users of the OBS is that it is too hard to identify which package out of multiple available ones is the correct, "safe", one to install. Also repository changes have no way of being noticed except with zypp refreshes suddenly start failing. The OBS provides an amazing, amazing service but still little complications arise; repositories disappear, change content, etc. Three parts would need to be implemented: 1) A "status" or "stability" attribute for all repositories on the OBS. It could have values like * UNSTABLE - This repository contains unreleased software / alpha- quality, possibly direct from source control. Bugs are to be expected. (e.g. KDE:Unstable:Distro ) * FACTORY (or LATEST?) - This repository contains the latest released software from this upstream project, to be submitted to openSUSE Factory. Bugs are possible, please report them. (e.g. KDE:Distro: Factory) * STABLE - This repository contains software as it was in the last stable release of openSUSE, possibly with some additional bugfixes. Bugs should be infrequent. (e.g. KDE:Distro:Stable) * HOME(?) - This repository is someone's Home project. Packages may be added and removed at any time. (maybe not necessary) * VERSION(?) - This repository contains a snapshot of a specific released version of this software. (maybe not necessary) (e.g. KDE:SC: 45) I know the OBS supports attributes, so maybe that infrastructure can be used. The current solution of trying to explain it in the repository name is not sufficient as people have conflicting ideas of what "Factory" means, etc. With the explanations side-by-side, there can be no confusion. What would need to be added is * integration with software.opensuse.org and webpin - so repository state is clearly visible in search results, with the explanations of each state also visible on the same page. * integration with Yast2/zypper - in the repository configuration, the repository state should be shown (does it need to be updated every so often? will repositories ever change their state?) 2) A NEWS/ChangeLog file/attribute for every repository on the OBS. This allows the repository owner/maintainer to communicate with the users letting them know of important changes that affect them. This would be downloaded with the repository metadata. This would need to be integrated into: * OBS - easy way to edit this file should be possible (maybe it can be based on the repository description?) * Yast2/zypper/updateapplet - when refreshing a repository, if a changed NEWS is detected, inform the user. something like > zypper ref Repository "foobar" has updated its NEWS file. [Read/Ignore/Skip]: where you can choose to read the changes now, leave it till next time, or ignore it completely. Currently the build service project page is the only place where such information is put, but users never read that. Otherwise you have to resort to the mailing lists, but most users aren't subscribed there until they have a problem. The NEWS file would be used to pass on information including: * Significant changes to the purpose or content of the repository (e.g. KDE:Distro:Factory switching from KDE SC 4.5 to 4.6) * Repository renames, obsoletions, deletions (e.g. KDE:KDE4:Community - 3) Improved software search - software.opensuse.org and webpin could become a lot more new-user friendly. Some of my suggestions * Exclude HOME and UNSTABLE projects * Exclude debuginfo and debugsource packages by default * Exclude devel packages by default * Default to only searching for the current, released version of openSUSE. * Display repository status as detailed above I think this could make an absolutely huge difference to how users use the OBS, and most of all, make it a lot more safe - reducing complaints. I know that repository stability attributes have been mentioned by many people many times - but now the infrastructure is there - lets take it one step further... (BTW Forgive my KDE examples, it's just what I am familiar with) Business case (Partner benefit): openSUSE.org: Using the OBS becomes safer for new users, because they can 1) Easily identify if it is safe to use packages from a repo 2) Are notified when the repo changes Therefore users will realise the huge number of packages available for openSUSE outside the distro. Discussion: #1: Pavol Rusnak (prusnak) (2010-09-27 11:52:17) The 3rd item (software.o.o) is almost done already. Search already excludes home projects and debug packages by default. Also by default it searches in the latest released openSUSE version. #2: Ralph Ulrich (ulenrich) (2010-09-27 14:28:57) I think the mess with the repository tree is because a multidimensional problem was tried to implement in a one dimensional tree. The wise man says: "Make a solution as simple as can be but not any simpler". These dimensions we now have in one tree: 1) Distributions tree - 11.2 11.3 etc 2) Maturity - like stable unstable 3) Rolling or fixed - releases like factory 4) Version tree - bundles like kde4.5 5) Users - home 6) Software kategories 7) Media - iso or rpm 8) Arch 9) Dev, debug - implemented as dev packages names #3: Tejas Guruswamy (masterpatricko) (2010-10-26 12:49:34) (reply to #2) I agree completely, all the information you list is necessary for the end- user to know but there is no standard way to get it to them. Compressing it all into the repository name is confusing as every packaging group has a different idea of how it should be done. #4: Adrian Schröter (adriansuse) (2012-04-17 09:32:05) The attribute to classify a project exists in OBS 2.3 (fate #306232), just webui and software.o.o makes no use of it yet. -- openSUSE Feature: https://features.opensuse.org/310604