Mailinglist Archive: opensuse-factory (475 mails)

["Alexey Eremenko" <al4321@xxxxxxxxx>]

On Sun, Aug 17, 2008 at 1:35 PM, Pascal Bleser
<pascal.bleser@xxxxxxxxxxxx> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx