Mailinglist Archive: opensuse-factory (475 mails)
|< Previous||Next >|
Re: [opensuse-factory] Contrib repository
- From: "Alexey Eremenko" <al4321@xxxxxxxxx>
- Date: Sun, 17 Aug 2008 12:43:49 +0300
- Message-id: <7fac565a0808170243k374558a7vbddfce2049a50e32@xxxxxxxxxxxxxx>
Well, I put dynagen and dynamips as second-class packages. To be reviewed later.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
Ideally it should be both reasonably stable and have large number of
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
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
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
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?
See above.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
This will allow us to stay in focus. (not waste energy to maintain too
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
See above.Maybe later on we will revisit the idea, and add separation.
But if anyone thinks we need unstable repository now, let discuss it.
But only for staging.
- - 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
- - 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":
- - the packages go into "contrib-testing" and is announced somewhereI believe, that testing can happen in user's OBS or maintainer's OBS.
- - 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"
It's just an idea...Destribution oriented way.
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 ?
* 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)
See above.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
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 ?
2) how do we decide on sufficient stability/quality for packages to goSee above.
intro contrib ?
3) we need experienced packagers and/or top-notch packagers who doIt would help of course.
4) we'll need even more beta-testers (which are potentially harder toI believe marketing will come from news.opensuse.org once we start
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, ...
5) do we freeze package versions or do we freeze the whole repositoryWe freeze together with Factory. All packages gets frozen at the same time.
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 ?)
-Alexey Eromenko "Technologov"
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
|< Previous||Next >|