OK, we won't discuss the "why's", but it exists, and offliners won't go the way of the dodo, no matter how cheap broadband internet will be. -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, Jul 29, 2008 at 02:22:56PM +0000, Alexey Eremenko wrote:

Anyway: since openSUSE is sort of "open", I believe there should be some kind of mechanism to allow integration of new packages into the core distro.

The Wishlists in the Wiki, and now openFATE. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

In short it needs: * Source needs to be trusted (when is this the case ?) * To be packaged by a trusted packager (when is a packager trusted enough for the distro ?) * A significant interest by the users (How to messure this ? 2 loud people vs. 1000 quite people ?) * Who is able and willing to deliver maintenance updates ? (Who qualifies to deliver updates for two years ? Who can be the fallback ?)

Actaually Ubutnu has achieved them all. It has both 1 small core system, which is fully maintainable, one large repository (universe), and one large repository of problematic software (multiverse). -- -Alexey Eromenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, Jul 29, 2008 at 10:09 AM, Adrian Schröter <adrian@suse.de> wrote:

However, what is needed is IMHO a discussion and policy what the openSUSE distribution should be.

a) A relative small distribution with best possible quality, trust and maintenance

b) A as large as possible distro with the price of lower quality/trustable and more often changing content.

c) something in the middle ;)

Whatever you select, you will have a price to pay. But this is IMHO something what should be discussed on -factory or -project. Or even better, someone can come up with a proposal how a package can qualify for the distribution in future.

Some thoughts on this discussion from one end-user's perspective... Long ago I used FreeBSD heavily and one thing I very much appreciated was having "one stop shopping" for 3rd party software, i.e., there was a single project-monitored and blessed place to go to find 3rd party software (the FreeBSD ports/packages system). On the other hand, Linux always seemed to have more software available than FreeBSD.... BUT it was a lot harder to find/access, came from "random" places (e.g., searching pbone.net), and often didn't work because it wasn't well integrated, or you had to build it yourself (so no RPM database tracking), etc. The OBS is a great unifying technology that solves part of that second Linux-specific problem set: (a) I can find almost all software for SUSE in one place, http://software.opensuse.org/search (b) software on OBS is built under clean-room conditions for each distribution (c) all software is RPM packages with consistent inter-package dependencies. However, there still remains one problem with OBS: there are so many separate repositories. I don't have a problem with home:foobar projects, it's clear what they are about, and they should remain separate. However, why do I have to end up adding twenty different repositories to zypper (which dramatically slows it down by the way) just because what I want to do doesn't fit neatly into a single category? So here's my suggestion. First, keep the three "levels of trust" we have now: 1 = factory, 2 = established category projects like network:telephony, Apache, etc., 3 = home:user projects. Next, with each release of SUSE, create the normal SUSE distribution using level 1 stuff, but also create a new "3rd party distribution" containing the union of all level 2 projects, taken as a snapshot at release time. The "3rd party distribution" could be shipped as a separate set of ISO images and would also be hosted in a *single* online repository (called e.g., "openSUSE 10.3 3rdParty"). So you point zypper at e.g. standard SUSE 10.3 repository and 3rd Party 10.3 repository and you get it all. Not sure if this is the perfect model, but the general goals should be to make clear the trust level of the software you're getting while keeping the number of repositories at a minimum. So if there are basically three trust levels, then at least for the higher trust levels there should be exactly one corresponding repository. -Archie -- Archie L. Cobbs --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tuesday 29 July 2008 18:12:59 Archie Cobbs wrote:

On Tue, Jul 29, 2008 at 10:09 AM, Adrian Schröter <adrian@suse.de> wrote:

...

However, what is needed is IMHO a discussion and policy what the openSUSE distribution should be.

a) A relative small distribution with best possible quality, trust and maintenance

b) A as large as possible distro with the price of lower quality/trustable and more often changing content.

c) something in the middle ;)

