I have removed them from candidates list for now.
Well I just meant that maybe we should think a bit about which packages we want to be in contrib :)
I think that, indeed, starting with the smaller things that are missing in Factory is a good idea. They're usually not very invasive, and easier to package.
Well, I put dynagen and dynamips as second-class packages. To be reviewed later.
Ideally it should be both reasonably stable and have large number of packages. Specific packages are to be reviewed on case-by-case basis.
Ok. So how do we want to do those reviews ? Do we need a release management team for contrib ? (people who decide what gets in, what doesn't, which versions are OK after doing a bit of research on upstream)
It might be organizational overkill... but on the other hand, we need something to handle it, because once we start the project, we might end up with 50 or 100 requests of people who want this, and that, etc...
I believe it should be in this way: 1. mailing list for reviewing packages (we can use factory mailing list for now, later create a separate contrib mailing-list). People will request package to be integrated (either directly via mailing-list of via bugzilla), and maintainers with free-time will start testing. 2. When package is reviewed, different people can says objective reasons why not to put it in contrib. (I mean, first and foremost stability issues and such). If not reasons are found, package gets in. 3. There (hopefully) will be several packagers/maintainers in contrib team, anyone of them can put the package, if there are no objections from peers. 4. I can become leader of sorts (in cases where maintainers can't agree on some issue/package - I hope there will be only few such cases) 5. Typically, the man who knows specific topic will become tester/maintainer for that package/category. (for example, I'm strong in virtualization area, except Xen :) ) - (some people might be strong in other aspects) Is there any better idea for handling reviews?
Do we want to have a contrib-(staging|beta|unstable|experimental|testing) repository where packages have to undergo some reported tests before they end up in contrib ?
Generally I prefer to keep unstable/experimental stuff either upstream or in user's OBS, not in contrib. After it becomes stable it may become integrated. This will allow us to stay in focus. (not waste energy to maintain too many repos)
Yes, sure, but => "after it becomes stable" <= That's precisely the point. How do we decide whether a package is stable enough to go into contrib ? Through a release management team ? But maybe we need to offer a comfortable way for people to test packages before they make it into contrib, and having a staging repository is one way of doing it. (I'm just throwing ideas, I'm not saying it's necessarily _the_ way to do it)
See above.
Maybe later on we will revisit the idea, and add separation. (stable/unstable) But if anyone thinks we need unstable repository now, let discuss it.
But only for staging.
An example: - - someone requests a package of "foo" - - the release management team reviews the request, - -- has a look at upstream: - --- is the software actively developed or is it dead since 2004 ? - --- does it comply with legal ? - -- checks whether we have someone who wants to maintain that package in contrib - - the release management says "ok, let's have it in contrib" - - packager X builds RPMs of it and then, at that point.. how do we determine whether it's stable or not? I think that the next item should be "test":
See above.
- - the packages go into "contrib-testing" and is announced somewhere - - testers install the package and give it a run, reporting whether it has bugs or whether it works - - once we have a critical mass of positive reviews and no show-stopper bugs (whatever that critical mass is.. 5 positive reviews and no blockers ?), the package is moved from "contrib-testing" to "contrib"
I believe, that testing can happen in user's OBS or maintainer's OBS.
It's just an idea...
Also, it raises another question: do we want to handle contrib in a package oriented or in a distribution version oriented way ? Let me explain: when someone request "foo" to be in contrib, and it's stable and yeah, ok, it's fine to go into "contrib"... do we only package it for Factory or do we also build it for older openSUSE versions (when it's possible, let's avoid backports that require patching) ? I mean, if "foo" is stable, why not have it for 11.0 and 10.3 too ? See what I mean ?
Destribution oriented way. See Q&A: * Q: What about "backports" ? * A: Unfortunately, we cannot ensure stability & maintenance of "backports". I believe, that this will allow us to stay in focus. (not waste energy to maintain too many repos) and provide better results in the long run. "Backports" are really better to be continued to be offered by specific projects (GNOME, KDE, etc...) or by user's OBS. Again, This repository should be viewed as a community-driven extension of Factory, with all it's standards and limitations applied. (of course, if there are volunteers we can re-discuss it)
We should also at least think grossly about a process to request packages for the contrib repository (e.g. bugzilla).
Again, it's a great idea you're having there, and let's go through the process of maturing the idea (which we're starting to do now), to give it the best chances of making it a success. Hopefully with the input of many.
If we rush it out right now without thinking on how to handle things, it'll end in a dead horse, and the idea is just too good for that.
To summarize a bit: 1) who decides whether something is OK to be packaged in contrib ? See above. 2) how do we decide on sufficient stability/quality for packages to go intro contrib ? See above. 3) we need experienced packagers and/or top-notch packagers who do peer-review It would help of course. 4) we'll need even more beta-testers (which are potentially harder to find than packagers), have to think about announcements, raising interest ("marketing" ?), make it as easy as possible for testers to contribute, report whether it works or not, ... I believe marketing will come from news.opensuse.org once we start working... :)
5) do we freeze package versions or do we freeze the whole repository once it is bound to a released openSUSE version ? (if "foo" is stable and goes into contrib, do we only build it for Factory or also for already released openSUSE versions ?)
We freeze together with Factory. All packages gets frozen at the same time. Thanks, -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org