On Sun, Aug 17, 2008 at 1:35 PM, Pascal Bleser <pascal.bleser@opensuse.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexey Eremenko wrote: [...]
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.
A specific mailing-list could be an idea. Or bugzilla. Both have their issues: - - a mailing-list requires subscribing - - bugzilla is just a pain in the ... to use
Both are equally well suited (or not) to discuss whether a package is OK or not. We should at least be transparent for reasons not to include a requested package into contrib.
But we must decide for one way, and have only one.
Both ways should be available, just like for Factory. Bugzilla is preferred for requesting packages, while mailing-list will be used more for discussion. But it's possible to have a discussion in bugzilla as well as requests in mailing-lists.
Maybe we should go for a combination: - - use a mailing-list to discuss candidates, everyone can contribute, with opinions, with testing it (before it's in contrib), or because they've already used it and know whether it's useful, well maintained, stable (or not) - - have a team with 3 people who decides in case of conflicts or lack of feedback
Any people, including guests and strangers can express opinions and discuss problems. But few maintainers (uneven number) gives final decision, based upon all people's discussions. That sounds good enough.
That solution would mean using a mailing-list instead of bugzilla. Not that bugzilla is more structured, and that a mailing-list could tend to be used for somewhat off-topic discussions that belong on other lists, such as -factory, -project, -marketing. I guess we can't have it both ways.
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.
Sure, but that also needs coordination. We need some "ok, I'll take it, objections ?" -- no objections, he does it, or "I'm maintaining a similar package, lemme do this", etc... => mailing-list
"in contrib team" -- seems we agree on having some sort of release management team ;)
Basically if no problems are found in a package, it should get in.
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)
Not a one man show, please. We need a team of 3, because more is overkill, 1 is a dictatorship, and 2 is an even number (which sucks when it comes to voting ;)).
OK, a team of uneven number of maintainers (3 or 5 are good).
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?
That won't work, we can't have dedicated testers for each package, because we'll have 70% of packages where we won't find a dedicated person. We should really resort to volunteers doing tests here and there, the same way it works for beta-testing the distribution.
Which means - - properly announcing candidates for testing - - have a clear and unique way of reporting problems and success (even if it's just a post on a mailing-list, but it has to be documented) - - make it as easy as possible for people to test it
... which is why I still think that having a "contrib-testing" repository is a good idea. At least it makes it really easy for people to install the packages, and test them.
The key factor to success here is really to make it easy to contribute, including for people who are just interested in helping here and there, occasionally, because they're interested in a specific package/domain or because they only have little time to contribute.
Anything else will fail, really, I'm quite sure of that.
OK, all users will be able to discuss packages on mailing-list and request new ones in bugzilla. Is this "easy-to-contribute" or you mean something else?
- - 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.
Mmmmm... myeah, it could. But then we'll end up with candidates in many different repositories. And maintainer's OBS repositories that also include other packages.
Having a single contrib-testing repository is like a queue of candidates to pick TODOs from.
OK, if you think that "contrib-testing" (I prefer to call it "contrib-unstable") is better than user's OBS, then it's a possibility. I'm not against it, but I don't see much advantage here over user's OBS. We can do it, if you believe it is better.
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 ?
Distribution 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)
I hope I'm misunderstanding here. Are we discussing this or did you decide that it's decided ?
It's not decided, but discussed.
I believe marketing will come from news.opensuse.org once we start working... :)
- From my experience, that's a slightly bit naive :)
Getting people to contribute is always a lot of work. It means - - discuss it thoroughly before launching it, gather feedback, ideas, opinions of many people, not just 2 or 3 - - clear processes: where to request candidates, what are the conditions to be accepted, how to test, how to report success, how to report issues, how many reports before it gets promoted to the stable repository, why are packages there frozen, etc... - - documentation, lots of documentation (especially on the processes) - - make it easy and low effort for anyone to contribute occasionally - - blogging about it, announce it on mailing-lists and forums, on news.o.o, etc... (but that's the easy part)
So you want to be a marketer ? Documentation (at first) will come in a wiki.
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.
Let me take an example. Imagine we have a frozen Contrib for 11.1. Then someone requests "foo" to be added in Contrib. Review (license is OK, legal is OK, it's actively maintained), gets successful test reviews, all fine, we add it to Contrib/Factory.
1) do we keep on upgrading it until Contrib/Factory is frozen (as it is done in Factory), which means re-testing it ?
2) do we also publish it into the Contrib/11.1 repository, given it is a new package that wasn't in Contrib before ?
After openSUSE enters BETA-stage only critical bugfixes/security fixes are allowed. "contrib" will be frozen. It could be like that: openSUSE 11.1 BETA stage - "contrib-11.1" = frozen, only critical bug fixes allowed (for existing packages). No new packages. After release of 11.1 it will become unfrozen again, together with Factory. Once Factory splits into new tree (->11.1) same must happen with contrib. Obviously we have just one month before BETA. Now if we will have "contrib-unstable", then this need not follow factory, because it is unstable by default. (here rules could be lessened to some extent) -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org