Whatever you select, you will have a price to pay. But this is IMHO something what should be discussed on -factory or -project. Or even better, someone can come up with a proposal how a package can qualify for the distribution in future.

Some thoughts on this discussion from one end-user's perspective...

Long ago I used FreeBSD heavily and one thing I very much appreciated was having "one stop shopping" for 3rd party software, i.e., there was a single project-monitored and blessed place to go to find 3rd party software (the FreeBSD ports/packages system).

On the other hand, Linux always seemed to have more software available than FreeBSD.... BUT it was a lot harder to find/access, came from "random" places (e.g., searching pbone.net), and often didn't work because it wasn't well integrated, or you had to build it yourself (so no RPM database tracking), etc.

The OBS is a great unifying technology that solves part of that second Linux-specific problem set: (a) I can find almost all software for SUSE in one place, http://software.opensuse.org/search (b) software on OBS is built under clean-room conditions for each distribution (c) all software is RPM packages with consistent inter-package dependencies.

However, there still remains one problem with OBS: there are so many separate repositories. I don't have a problem with home:foobar projects, it's clear what they are about, and they should remain separate. However, why do I have to end up adding twenty different repositories to zypper (which dramatically slows it down by the way)

this should be really fixed with 11.0

just because what I want to do doesn't fit neatly into a single category?

So here's my suggestion. First, keep the three "levels of trust" we have now: 1 = factory, 2 = established category projects like network:telephony, Apache, etc., 3 = home:user projects.

Next, with each release of SUSE, create the normal SUSE distribution using level 1 stuff, but also create a new "3rd party distribution" containing the union of all level 2 projects, taken as a snapshot at release time. The "3rd party distribution" could be shipped as a separate set of ISO images and would also be hosted in a *single* online repository (called e.g., "openSUSE 10.3 3rdParty").

This would have basically two effects: 1) The repository would cause plenty of conflicts, because we allow by intention that packagers replace/update packages. It would cause a real dependency hell when installing any package in YaST. 2) everybody would be able to inject evil code to everybodys system. (you do not even need to install a specific package, you would always get the package with %post script sending your credit card credentials to someone else). So no one should ever add this repo ever, simply because it is a soo easy target that for sure plenty people will do it. Seriously, I saw often enough code in configure scripts talk with online server and sending private data that I will never install software which is not trustable to some degree (or I have reviewed myself). bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tuesday 29 July 2008 19:05:55 Archie Cobbs wrote:

On Tue, Jul 29, 2008 at 11:50 AM, Adrian Schröter <adrian@suse.de> wrote:

...

...

So here's my suggestion. First, keep the three "levels of trust" we have now: 1 = factory, 2 = established category projects like network:telephony, Apache, etc., 3 = home:user projects.

Next, with each release of SUSE, create the normal SUSE distribution using level 1 stuff, but also create a new "3rd party distribution" containing the union of all level 2 projects, taken as a snapshot at release time. The "3rd party distribution" could be shipped as a separate set of ISO images and would also be hosted in a *single* online repository (called e.g., "openSUSE 10.3 3rdParty").

This would have basically two effects:

1) The repository would cause plenty of conflicts, because we allow by intention that packagers replace/update packages. It would cause a real dependency hell when installing any package in YaST.

Yes, that is a potential problem. However, why should package X exist in two different incarnations (not just _aggregate) in two different projects (not counting home:user projects)? It seems like the conflicts are caused by a separate underlying disorganization that should be fixed and has nothing to do with how you split up repos. Maybe I'm oversimplifying things?

_aggregate is just increasing problems for a number of reasons, I do want to explain in detail this evening. It is also the concept that we allow builds of the same package, for example to change some configuration or to use newer/incompatible base libs. In this case the resulting package is also incompatible.

...

2) everybody would be able to inject evil code to everybodys system. (you do not even need to install a specific package, you would always get the package with %post script sending your credit card credentials to someone else). So no one should ever add this repo ever, simply because it is a soo easy target that for sure plenty people will do it.

