Mailinglist Archive: opensuse-factory (475 mails)

< Previous Next >
Re: [opensuse-factory] Contrib repository
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxxxxx>
  • Date: Sun, 17 Aug 2008 10:45:08 +0200
  • Message-id: <48A7E514.6010702@xxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexey Eremenko wrote:
On Sun, Aug 17, 2008 at 2:56 AM, Pascal Bleser
<pascal.bleser@xxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Posting from Alexey's "Requesting to create a top level project
"Contrib"" post:

Pascal Bleser wrote:
Either you want a coordinated effort with several contributors or you
just rush something badly thought out on your own.
If you want the former, then we're not done discussing it.
For example, I have some doubts about your list of candidates on the
wiki page [1]. To be more specific, dynagen/dynamips? Who the hell cares
about those ? You and 5 other people ? Does that make it a good
candidate for being in the contrib repository ? (playing devil's
advocate here)

[1]http://en.opensuse.org/Contrib/packages

Well, those 2 specific packages are needed by me, but I agree, that
those may be poor candidates, at least for first stage.

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.

As I replied in your above mentioned post, if you/we want this to be a
coordinated effort of several and not a one-man-show of Alexey,
- - we need a sufficient number of good packagers, not just 2 or 3
- - we need to think about, discuss, define the release cycle (freezing,
announcing, etc...)
- - the list of candidates shouldn't be "what Alexey needs right now"

Everyone is free to add candidate packages to the list.

Yes, of course. And we can keep all the packages you've put on that
list. Maybe my statement above was a bit harsh: what I actually mean is:
before we start creating the repository and packaging stuff in there, we
should think about a longer list of candidates, and what sort of stuff
we want in the repository (as I wrote above).

About release cycle:
"Contrib" will be in sync with Factory release cycles. It will
BETA-test during openSUSE 11.1 BETA cycle, together with it

Yes, that's one way of doing it, and it sounds like a good plan -- at
least it does to you and me. But maybe someone else sees a problem with
doing that, and has a better idea.

e.g.: what do we think is an appropriate size for the repository to be ?
- - just shove anything into it and possibly end up with a huge repository;
- - keep it small and well tested
?
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...

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)

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":

- - 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"

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 ?

We should also at least think grossly about a process to request
packages for the contrib repository (e.g. bugzilla).

Yes, bugzilla integration is very important indeed.
I have added that this topic is to be discussed to the project's home page
wiki.

Ok, great :)

I'm really not a process type of guy, but a bare minimum should be
written down on the wiki before we start, and if we want people
(packagers and testers) to join the effort, they have to know exactly
what they (are going to|would) participate in.

Yes, wiki page is the first thing, that is done.
http://en.opensuse.org/Contrib/

Alexey, don't get me wrong, I'm not trying to kill the idea :)
I think it's an excellent initiative, but I also think that we really
have to think it out before we do it. I'm not trying to find reasons not
to do it, I'm mostly raising questions, issues and throwing random ideas
on how to solve them. And trying to gather input/ideas/blockers from
several people, not just you and me :)

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 ?
2) how do we decide on sufficient stability/quality for packages to go
intro contrib ?
3) we need experienced packagers and/or top-notch packagers who do
peer-review
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, ...
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 ?)

cheers
- --
-o) Pascal Bleser <pascal.bleser@xxxxxxxxxxxx>
/\\ http://opensuse.org -- I took the green pill
_\_v FOSDEM::23+24 Feb 2008, Brussels, http://fosdem.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFIp+UUr3NMWliFcXcRAnFJAJ9dwJ/tpMdPCpP3KHjccx1TysQ66QCgqfvr
EX1cNdlRdoGPWux6YdL8rZk=
=jpU3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >