Feature changed by: jason ferrer (jetchisel) Feature #308469, revision 3 Title: Automatically generated list of various private/open repositories Buildservice: Unconfirmed Priority Requester: Important Requested by: Lee Matheson (oldcpu) Description: The new build service promises to make available many new packages for openSUSE community members. It also means proliferation of many packaged rpms to varying standards, with risk of dependency problems and breakage in users openSUSE systems, who add unsupported private repositories without understanding the risk.  A way forward is needed to help both the private packagers and the community in using any newly available packages where appropriate, and not using them where not appropriate for use. A way forward start (but not the final answer) would be an automatically (on a regular basis) generated list posted on a web page/site, that would list all build service repositories, with a comment/descriptive field that the build service packager is required to fill in. A recommend field could be an indication as to their planned future support for any package (ie "one of package" for private use, or "temporary package for TBD time frame", or "planned for long term support", or "packaged for private testing" ... ) etc ... With this automatically generated/re-generated list in place, openSUSE users could go to the list to help them assess if they should download and install an rpm from a repository, or indeed if they should add the repository to their software package manager's repository list. + Discussion: + #1: jason ferrer (jetchisel) (2010-04-11 11:39:56) + Surely an OpenFate material! -- openSUSE Feature: https://features.opensuse.org/308469

Feature changed by: jpxviii jpxviii (jpxviii) Feature #308469, revision 7 Title: Automatically generated list of various private/open repositories Buildservice: Unconfirmed Priority - Requester: Important + Requester: Mandatory Requested by: Lee Matheson (oldcpu) Description: The new build service promises to make available many new packages for openSUSE community members. It also means proliferation of many packaged rpms to varying standards, with risk of dependency problems and breakage in users openSUSE systems, who add unsupported private repositories without understanding the risk.  A way forward is needed to help both the private packagers and the community in using any newly available packages where appropriate, and not using them where not appropriate for use. A way forward start (but not the final answer) would be an automatically (on a regular basis) generated list posted on a web page/site, that would list all build service repositories, with a comment/descriptive field that the build service packager is required to fill in. A recommend field could be an indication as to their planned future support for any package (ie "one of package" for private use, or "temporary package for TBD time frame", or "planned for long term support", or "packaged for private testing" ... ) etc ... With this automatically generated/re-generated list in place, openSUSE users could go to the list to help them assess if they should download and install an rpm from a repository, or indeed if they should add the repository to their software package manager's repository list. Discussion: #1: jason ferrer (jetchisel) (2010-04-11 11:39:56) Surely an OpenFate material! #2: Rick Beauchamp (techwiz03) (2010-04-23 19:39:55) reasonable direction to be taken. -- openSUSE Feature: https://features.opensuse.org/308469

Feature changed by: Sascha Peilicke (saschpe) Feature #308469, revision 9 Title: Automatically generated list of various private/open repositories - Buildservice: Unconfirmed + Buildservice: Rejected by Sascha Peilicke (saschpe) + reject reason: See comment Priority Requester: Mandatory - Hackweek V: Unconfirmed + Hackweek V: Rejected by Sascha Peilicke (saschpe) + reject reason: See comment Priority Requester: Important Requested by: Lee Matheson (oldcpu) Partner organization: openSUSE.org Description: The new build service promises to make available many new packages for openSUSE community members. It also means proliferation of many packaged rpms to varying standards, with risk of dependency problems and breakage in users openSUSE systems, who add unsupported private repositories without understanding the risk.  A way forward is needed to help both the private packagers and the community in using any newly available packages where appropriate, and not using them where not appropriate for use. A way forward start (but not the final answer) would be an automatically (on a regular basis) generated list posted on a web page/site, that would list all build service repositories, with a comment/descriptive field that the build service packager is required to fill in. A recommend field could be an indication as to their planned future support for any package (ie "one of package" for private use, or "temporary package for TBD time frame", or "planned for long term support", or "packaged for private testing" ... ) etc ... With this automatically generated/re-generated list in place, openSUSE users could go to the list to help them assess if they should download and install an rpm from a repository, or indeed if they should add the repository to their software package manager's repository list. Discussion: #1: jason ferrer (jetchisel) (2010-04-11 11:39:56) Surely an OpenFate material! #2: Rick Beauchamp (techwiz03) (2010-04-23 19:39:55) reasonable direction to be taken. + #3: Sascha Peilicke (saschpe) (2011-05-23 11:28:58) + While it is true that a user has to make a decision about + project/package quality, I doubt that forcing packagers to write sth. + on their repos changes anything. Furthermore, projects and packages + have a description, which could be used for your idea. + While it is clear that everything under home: or devel: is potentially + dangerous, there's no way to tell whether any other repo is not. We not + even guarantee this for stable releases. One way is to ask the + maintainer by mail if he agrees that his packages are ready for use. + It's a social issue IMO, not necessarily a technical one. -- openSUSE Feature: https://features.opensuse.org/308469