Alexey Eremenko wrote:

On Sat, Aug 16, 2008 at 2:46 AM, Pascal Bleser wrote:

...

Adding more packages to Factory really doesn't make sense. Personally, I'd rather tend to think that the opposite is a much better idea: reduce..

Migrating packages from "Core" to "Extras" ? huh? This is a possibility _only after_ we will have contrib repo established and proven to work.

Just as a note: Fedora has merged Core and Extras to one single repository lately, see http://lwn.net/Articles/217038/ for example. So using that metaphor probably isn't the best way of talking about things. ;-) Robert Kaiser --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Alexey Eremenko [08-16-08 08:57]:

...

Just as a note: Fedora has merged Core and Extras to one single repository lately, see http://lwn.net/Articles/217038/ for example. So using that metaphor probably isn't the best way of talking about things. ;-)

Yes I know, but in future something similar might happen here, in openSUSE.

Then after reading your answer to Mr. Bleser, one would have to conclude that your are speaking out of both side of your mouth. You admitted or implied that you understood the opposite in your answer to his post. How will you determine that only *stable* packages are included? The stability label requires extensive texting across a wide range of hardware. These are just questions based on what I read. I am for the project if it will work as described. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, 2008-08-16 at 15:30 -0700, Randall R Schulz wrote:

On Saturday 16 August 2008 14:35, Patrick Shanahan wrote:

...

...

... The stability label requires extensive texting across a wide range of hardware.

Sounds like a job for bored teenagers. Or for boring teenagers...

As a non-bored (relatively busy and tired) teenager, the 'wide range of hardware' might be a difficult feat to accomplish for most of us ;-) -- Kevin "Yo" Dupuy - openSUSE Member Public Mail: Meet Bob Barr - Libertarian for President - http://www.BobBarr2008.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Shanahan wrote:

* Alexey Eremenko [08-16-08 08:57]:

...

...

Just as a note: Fedora has merged Core and Extras to one single repository lately, see http://lwn.net/Articles/217038/ for example. So using that metaphor probably isn't the best way of talking about things. ;-) Yes I know, but in future something similar might happen here, in openSUSE.

Then after reading your answer to Mr. Bleser, one would have to conclude that your are speaking out of both side of your mouth. You admitted or implied that you understood the opposite in your answer to his post.

How will you determine that only *stable* packages are included? The stability label requires extensive texting across a wide range of hardware.

Well let's not go to that extreme either. Stability primarily has to do with having the packages frozen before an openSUSE distro is released, have people test it and report bugs, fix the bugs. Yeah, pretty much what is happening with Factory when it goes through the alpha, beta and RC stages. The difference with other repositories is really just three things: - - feature-freeze the packages (obviously, bugfixes are allowed), don't upgrade them while the repository is in frozen state - - don't package beta versions or VC snapshots (we might end up with a few exceptions, but they should be rare, really) - - call for testers, ideally bundled in the alpha/beta/RC announcements for (Factory|next openSUSE) cheers - -- -o) Pascal Bleser /\\ 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) iD8DBQFIp27+r3NMWliFcXcRAlKrAKCGc30iMR+x18xv8lEdLCsfaPSUmQCfQe0/ Vc4uuzEALHFX2a6yF0KzpkY= =e/4B -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, Aug 17, 2008 at 2:56 AM, Pascal Bleser 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.

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. 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 See policy: http://www.opensuse.org/Contrib

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.

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) 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.

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.

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/ Thanks-in-advance, -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

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.

Well, I put dynagen and dynamips as second-class packages. To be reviewed later.

...

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. 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. 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. 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) 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?

...

...

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)

See above.

...

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

See above.

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

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 ?

Destribution 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)

...

...

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

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 ? 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... :)

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. Thanks, -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----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 
  /\\ 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

"Alexey Eremenko" writes:

[...] 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.

I suggest to create some criteria as well and publish them - that way we have a first filter. Let's then discuss it... Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Sun, Aug 17, 2008 at 1:23 PM, Martin Schlander wrote:

Søndag 17 august 2008 10:45:08 skrev Pascal Bleser:

...

Well I just meant that maybe we should think a bit about which packages we want to be in contrib :)

How about any working package that someone wants to build, or has already built in the BS? :-)

Of course following current BS policies - meaning no non-free software, no packages known to violate US patents...

And of course excluding factory duplicates.

Maybe there should also be some restrictions for packages prone to security issues - don't know how to define that in a good way though.

