Mailinglist Archive: opensuse-buildservice (351 mails)

< Previous Next >
Re: [opensuse-buildservice] openSUSE Build Service Trust concept
  • From: Christian Boltz <opensuse@xxxxxxxxx>
  • Date: Tue, 8 Jul 2008 23:23:59 +0200
  • Message-id: <200807082324.02044@xxxxxxxxxxxxxxx>
Hello,

on Montag, 7. Juli 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

Your text looks like you have invested lots of time :-)

Nevertheless I found some things I'd like to comment on:


Despite all proposed values make an effort to evaluate a package and
not its producers, this project does a lot of data mining.
Therefore, it has to be evaluated if there are any violations of
privacy.

Very valid point!

In addition to this, all metrics which would enable performance
measurement of Novell employees should be disabled by default as
soon as the employee flag is set for an account.

Please use the same defaults for everybody. If you think something
should be disabled by default for Novell employees, there's a great
chance community packagers also don't want to have it ;-)
(Yes, you'll probably miss some data because of this. But you'll also
miss several complaints about not respecting privacy.)


Quality & maintenance
Without a strong connection between packages and bugs, it is nearly
impossible to get quality and security metrics for packages.
Therefore, I strongly recommend to integrate a possibility to assign
a bug to a package, like all other major distributions do in
Novell's Bugzilla.

Agreed - a strong connection to bugzilla would be very helpful.

On the other hand, the build service team should consider creating
an own bug tracker because it may not be desirable to have all bugs
for all packages from the openSUSE build service within Novell's bug
tracking system. The preferred way would probably be an own bug
tracking system for each build service project.

I only see disadvantages when using separate bug trackers:
- searching for bugs is more complicated (you have to search multiple
places if a package is also in the distribution)
- it's difficult to make a bug in a buildservice package a bug in the
distribution (and the other way round) - you'll need to copy&paste
everything to another bugtracker.
- and, BTW, I don't see why it would do any harm to b.n.c if all bugs go
there ;-)

My proposal:
- create a product "build service packages" on bugzilla.novell.com
(optional: split home:* to a separate product)
- automatically create a component for each project in the build
service, with the configured bugowner as default assignee and QA
contact
- let the "report a bug" link preselect the component (aka project) and
pre-populate the description with package name and version
- if a package has a different bugowner than the project, I propose to
set the assignee to the package bug owner and QA to the project bug
owner
- oh, and please make sure the bugzilla team finally fixes bug 374374
(non-public, short summary: user lookup is disabled for community
members :-( )


Regards,

Christian Boltz
--
Come on, just change ftp to ftp4 and go on.
1000 OpenSUSE users more or less a day really is peanuts. ;-))
[Eberhard Moenkeberg in opensuse]
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References