17 Aug
2008
17 Aug
'08
10:35
-----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.
> 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.
Yes, but we have to define what those "different people" are.
I don't think that using a mailing-list and having lots of people who
give their feedback. Let's take an example: dynagen. It's rather
specific (only interesting for people using Cisco/IOS), so
- - only very few people would have an opinion on it
- - only very few people would have used it in the past and can report on
its stability (and usefulness, and upstream activity, ...)
Having a team in charge has both benefits:
- - dedicated people who take action even when it's boring stuff no one
wants to do or no one has an opinion on,
- - avoids endless discussions
...and drawbacks:
- - have to find people who are ready to dedicate time to this activity
and stay committed for a while
- - having an open discussion with a potentially large number of people on
the -contrib mailing-list gives much higher chances for someone to have
used the requested software in the past, and able to comment on it
(think of the dynagen example above)
Dunno. I'm not sure whether we could draw enough interest to have 100
people subscribed+active to a -contrib list. On the other hand, it's
even more difficult to find capable people who have enough time to
dedicate to do this in a team.
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
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 ;)
> 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 ;)).
> 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.
[...lots, please check the previous posts...]
>> - - 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.
>> 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 ?
>>>> We should also at least think grossly about a process to request
>>>> packages for the contrib repository (e.g. bugzilla).
[...]
>> 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... :)
- 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)
>> 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 ?
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/7dr3NMWliFcXcRAoDYAJ4hOILjiCt4mZZsaRJyZiSzS+xDAgCeMIGG
e3BWvYnM9xcLR6qXmGIWJbE=
=usTv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-factory+help@opensuse.org