Generally I think we should want so many packages in contrib, that it would be easier to discuss which packages we _don't_ want there.

+1 I agree with Martin, but with one additional restriction: stability. -- -Alexey Eromenko "Technologov"

I cut the post a bit because it vas so many subjects in it. My comment here is on the stability discussion. 2008/8/17 Pascal Bleser :

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 ?

A set of checks can be made here: - does the programmer(s) of the SW consider the SW to be stable? - Is the SW stable in other mature distros? Fedore, Debian, Mandrake or Kubuntu - Is the SW maintained on a regular basis? - Is the SW programmer(s) interested in working with openSUSE? - an OBS project excists for the SW If the selected criterias (not necicarily the ones above) are met, then it should be taken in to Contrib and a set of basic tests run. The tests should focus only on packaging/distro relatet issues. The screening above should make it clear the it functionality wise is ok.

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 ?)

Regards Birger --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Aug 18, 2008 at 02:29:32PM +0200, Robert Kaiser wrote:

Birger Kollstrand wrote:

...

I cut the post a bit because it vas so many subjects in it. My comment here is on the stability discussion.

2008/8/17 Pascal Bleser:

...

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 ?

A set of checks can be made here: - does the programmer(s) of the SW consider the SW to be stable? - Is the SW stable in other mature distros? Fedore, Debian, Mandrake or Kubuntu - Is the SW maintained on a regular basis? - Is the SW programmer(s) interested in working with openSUSE? - an OBS project excists for the SW

If the selected criterias (not necicarily the ones above) are met, then it should be taken in to Contrib and a set of basic tests run. The tests should focus only on packaging/distro relatet issues. The screening above should make it clear the it functionality wise is ok.

So you would exclude things like xmms2 from the beginning? D'Oh. I so much would have liked to see openSUSE packages to try that one :(

I do not see it really excluded, but you could package it for yourself in your home: Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Andreas Jaeger wrote:

Pascal Bleser writes: We currently have two reviews: The one whether a package goes in, the other whether an update to a package is ok. The question is whether we want both of these reviews, or whether we have only an initial review and then the maintainer of the package is allowed to update is until we freeze the repository...

Freeze = release of openSUSE X.Y? I think we need both reviews, otherwise I fear that there won't be any way to "gradually" freeze the repository: stop major changes at some point in time (first beta release of openSUSE X.Y?) and really freeze when openSUSE X.Y releases. I think I like the idea coolo (?) had - create source links to maintainer's home: projects initially and replace them with copies at some point in time, so that all further changes go through a review (a compromise based on the assumption that a review of every change every time is impossible). Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 18 August 2008 03:10:50 pm Alexey Eremenko wrote:

I don't understand, why link? why not copy ?

IMHO, it is just to use system efficiently and lower number of tasks that maintainer has to think about. Package already exist in maintainer home and every change is available instantly if it is linked. No extra work, CPU time and hard disk space to update copy in Contrib repo, and no way to forget to update copy. When repo is frozen, create copy to prevent accidental change. -- Regards, Rajko http://en.opensuse.org/Portal needs helpful hands. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Alexey Eremenko wrote:

Marek: +1

...

I like the idea coolo (?) had - create source links to maintainer's home: projects initially and replace them with copies at some point in

I don't understand, why link? why not copy ?

For easier updates by large base of maintainers, without the need for official commit requests?

Yes, because I think that with a non-trivial amount of actively maintained packages, it's not doable to do proper reviews anyway during the alpha phase. I think it's more efficient to let the maintainers do what they want, at some point (first beta or so) replace links with copies, delete built rpms, review what's in the repository and force further changes to do through submit requests. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, 19 Aug 2008, Andreas Jaeger wrote:

Michal Marek writes:

...

Andreas Jaeger wrote:

...

Pascal Bleser writes: We currently have two reviews: The one whether a package goes in, the other whether an update to a package is ok. The question is whether we want both of these reviews, or whether we have only an initial review and then the maintainer of the package is allowed to update is until we freeze the repository...

Freeze = release of openSUSE X.Y? I think we need both reviews,

Yes, that's what I meant with freeze.

