-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexey Eremenko wrote:
On Sun, Aug 17, 2008 at 2:56 AM, Pascal Bleser <pascal.bleser@opensuse.org> 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)
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@opensuse.org> /\\ 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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org