On Mon, 7 Jul 2008, Marko Jung wrote:
after a lot of inspiring conversations with co-workers at SUSE and friends from the open source community I finally published a first abstract draft how we could add some metrics to openSUSE build service to create a trust system.
http://en.opensuse.org/Build_Service/Concepts/Trust
This article does not go much into particular neither explains concrete implementation details. Main target of this proposal is to have a basis for discussion. The article even goes beyond the focus on trust and proposes some additional metrics to support openSUSE users in their decision from which repositories they should obtain their software packages.
Within the next weeks I would like to discuss this with you. So if you are interested in this topic please contact me. Any suggestions, feedback or critics are highly appreciated.
Some comments. -snip- Proven identity A user that identifies himself in a trusted way, by sending e.g. his work/living address, contact details or a copy of his id, in a trusted way to a trusted entity makes himself much more responsible for his work. A SUSE/Novell employee has done this identification by signing his work contract, but others shall be able to get on the same level by sending their id to a review board or an adequate standardised process. Here are several options possible. For example, we could adopt the assurance process of CAcert.org, where a new user has to get approved by several existing ones, before he is able to create certificates. Another possibility is to request a user to submit his public GNU Privacy Guard key, which has to be signed by a given amount of well known openSUSE build service users. -snip- Although my name is my real-world-name, my network identity has very few crossings with my life in the outside world. Also my work-indentity and reputation is not very closely linked to my networking myself. Thus such an proven identity would prove I am I, but would not tell you anything more about the fact if I'm trustworthy or not. There have been and there are many people who trust me in case of software development, who have never ever seen me, talked to me in person or even had a phone call to me. Nevertheless they trust me. If I would use a pseuddnum, the facts would be the same, only it would be impossible for me to have an "proven identity".
From my side of view openSUSE build service should start with some internal metrics first:
a) How long is the user member of the community b) What is his activity level c) How does he handle bug reports d) rpmlint/failures/package qualities and stuff like that. Next would be ratings and human opinion specifics a) What do others thing about the user b) Involved in upstream c) Involved in bug fixes -snip- Availability for several architectures and products A good packager takes care of his packages for all shipped architectures (like i586, amd64, s390, ppc) as well as older (not discontinued) products (e.g. openSUSE 10.2, openSUSE 10.3). In addition to the history described above we should enhance the version and build history to observe all platforms and products. -snip- I don't think this can be used as rating. Lots of new packages don't build with older products and also the discussion to keep old stuff available seems an never ending story. I don't think this qualifies as trust indicator. -snip- Package history / version numbers Some users have a high demand for bleeding edge software. On the other hand, many users just want to get (security) bugs fixed without any further changes or feature additions. -snip- Although it's a nice idea, it first requires a way to notice the packager about new versions. I maintain a lot of packages and cannot have a look at every package everday to see if there is a new release. Also I cannot subscribe to all the mailingslists and info channels to be notified about news (I already get too much mail, wont have to check more). Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org