Seriously, I saw often enough code in configure scripts talk with online server and sending private data that I will never install software which is not trustable to some degree (or I have reviewed myself).

So... are you saying that projects like Apache and network:telephony are not to be trusted? Then hmm, OBS just became a lot less useful to the world.

I say that they are only trusted to that degree that you trust the people with write access there and that you trust the upstream project (or trust that the packagers have reviewed the sources).

Yes I agree there must be some kind of oversight to prevent evil %post scripts. This is true of any open source project. Perhaps this is an argument for setting up OSC commit mailing lists (like SVN commit emails) for each OBS project, so other members of the project can monitor changes... ?

Hermes is aimed to do that. Will be launched this or next week. (and you can select there certain projects/packages for notifications. No one will be able to read all changes).

In any case the trust question is an important one but is also a separate one: if you can't trust Apache and network:telephony together in one repository, then you can't trust them in two repositories either. Orthogonal question.

Yes, but when you want to install package X from Apache, you need only to bother about this project and not to check if you can trust also all people and sources from network:telephony. When you say merge all home: projects blindly, it is obvious from my POV that we will either get daily attacks because it is so easy to infect plenty of systems or we need to tell everbody that never ever you should add this repo. So it becomes pointless from my POV.

So yes the trust equation needs to be figured out. But separate from that, a single unified repository would be a lot more convenient, trustworthy or not.

Seriously, I will refuse to host a repository on our servers where everybody in the world can immediate infect a large number of our users at any time. I think we would be also liable for such a setup. First of all, we wanted to discuss what are the rules for Factory packages, so this discussion is kind of off topic. secondly, lets improve the behaviour to add repos and install software. It solves a lot of problems. And makes actually also the package manager lots faster when you add only a number of small repos instead of one large monster repo. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tuesday 29 July 2008 20:16:08 Archie Cobbs wrote:

On Tue, Jul 29, 2008 at 12:35 PM, Adrian Schröter <adrian@suse.de> wrote:

...

It is also the concept that we allow builds of the same package, for example to change some configuration or to use newer/incompatible base libs. In this case the resulting package is also incompatible.

I think the worth of doing this is debatable. I would rather have a system where "alternative" builds of the same project had different names, or something like that.

Here is my point of view as a user: I know for example there are a zillion ways to configure asterisk. But I usually just want the "standard" version of it. I don't want to be forced to choose among a bunch of them.

Not allowing clone builds would mean * Not allowing KDE 4.0 and KDE 4.1 Beta/RC builds for example * Not allowing offering packages with bugfixes, which needs testing before submission. * Not allowing test builds with changes of below packages (libs, compiler, ..) Enforcing a rename would not be praticable, time consuming and you would be able to test in the same setup. In short it would reduce the value of OBS a lot.

...

When you say merge all home: projects blindly, it is obvious from my POV that we will either get daily attacks because it is so easy to infect plenty of systems or we need to tell everbody that never ever you should add this repo. So it becomes pointless from my POV.

Just to be clear, I did NOT say we should include home:user projects. Only the "official" projects such as Apache and network:telephony, etc.

The home:user projects live on "level 3" trust (basically not much) and I agree that including them would mean basically you can't trust anything.

Okay, but it is not much different in none-home: projects. Of course we can enforce more rules and reviews, but we would need to limit the access to them a lot. I do not like this idea. Simply think about KDE:*Desktop project (where only core developers of KDE have access) and KDE:Community (where basically everbody can get access). Both have valid use cases and we as the openSUSE project should not decide what a user wants add to his system. However, there will be a feature in 11.1 in OBS what you will hopefully like, the support of nu file. With these files you can add and remove multiple repos at once to YaST/zypper. The client will handle it as one repo. And everybody can create the list of repos he like in these files without the need to double builds and server space because of it :) anyway, all this is not really new stuff and does not help to decide how Factory should look alike :) -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, 29 Jul 2008, Adrian Schröter wrote:

However, there will be a feature in 11.1 in OBS what you will hopefully like, the support of nu file. With these files you can add and remove multiple repos at once to YaST/zypper. The client will handle it as one repo. And everybody can create the list of repos he like in these files without the need to double builds and server space because of it :)

Could you explain that in deeper detail? Ciao -- http://www.dstoecker.eu/ (PGP key available)

On Tue, 29 Jul 2008, Adrian Schröter wrote:

* A significant interest by the users (How to messure this ? 2 loud people vs. 1000 quite people ?)

Get the download statistics back to work. These are an independend measuring instrument, which can be used exactly for this.

* Who is able and willing to deliver maintenance updates ? (Who qualifies to deliver updates for two years ? Who can be the fallback ?)

From my point of view Novell is responsible for Factory packages, so trust and maintenance must be handled by the Novell people. The OBS packages can thus be only a base for the own package.

So it is plainly: - Download statistics suggest to integrate package x - package x is taken from OBS to Factory - review the SPEC files - check sources against upstream (are the tarballs equal?) - check upstream sources (to a certain degree) - check patches Now the depths of the checks depends on the package, the quality of the resulting RPM and also the individual trust-level of the author of the package. Also the depth of these checks for updates mainly depends of the trust-level of the package author. But this are all Novell internals. The open part of SUSE should be seperated from that. I install openSUSE on many systems and want to be sure (to a certain degree - it's open source) this is possible. Anyway I use the same method for Application:Geo. While initially everbody had write access to every package there I switched that, so that I'm the only one and the others have access to the individual packages only. From time-to-time I check all the changes happened inbetween (This does not mean I will be able to detect any dangerous modifications at all). At the end the project Application:Geo has established a security policy without the need to discuss this with anybody else. Same is true for factory - it's a pure internal problem. Ciao -- http://www.dstoecker.eu/ (PGP key available)

On Wed, 30 Jul 2008, Adrian Schröter wrote:

...

Get the download statistics back to work. These are an independend measuring instrument, which can be used exactly for this.

Sure, but what is rule ? How much downloads per time is needed to qualify ?

Run statistics over the downloads and choose accordingly. Very likely you will have some ranges then, which can be used to cluster the data into - seldom used - used frequently - often used This statistics should help to decide your above question, especially if you compare them with downloads of the distribution (thought only the relative values, not the absolute ones).

Yes, I agree 100% here. But shouldn't it be possible also that non-Novell employees can become part of distribution maintainers ? I fear that otherwise plenty of packages just get refused due to limited resources. Of course we need a definition, when someone is trustable enough for Factory maintainership.

Hmm, actually I myself take part in factory for package frozen-bubble like this: I make changes to the games: package (also get frozen-bubble bug reports of BugZilla) and when I think it is useful ask the Novell member (aehm, forgot his name) to integrate into Factory. So this boils down to 1-2 minutes work if he trusts me and lots of control if not. I'm not sure if I would like to have the rights to submit to Factory directly.

No, in factory directly only a very small group has direct write access. They review changes from submitters. But they have their groups of trusted people for certain packages. But their changes get anyway reviewed.

I didn't want to overcomplicate the description :-) So please assume in all my descriptions, that I'm aware of the 2 step process in Novell factory. Ciao -- http://www.dstoecker.eu/ (PGP key available)

On Tue, 29 Jul 2008, Marcus Meissner wrote:

On Tue, Jul 29, 2008 at 02:22:56PM +0000, Alexey Eremenko wrote:

...

Anyway: since openSUSE is sort of "open", I believe there should be some kind of mechanism to allow integration of new packages into the core distro.

The Wishlists in the Wiki, and now openFATE.

How do I get openFATE and to access it. I have been waiting for it for a long time. I did not see it mentioned in the Project meeting. Thanks, -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org