First of all (I didn't see this mentioned yet) I think Contrib should be versioned (thus, become openSUSE_11.1:/Contrib at the point openSUSE_11.1 branches). It as well makes sense to stage Contrib (I would like this for Factory, too, but it's probably easiest to try with Contrib first). If you are familiar with the Debian way then you know there is the unstable and the testing repositories. So there should be something like Contrib:/Unstable (feel free to pick a more suitable name) where a new package (version) should reside for some time before it is migrated to the main Contrib repository. Criterias ideally would be "zero bugs of severity greater than normal" - but of course this would require proper bugzilla integration (or completely manual migration). Staging Contrib helps getting more peer review and avoids breaking Contrib itself. At the point the next openSUSE is freezed development can continue in the unstable branch but only critical fixes are migrated to Contrib. Versioning Contrib of course immediately asks for an official "Backports" repository with the latest-and-greatest for older openSUSE releases. But I strongly suggest to _not_ make Contrib this Backports itself. Richard. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Dienstag 19 August 2008 schrieb Alexey Eremenko:

For now: Richard and Yaloki asked for contrib-unstable branch. Let's discuss it. What is the advantage of contrib-unstable over users OBS anyway ?

I think this lowers the number of people testing it even more. And home:* is the unstable branch of contrib in the general case, so I see little use of it. And after all, it's only developed against Factory and Factory alone has not enough users to split it. So I'm pretty much against that suggestion. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

So I'm pretty much against that suggestion.

Me too, at least for now.

Because I don't see advantages, but maintaining another repo/branch requires man-power, I don't like it very much. (for now) I'm neutral on that, with a small bit of opposition. -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Mittwoch 20 August 2008 schrieb Pascal Bleser:

It is not meant to be used by people who want "that package", because it'll definitely be removed from "Contrib-testing" at some point: either when it's stable enough for "Contrib-stable", or when it's deemed not good enough for "Contrib-stable" (not actively developed/supported, too buggy, foreporting nightmare, side-effects, ...).

Does that cast another light on "Contrib-testing" in your eyes or are you still opposed to it ?

But then you would need everyone to be able to write to that repo, that sounds uglier than a wiki page to me. But I understand your proposal now - and I think it's different to what Richard proposed. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 20 August 2008 03:22:25 am Richard Guenther wrote:

On Wed, 20 Aug 2008, Stephan Kulow wrote:

...

Am Mittwoch 20 August 2008 schrieb Pascal Bleser:

...

It is not meant to be used by people who want "that package", because it'll definitely be removed from "Contrib-testing" at some point: either when it's stable enough for "Contrib-stable", or when it's deemed not good enough for "Contrib-stable" (not actively developed/supported, too buggy, foreporting nightmare, side-effects, ...).

Does that cast another light on "Contrib-testing" in your eyes or are you still opposed to it ?

But then you would need everyone to be able to write to that repo, that sounds uglier than a wiki page to me.

But I understand your proposal now - and I think it's different to what Richard proposed.

No, besides the name the proposals are the same. Contrib/unstable should be a staging area. (Much like we have this extra patches repository where patches are put early)

Is it possible to keep naming consistent with other names in opensuse. Contrib : Third party contributions, not part of official distro, but following distro development and release cycle, so: Contrib/11.0 Contrib/Factory Testing area will be Contrib/Factory, and the rest frozen after the release. Is there something that I miss in discussion? Do we look for the naming that is closer to common language (testing vs. factory). -- Regards, Rajko http://en.opensuse.org/Portal needs helpful hands. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Kulow wrote:

Am Mittwoch 20 August 2008 schrieb Pascal Bleser:

...

It is not meant to be used by people who want "that package", because it'll definitely be removed from "Contrib-testing" at some point: either when it's stable enough for "Contrib-stable", or when it's deemed not good enough for "Contrib-stable" (not actively developed/supported, too buggy, foreporting nightmare, side-effects, ...).

Does that cast another light on "Contrib-testing" in your eyes or are you still opposed to it ?

But then you would need everyone to be able to write to that repo, that sounds uglier than a wiki page to me.

Not everyone, only the "maintainers" (or "reviewers" ?) of "Contrib-testing" may do that. Example: - - you package newsbeuter in your home:coolo - - someone proposes it as a candidate for Contrib - - I review the package, check upstream health, check the license, dependencies, etc.. well.. a review - - the package is fine, it's MIT/X license, has good upstream development, several contributors, frequent releases, upstream seems responsive to patches and emails, doesn't require upgrades of library packages, etc.. => OK - - I linkpac or copypac (not sure we agreed on this already) home:coolo/newsbeuter to Contrib:testing/ Volunteers can then pick up newsbeuter from Contrib:testing and test it, send reviews (email or bugzilla, undecided atm). If it doesn't have blocker bugs we can't fix, after receiving, say, 10 OK reports from testers, I move it from Contrib:testing to Contrib:stable cheers - -- -o) Pascal Bleser /\\ 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) iD8DBQFIrQ0Br3NMWliFcXcRAnjMAKCuGzyl0Cv1gjh1HxVuMK9HnwHFygCfdjXx zJYiaqhAaqmiRNo61ynHUdE= =5R0j -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 20 August 2008, Richard Guenther wrote:

