[opensuse-project] Build Service trust/rating system
Hi everybody. I want to raise your attention on a project I'm currently working on with Adrian: the implementation of a trust/rating system for the OBS. We'd appreciate if everyone interested could communicate his opinions/thoughts/impressions on this. We are very interested to get some input from the whole openSUSE community. Adrian has already posted a wiki entry which gives further information on the subject here... http://en.opensuse.org/Build_Service/Concepts/Trust Feel free to comment on this - input is highly appreciated! Thanks, Rupert -- Rupert Horstkötter, Product Management Email: rhorstkoetter@novell.com Phone: +49 911 74053 649 SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jan 29, 2008 at 03:12:49PM +0100, Rupert Horstkötter wrote:
Hi everybody.
I want to raise your attention on a project I'm currently working on with Adrian: the implementation of a trust/rating system for the OBS. We'd appreciate if everyone interested could communicate his opinions/thoughts/impressions on this. We are very interested to get some input from the whole openSUSE community. Adrian has already posted a wiki entry which gives further information on the subject here... http://en.opensuse.org/Build_Service/Concepts/Trust Feel free to comment on this - input is highly appreciated!
I read the proposal it I like it. It seems reasonable and doable. I appreciate the decision to offer different ways of how trust can be "earned". I'm not sure if that can be molded into a single number, however I would be happy with several separate "channels" of trust, if you know what I mean. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tuesday 29 January 2008, Dr. Peter Poeml said:
On Tue, Jan 29, 2008 at 03:12:49PM +0100, Rupert Horstkötter wrote:
I want to raise your attention on a project I'm currently working on with Adrian: the implementation of a trust/rating system for the OBS. We'd appreciate if everyone interested could communicate his opinions/thoughts/impressions on this. We are very interested to get some input from the whole openSUSE community. Adrian has already posted a wiki entry which gives further information on the subject here... http://en.opensuse.org/Build_Service/Concepts/Trust Feel free to comment on this - input is highly appreciated!
I read the proposal it I like it. It seems reasonable and doable. I appreciate the decision to offer different ways of how trust can be "earned". I'm not sure if that can be molded into a single number, however I would be happy with several separate "channels" of trust, if you know what I mean.
Agreed, since trust is advisory, one's assessment of trust would be helped by having some discrete information on a packager eg: Joe Packager Individual assertions of trustworthiness [x] signed guiding principles [x] signed maintenance agreement [x] assured identity Trust Testimonials from others [x] Novell employee trusted by Jane Packager (trust: 40) trusted by Jim Packager (trust: 10) trusted by Johnny Packager (trust: 1) Statistics Time in project: 3 years 1 month Packages maintained: 12 Mean package update latency: 10.3 days [*] Bugs/package: 1.7 [**] Mean Rpmlint warning score: 20 I guess you could come up with some kind of weighting for each of these values to come up with an overall trust metric. My question is, how would this trust metric be used? Is it shown to the user upon adding a repo along with a scale explaining eg "Trust 100 - 80: Highly trusted. These packages are believed to be of high quality, follow openSUSE packaging guidelines well and are kept up to date, ..."? I guess the trust scoring system is influenced by cacert.org - can someone actively involved there explain the rest of their mechanism? [*] could be computed by logging release dates from Marcus' release scraper scripts and comparing those to the dates packages were updated [**] fairly arbitrary unless there were a way to distinguish packaging bugs on a package. Will -- Desktop Engineer KDE Team --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi there, I've appended some random notes, ... On Montag, 4. Februar 2008, Will Stephenson wrote:
Agreed, since trust is advisory, one's assessment of trust would be helped by having some discrete information on a packager eg:
Joe Packager Individual assertions of trustworthiness [x] signed guiding principles [x] signed maintenance agreement [x] assured identity Trust Testimonials from others [x] Novell employee trusted by Jane Packager (trust: 40) trusted by Jim Packager (trust: 10) trusted by Johnny Packager (trust: 1) Statistics Time in project: 3 years 1 month Packages maintained: 12 Mean package update latency: 10.3 days [*] Bugs/package: 1.7 [**] Mean Rpmlint warning score: 20
1. I'd like to see some more things that the packager tells about himself: programming skills: the programming languages a packager can fix bugs in the packages. building skills: how familiar is the packager with autotools, cmake, ... to fix build issues packaging skills, simple builds, library builds, special things like python packages desktop integration, ... oss projects the packager is member in. 2. I'd like to see a place where a packager can write some comments about each package and why it was build this way. * Why was it build? * personal interest * for the university/company * because the packager is one of the developers * because the package is required by another one * just for fun * Packaging decisions? * why was the package not build for new/old distributions * why was it build this way * Support for the package? * will the packager support the package (bug fixing) * will the package be fixed if it's hard to build or will it be dropped. * How to test the package? * run make check * run the application with some example files * ... 3. Splitting the build process into 3 steps could increase the quality * packaging * testing * publishing Currently it's hard to test a package in the build service as the build rpms are published immediatly. I think it would be an improvement to have an explicit test stage. Then we could create a chain of packaging, testing and publishing. The tester could be the packager, or another member of a specific project, or even a user without packaging skills. * the packager could create the package notify it to the tester * the tester tests the package and publishes it. The tester also could take care of publishing a bunch of related packages in one step. This could also increase the trust into a package. A tester with a high trust rate could increase the trust of the packager and vice versa. BTW: It would be nice to read some stories about how the core distribution is build and tested. Regards Werner -- Member of the science repo developer in the geda project geda.seul.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (4)
-
Dr. Peter Poeml -
Rupert Horstkötter -
Werner Hoch -
Will Stephenson