Mailinglist Archive: opensuse-buildservice (253 mails)

< Previous Next >
Re: [opensuse-buildservice] how to carefully push a package
  • From: Henne Vogelsang <hvogel@xxxxxxxxxxxx>
  • Date: Fri, 24 Nov 2006 12:53:04 +0100
  • Message-id: <20061124115304.GA20770@xxxxxxx>
Hi,

On Thursday, November 09, 2006 at 16:29:14, Detlef Steuer wrote:

> into inclusion in the main distribution? Are there defined milestones
> a packages must pass? (Besides a clean build, of course.) What are
> showstoppers?
>
> Is there a predefined way to work a package`s way up into OpenSuse?
> Or does the intention to include packages from BS into OpenSuse even
> exist?

Up till now there is no defined way to include packages from the
buildservice into the distribution. The way to go is to enter the
project into the wishlist on the wiki and provide a link to the
buildservice project. We will then pick the package up and work with the
BS maintainers for inclusion.

But we thought about this a lot. The goal is to make this process as
comprehensible, objective, scalable and living as possible. Here is the
"plan" we have how we would like to do this:

Package Attributes
------------------
Each package has N attributes. There are different kinds of attributes.
Bolean (yes/no), Alternative (a, b, c,), Score (0-10) and so on.

Examples:
popularity=8
osi_approved=yes
upstream_active=no
novell_maintained=yes
only_package_that_provides_this_functionality=yes
stability=experimental
classification=addon
maintenance=moderate
bugs=7
security_updates=0

Input Providers
---------------
Each Attribute has an input provider. Input providers can be all kind of
things.

Examples:
humans:
o maintainer
o author
o user
o legal
o and so on
programms:
o download.o.o
o YaST
o License Digger
o Wishlist (Fate)
o bugzilla
o vote tool
o and so on

Attribute aggregation
---------------------
A distribution is an attribute aggregation. Think of it as a rule sheet.
Set by the distributions project manager. In case of openSUSE this would
be AJ. In case of Steuerlinux powered by openSUSE this would be you.

Example:
if classification equals core then
stability needs to be rocksolid or
only_package_that_provides_this_functionality needs to
be yes
novell_maintained needs to be yes
if stability equals experimental then
bugs need to be less than 15 and
security_updates need to be less than 4
if only_package_that_provides_this_functionality equals no then
popularity needs to be more than 6
if name equals glibc then
project needs to be novell:glibc

It is a long way to go before we can make this happen but we are working
on it. The thing is, it is already working like this. Kind of. Just
without the attributes, input providers and rules sets expressed
somewhere. It all happens in some inter-human conversation or in
someones head.

The next step will be to solidify attributes, input providers and a rule
sheet from the existing distribution. Once we have that first set, we can
extend and particularize it.

Henne

--
Henne Vogelsang, Core Services
"Rules change. The Game remains the same."
- Omar (The Wire)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References