[opensuse-buildservice] how to carefully push a package
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? Is there some document that defines what should happen with BuildService´s packages in the long term? I´m asking because I get regular requests from the R community if it would be possible to include R on the Suse-CDs. Can anyone with more knowledge say anything about it? I´d be very happy to receive any hints. Regards, Detlef --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi and thx a lot for the answers!
On Fri, 24 Nov 2006 12:53:04 +0100
Henne Vogelsang
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.
Ok, it is on the wishlist and link is provided. Someone else already did that. Fine!
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.
:-) Ok , I understand the way you want to go. It looks a bit complicated to handle, if you really want to have lots of distributions. I don´t know for other packages and maintainers but I would be very glad, if there was a centralized repository for add-ons, at least as an intermediate step. So users would get their hand on OpenSuSE, install the core distribution, add a repository (or that repository is compiled into yast beforehand) and after the first login they have another 20000 packages to choose from without having to search for, like say Ubuntu Universe. That searching is where people are having problems right now. The BS nearly is such a repo, but you have to know where to look. Well, most probably you discussed such a set-up, too. I don´t think that many people are interested in providing a complete, specialized distribution, that is after doing it _once_ just "because you can", but may be I´m wrong here. Thx again for the explanation! Detlef
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@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (2)
-
Detlef Steuer -
Henne Vogelsang