I think it _increases_ the number of people testing compared to the number of people testing home:*. I see contrib-unstable as a way

I agree that the diversificatio of home:* is a bad thing. For most bigger parts of the distro (desktops, X11, apache, various other servers) etc there are however "themed" repositores that you can add and you get a whole stack of new packages to test. Isn't that almost the same? So is the request just merely asking for an "utils:misc:" repository? Greetings, Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Marek schrieb:

Dirk Mueller wrote:

...

I agree that the diversificatio of home:* is a bad thing. For most bigger parts of the distro (desktops, X11, apache, various other servers) etc there are however "themed" repositores that you can add and you get a whole stack of new packages to test.

Isn't that almost the same? So is the request just merely asking for an "utils:misc:" repository?

Yes and no. "Themed" repositories are often not just add-ons, but update packages in the distro. For instance, by adding the Apache repository to install GeoIP, I also get a newer apache and libapr (OK, apache is probably not a good example, but let's assume that I want the apache I got with the distro). OTOH the Contrib repository should only contain _additional_ packages, so that it can be added as an installation source without having to worry about possible conflicts. If we take Apache as an example, if Peter wants, he could request adding GeoIP to Contrib and link/aggregate it to Apache (*). Then users only interested in GeoIP and not the newest apache could install it from Contrib.

(*) actually, GeoIP sources are in devel:libraries:c_c++, but there you get a newer (lib)curl as a bonus, so the problem is the same...

Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

To get around this problem all we have to do is give the OSS and non-oss repos as well as update higher priorities in the respective package managers (at least if geoIP does not explicitly has the apache from the same repo as a requirement). There is no need to reorganize the whole Repo system for this reason. Felix -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIrT+daQ44ga2xxAoRAu/tAJ0RnAY62KViFiALwTpiXsE8RwvZ+gCcDInd 6eqsO4bL0ZhtTqTng7e+VEE= =0UiJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 21 August 2008, Michal Marek wrote:

Contrib is specifically NOT going to provide backports, but rather serve as an extension to Factory.

There is use for both: "Themed" projects, providing latest and greatest packages for a wide range of distributions, "Contrib", as an extension to Factory and 11.1,2,3... in the future, providing add-ons only, and not updating after the distro is released.

I understand the difference now. I am not sure however that it needs a solution in the OBS. The package manager could for example highlight that a certain repository wants to upgrade a "lib*" package that is also required by other packages not provided by the same repository, so that inconsistencies could happen. Another solution would be to provide a "addon:" toplevel namespacet that must not replace any non-leaf package of a distro. I'm not sure if it is worth it, often enough it is quite painful to keep current packages compiling if you're not allowed to upgrade libraries the package depends on. Greetings, Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, 2008-08-17 at 04:06 +0200, Alexey Eremenko wrote:

On Sun, Aug 17, 2008 at 2:56 AM, Pascal Bleser 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.

Not sure why you removed them but... After all, they are "candidates".

...

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.

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

See policy: http://www.opensuse.org/Contrib

I don't think the policy has been established though? If not, it'd be really good if you could say that this is "your opinion", instead of trying to make it a policy by pointing to a page that will change the further we get.

...

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.

I want to see every app ever written being in this repo, BUT, we also have to think about the size of repodata. Will we just continue adding packaging to this repo without thinking of that? Is there a plan on how to tackle this?

Specific packages are to be reviewed on case-by-case basis.

By whom?

...

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)

Sure, but how will you get people to test "unstable"/"experimental" packages if they stay in someones home?

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.

I'd love to see this happen, but I have no idea on how to realize it :-/

...

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.

Bugzilla sounds like the way to go for this.

...

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/

It's "created", not done. Alexey, I love that you started to talk about this, and I hope it is a language issue when you reply like this (see above regarding the "Policy established" as well)

Thanks-in-advance,

Cheers, Magnus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org