Mailinglist Archive: opensuse-factory (475 mails)

["Alexey Eremenko" <al4321@xxxxxxxxx>]

> > 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx