On Monday 05 September 2005 11:21, houghi wrote:

What links are there         |________________ RPM -> Use that         |         |________________ rpm.src -> Use that

I am hope that rpms which don't follow SUSE policies are no option. SUSE always standed for high quality. I don't expect Novell to change this. Thus there MUST be some QA process before (of course afterwards too) any package is added at all. Don't just grab random crap and add it. SPECS need to be reviewed before they are added, packages need to be tested, it must be ensured that even with add-on packages updates to newer SUSE Linux versions are possible, it should be ensured that someone is willing to maintain the package and updates it if a security issue is found, etc. Otherwise you end up like Ubuntu's universe with a big number of packages but not enough maintainers, a lot of broken packages, no security support, etc. We don't want this, do we? Cheers, Andreas

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Simon wrote:

On Monday 05 September 2005 08:32, Andreas Girardet wrote: ... This is a great initiative. Two points I can't find on the wiki page. Bug-tracking system. I think it's important to have a bug-tracking system up for contributed packages. Probably we don't need to discuss the advantages of that.

Would definately be a requirement. There must be a convenient way to report issues with every package. But... not that easy to implement.

Review. I suppose many people whould not be comfortable with the prospect that packages from random people are committed without any review process. Quality is important. Thus I would like to see a group of people, people who have shown to have competence and commitment to review packages before they are commited. This is a good way to hold up a minimum of quality, ensure that SUSE's packaging policies are followed, etc. I see quality here more imporant than the number of rpms.

Exactly. I've already said (and AFAICR it's on the wiki) that not "everyone" should be able to commit packages in there. Or if they do, they must be reviewed by experienced packagers before being available for download. But review is not enough, as unmaintained packages are a pain as well. People who contribute RPMs must understand that; - - they must follow a common style guide - - they become the maintainer for that package and must commit to keeping it up to date and applying bugfixes

People should also do some investigation to ensure that the packages are free of legal issues (at least as far as a non-lawyer can tell) and known security issues before the packages land on the servers. Packages with known security issues should not be commited at all until a patch is made (or maybe put into some seperate repository with a big red warning).

Yep, legal issues are important as well.

Something else. The wiki page asks about how to integrate packman. Will this be possible at all? Packman contains packages which are illegal in a lot of countries. If this project want's to stay under the umbrella of openSUSE such packages are surely out of this game (think of copy-protection circumvention, and unlicensed media codecs). Maybe it would be a good idea to have a single repository for this kind of packages outside of the openSUSE project.

Packman will remain Packman. Guys, step back a bit and first spend some time thinking about all this. I've been maintaining RPMs for quite a while (I run the suser-guru repository), I'm part of Packman and I've had long prospective discussions with Dag Wieers of RPMforge. There have already been a lot of ideas, most of those points discussed, but not much has happened up to now, mostly because all of this requires a /lot/ of work. This is *really* complex to set up, there are a lot of things to think about, policies to define, rules to be followed, technical infrastructure to be set up. It's great to have the momentum, the will to make something happen, but it will need some time and long discussions to properly set that up. So don't get rushed into something not feasible or which is already broken by design. There are a number of people who are really experienced with all of this (yes, I humbly include myself ;)) and, believe me, it's much more complex than what most of you think. Nevertheless, we should keep on collecting and discussing ideas as well as potential issues.

From the wiki: "Packages should be allowed from any source regardless of the packagers seniority or trust level." Are you serious? People should install random software on their systems? Trust is important here. If the first packages arrive which break user systems, delete their data, install backdoors, etc. openSUSE will suffer from it. I too think everyone should be able to contribute packages, including people who have not yet much practise with rpm (I for example am just learning how to do them), etc. But those packages should be reviewed by more expierinces and trusted people before they land in the repositores.

Yep, I agree 100%. I've seen a lot of ugly packages already (installing into /usr/local, no dependency information, no init scripts, no desktop files, ...) and those just don't help *anyone*. It's also more difficult than you think to find people who are committed /into time/, not just baking a single RPM and submitting it somewhere. Packages need maintainers. Some might start to think "oh boy, not the same thing as Debian or Fedora, all they are doing is broken". Well.. Debian's packaging is working very well: - - they have dedicated maintainers - - they have strong policies (maybe a bit too paranoid, I agree) - - they have very interesting build tools (e.g. for unattended builds) Fedora also has rather well-defined policies for their package(r)s. I don't agree with some parts of it, I even think some of their decisions are plain broken, but nevertheless. Quality is definately the most important aspect, much more important than quantity. And to me, quality is: - - having dedicated maintainers that update their packages when new releases come out, when bugfixes are needed - - having experienced packagers, who know their distro, who know how to integrate it well into SUSE - - having clearly defined policies and style guides (Novell/SUSE already have some [1], but they are incomplete to me, at lease for our purpose, but must serve as a base) - - for new packagers that join in or for new package submissions: reviews by experienced packagers, cross-signing of packages [1] http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.htm... Believe me, if we don't put it up like that, it's never going to work. Please let's discuss on that basis. How about a dedicated mailing-list ? cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHXZir3NMWliFcXcRAucQAJ9TbyX9M+R1qAxTx/0TfRsDszaOiACfQFt3 FDMNGlpDNDXFx4Z31vEWOSs= =4bNq -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:

Hi,

On Tuesday, September 06, 2005 at 12:58:43, Pascal Bleser wrote:

...

Quality is definately the most important aspect, much more important than quantity. The problem is identifying quality packages. One solution to this problem is identifying quality over quantity. Another one would be to let the whole of us decide and express our finding of quality in an easy way.

Hey, I was just giving my opinion on the subject :) And I wasn't babbling: IMHO, it's a better situation for the end-users to have a little less well-maintained packages than every single project out there but with RPMs that end up in slaughtering your system.

Im sure there are more ways to talke this problem. I myself find the "quality over quantity" approach not to good. I does not fit into my understanding of "open". And thats what we want to be. openSUSE not somepeopledecidesomenotSUSE..

Henne, who is deciding on what's going into the SUSE media or into the ISOs ? ... see ;) I don't see your point. Anyone would be invited to join in. Anyone can apply. But that involves: - - being the committed maintainer of the package - - accepting to be reviewed, at least in the beginning - - follow some guidelines on how to write the packages - - maybe also being on a central mailing-list with the other packagers C'mon, it's the same on packman: someone sends an e-mail "hi I packaged this". Would you just take his RPM and put it in the packman repository as-is, without reviewing or testing it ? And a few weeks later we get an e-mail "please update that package" or "there's a bug in that package" and the person who originally sent us the RPM (or spec) doesn't reply to our e-mails or doesn't have time to fix it. Well, if you really want to let anyone submit RPMs just by uploading them into some FTP, we would at the very least need separated repositories (stable, unstable, testing), to let users choose what harm they want to do to their system ;) Note that it's not exactly the same idea as Debian: with Debian, that "state" applies to the whole distribution. We will still have a stable SUSE distribution every 6 months, so we won't run into those issues. That stable/unstable/testing would apply to every single "3rd party" package itself. testing = not reviewed, not tested unstable = reviewed, not much tested stable = reviewed, tested by at least x people What would be nice, regarding that, is to have the possibility of letting users post their experience with the packages through some web interface. When an "unstable" package has a certain amount of positive feedback from users, it's being promoted to "stable". And "testing" packages simply get promoted to "unstable" when they have been reviewed by at least 1 or 2 experienced packagers. That's something I already discussed with RPMforge. IMHO it's a very good solution to a number of potential issues, but most probably involves writing some software for it (the web frontend for posting feedback). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHYIIr3NMWliFcXcRAgPtAJ4mDrzG9FDeTPei9zo6NaTqSCyxYwCgsJaO VbkWxtS1YPLAoryoWvP/t6Y= =eSh/ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sonja Krause-Harder wrote:
(hi Sonja, thanks for your hard work on the Java packages ;))

> On Tue, Sep 06, 2005 at 01:48:25PM +0200, Pascal Bleser wrote:
>> C'mon, it's the same on packman: someone sends an e-mail "hi I packaged this".
>> Would you just take his RPM and put it in the packman repository as-is, without reviewing or testing it ?
> What if the package was clearly marked as untested, submitted by an
> unknown, unrated, untrusted new user, and not available through
> automatic update, but only with explicit manual intervention? Would you
> still object?

See what I wrote in my latest reply to Henne:
- --->8--snip------------------
Well, if you really want to let anyone submit RPMs just by uploading them into some FTP, we would at
the very least need separated repositories (stable, unstable, testing), to let users choose what
harm they want to do to their system  ;)
Note that it's not exactly the same idea as Debian: with Debian, that "state" applies to the whole
distribution. We will still have a stable SUSE distribution every 6 months, so we won't run into
those issues. That stable/unstable/testing would apply to every single "3rd party" package itself.
testing = not reviewed, not tested
unstable = reviewed, not much tested
stable = reviewed, tested by at least x people
What would be nice, regarding that, is to have the possibility of letting users post their
experience with the packages through some web interface. When an "unstable" package has a certain
amount of positive feedback from users, it's being promoted to "stable".
And "testing" packages simply get promoted to "unstable" when they have been reviewed by at least 1
or 2 experienced packagers.
That's something I already discussed with RPMforge. IMHO it's a very good solution to a number of
potential issues, but most probably involves writing some software for it (the web frontend for
posting feedback).
- --->8--snip------------------

> Trust is an issue. But keeping everything out and only letting trusted
> packages is only one possible solution, and one that creates the
> bottlenecks you can observe in other open projects.

Being wide open is also an issue, IMHO even a lot worse one.

And I never said to "keep everything out".
I talked about reviews, cross-signing, and one option being to have different quality labels on
individual packages (stable/unstable/testing).

The latest most probably being the most interesting one.

Geez, I never said to make it a private club :)
Anyone can participate, create an account, sign in, and follow the guidelines.

> Another idea is transparency: make clear what level of trust a package
> has, what kinds of reviews were done, and make sure users know the risks
> when they download and install something. But allow everyone to use the
> build infrastructure and package distribution servers and host their
> packages there.

Sure, anyone can package anything and put it on their website ;)

> What would we need for such a model to work? 
1. define policies and quality guidelines for packages, based on what Novell/SUSE already provides:
http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html
2. set up an infrastructure for
   - bug reports
   - voting/feedback on packages to promote from unstable to stable
3. central mailing-list for all the packagers involved
4. implement support for that/those repository/ies into YaST2
...

cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\        
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDHYh1r3NMWliFcXcRAgWjAKCd3iWBS5SBCTQWjlGHo1XqzdmtbgCbByP1
1Vhca3Om8kS4VyC+KwAH8q0=
=seVo
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sonja Krause-Harder wrote:
> On Tue, Sep 06, 2005 at 02:15:50PM +0200, Pascal Bleser wrote:
...
> Having a central place to build package in clearly defined build roots
> and with the whole armada of automated package checks during and after
> build is a first step towards quality packages, don't dismiss it too
> lightly ;-)

I do. I can't see anything of that at the moment, so I cannot make assumptions about it.
And as far as the "armada of automated package checks", I believe they're not even worth a piece of
what a review by an experienced packager is.
Scripts that make sure that:
- - KDE packages are installed into /opt/kde3
- - GNOME and GTK2 packages are installed into /opt/gnome
- - configuration files are marked as %config
- - packages with daemons include init scripts
- - documentation files are marked as %doc
- - a .desktop file is included/added when appropriate

Part of it is possible, but not everything, unfortunately.

I agree that a certain number of things is possible:
- - build properly on all "supported" architectures (most specifically, x86_64)
- - the dependencies are all included and correct (**)
- - %suse_update_libdir and %suse_update_config are included when it's using autoconf
- - %suse_update_desktop_file is called when it includes a .desktop file
- - include fully-qualified paths to sources (with a few exceptions) (*)
- - correctly split into subpackages, at least when there are some files like include/*, lib*.a,
lib*.so (with a few exceptions) (*)
- - no files are installed under /usr/local
- - init scripts include an "rc"-symlink in /usr/sbin or /sbin

(*) not being done by SUSE at the moment, at least not before 10.0
(**) I have a few rants about SUSE .spec files about that but I would digress ;)

>>> What would we need for such a model to work? 
>> 1. define policies and quality guidelines for packages, based on what Novell/SUSE already provides:
>> http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html
>> 2. set up an infrastructure for
>>    - bug reports
>>    - voting/feedback on packages to promote from unstable to stable
> 
> Imagine a large pool of packages, not a distribution, and not even
> called testing. Just a kind of primordial soup of packages. Everyone can
> submit packages there.

Are you thinking of a central hosting for those packages ?
Or just information about where a package is available ?

> Now imagine you could define a larger entity, let's call it a package
> set, which you can create and be responsible for, and where you could
> collect packages that have passed your review and meet your quality
> standards. You could call it "Pascal's approved SUSE addon packages", or
> form a group of people to help you who also have the respective
> privileges for that package set. Hey, you could even create three of
> them and call them stable, unstable and testing ;-)

And where in that idea are the package maintainers ?
Personally, I don't believe in such a model if there aren't dedicated people that maintain every
single package. Having dead, unmaintained RPMs /is/ an issue.

Sonja, this is a totally different approach you're proposing there, and I really don't know how
viable that would be.
To me, what you're talking about is layered "on top" of what I'm talking about, in a sense that my
feeling is that it doesn't address a number of "low-level" issues like:
- - who's in charge of a package => keep an eye on new releases, keep an eye on security fixes,
contact person for feedback
- - how would that work with package installation front-ends like YaST2, apt, yum, if the RPM files
are not hosted where the "package set" is defined ?

Please develop some of those ideas.. are you thinking of adding that behaviour into YaST2 ?
(maybe it's just too hot, or me being stupid, or all of this being so different of the way I've been
contributing RPMs to a lot of people since quite some time that I can't picture it)

> But this would be only one package set of many, and SUSE Linux core
> would be another, and SUPER maybe yet another, with different levels of
> control and trust, and us Novell people only contolling very few of
> them. Would that meet your requirements?

I don't know. This is really too abstract at the moment.
We'd need to discuss it a lot more.

> Let's think further than the Debian model, please.

Call me small-minded, but we're not even near something as the Debian model at the moment.

Let me put this back into the current situation.

We're a very small number of "3rd party packagers" (packman, James [Ogley], a few suse-people, a few
suser-* on gwdg.de, and my site) and we're only partially talking to each other, packman definately
being the most consistent repository (as well as the largest), as it already groups a small number
of active packagers (and thanks to the hard work of Marc Schiffbauer and Eberhard Moenke, without
whom we as a SUSE community wouldn't even have that).

We're having some inconsistencies that are really problematic if you want to use all the
repositories, most notably:
- - conflicts in package names
- - conflicts with suddenly appearing SUSE packages, that are sub-packaged and named differently from
what we've been providing
- - duplicates: packages that are in more than one repository

Sonja, I'm probably not seeing the "bigger picture" like you do, but those are concerns we're
currently having, partly because we have not been much integrated or supported by SUSE up to now
(please don't take that as a rant, and I know that some devoted SUSE employees have always been easy
to contact and discuss such issues with).
And, yes, that's why there's openSUSE now, and it's great, but I'm still kind of lost on what's
really going to happen with regards to the community's packagers.

If we don't even put up something to address the 3 issues we're currently having now, how do you
want to make that very new and shiny concept (no, that's not ironic ;)) reality ?

Maybe I'm too focused on centralizing a certain number of things, because most of the problems the
Packman packagers and I have at the moment are directly related to the fact that we're all loose and
uncoupled.
And we're just a few. If I imagine all this exploding into a large number of packagers, most not
having been through what we have, I don't really see another outcome than having a large number of
RPMs all spread around, not compatible to each other, massive conflicts, possibly poor quality
packages, and all that being broken down onto the users.
(hmm.. does that sound like Fedora ? ;))

IMHO, quality and consistency has always been the major asset of SUSE Linux, and the small number of
3rd party repositories its biggest issue.
I don't think that sacrificing the first to improve the other is a good option.
But maybe that's just me. Or maybe we'll find a way to combine both.


Let's all meet at FOSDEM 2006 in Brussels, make a big openSUSE developer room and talk about all
that, and we could even have some people from Debian, Fedora, Ubuntu, Gentoo or whatever join in ;)))


cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\        
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDHaK2r3NMWliFcXcRApgAAJ9QYqQfUFmVwHxs9wtr0eG8cG1kdQCfeBca
uSeBproE+/j2LlftJWosIQA=
=ThrG
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sonja Krause-Harder wrote:

On Tue, Sep 06, 2005 at 04:07:51PM +0200, Pascal Bleser wrote:

...

...

Imagine a large pool of packages, not a distribution, and not even called testing. Just a kind of primordial soup of packages. Everyone can submit packages there. Are you thinking of a central hosting for those packages ? Or just information about where a package is available ? Central hosting, automated rebuilds when packages earlier in the dependency chain change.

Ok. So you actually mean: central hosting on opensuse.org + the current build infrastructure SUSE has (=> the build servers). Maybe a more distributed approach would be worth investigating as well. I particularely like Debian's idea of its unattended build daemon, even if it's worth improving. But like that, even people who don't have the necessary know-how to write RPMs but who would like to actively contribute can offer their hardware ressources as "build servers". They "just" need to have a daemon running, that pulls source RPMs from a queue, builds and validates it, and then submits potential issues or even the binary package back to the central repository. Obviously, this concept involves a lot of potential security issues.

...

...

Now imagine you could define a larger entity, let's call it a package set, which you can create and be responsible for, and where you could collect packages that have passed your review and meet your quality standards. You could call it "Pascal's approved SUSE addon packages", or form a group of people to help you who also have the respective privileges for that package set. Hey, you could even create three of them and call them stable, unstable and testing ;-) And where in that idea are the package maintainers ? Personally, I don't believe in such a model if there aren't dedicated people that maintain every single package. Having dead, unmaintained RPMs /is/ an issue. Of course every package has a maintainer - the person who submitted it to the system for the first time. Unmaintained packages need to be taken care of in any approach - maintainers disappear or lose interest for any reason.

See, you're coming back to the things I've put up for discussion ;) Fine, let's talk about a whole new approach, package sets or whatever we'll find out to be an interesting and realistic concept, but let's keep in mind the "low-level" issues we need to solve.

...

Sonja, this is a totally different approach you're proposing there, and I really don't know how viable that would be. That's why we're discussing, isn't it ;-) Seems so, indeed ;)

...

- - who's in charge of a package => keep an eye on new releases, keep an eye on security fixes, contact person for feedback The package maintainer. If they are not reacting, or not providing security updates, the package needs to be marked as unmaintained, or maybe even removed. That's a policy decision (and also a question that is present in any approach).

I already mentioned that extensively, as well as stressing the need for a "policy" and "guidelines". Now, what was so wrong with what I wrote in my previous mails ? ;)

...

- - how would that work with package installation front-ends like YaST2, apt, yum, if the RPM files are not hosted where the "package set" is defined ? What would the requirements be? A package set would, for example, result in its own install source you can configure YaST to use. Yes, I agree that this is the very obvious approach. Makes sense.

Different package sets would depend on others. To reuse the example, the openSUSE community approved reviewed addon set might be based on SUSE Linux core as the base distribution, but in addition contain packages which are - not in the core distribution - newer than in the core distribution - better than in core (i.e. feature-adding patches which didn't or will never make it into core SUSE Linux)

How is that so different from the current situation ? (besides enhancing YaST2 to use such "package sets" (= installation sources) with more ease) We currently have such "package sets", at least: - - packman - - suser-* - - suse-people - - my site What's so different in a "package set", compared to an "installation source" ?

We need to take care about dependencies both during build and in the installer. In the second and third group packages will override those in the core, so both the build server and YaST (or any other installer people will want to use) need to be able to handle a "layering" of package sets and the resulting install sources. Which we'll still have to implement, but fortunately we have both the build system and YaST under our control. So conflicting and duplicate packages are not necessarily a problem - it can also be a feature to have variants packages which contain, for example, experimental features, or are just newer.

Err.. well.. they /are/ a problem, unfortunately. And one I cannot see us solve by any means, unless we eventually kick the GTK and GNOME developers in the butt for not versioning their libraries properly. How would you solve: - - gimp 2.2.8 needs gtk2-2.4.0, all in stable, fine - - xchat needs gtk2-2.4.0 as well, all in stable, fine - - upgrade to gimp 2.3.0, that needs gtk2-2.8.0, provided in an unstable package set Upgrading gtk2 from 2.4.0 to 2.8.0 will break xchat, for sure (been there, seen that already). But both versions cannot be installed side-by-side, unless you do some really, really heavy patching that costs a vast number of hours of work (been there, tried that already, abandoned). I don't see how "layered package sets" would solve such issues, neither how we could build packages that solve issues that are originally flaws in the software itself (or how it installs itself). But I agree that this is the kind of problem you're also getting into with the "Debian approach". Installing gimp-2.3.0 would mean upgrading half your distribution's packages.

(Add requirement: show per-package information on the web frontend which variants exist for a package, in which package sets they are, what their dependencies and purpose are. Possibly also make this information available in YaST, though it might add more confusion than real advantages. In any case make YaST deal with multiple installation sources in a defined order of preference.)

Probably so, yes. - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v ===> FOSDEM 2006 -- February 2006 in Brussels <=== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHbcXr3NMWliFcXcRAl1SAJ0WPNQSZg9dvbBXpoLSDlpF839sAQCfc0kA gTeSTeN0rh7spLTTwr2Jzj4= =7Axy -----END PGP SIGNATURE-----

Hello team Since while I sleep you are all fantastically active and when you sleep I am awake :D ..... I thought that rather than joining into this discussion I can be more of a project secretary. But I do not make coffee ;) ..... It would not make sense for me to simple reply to many posts 12 hours after the discussion has happened ...... and I see all my ideas represented anyhow. I have edited http://www.opensuse.org/index.php/Packager and added whatever I could to several categories to start structure the discussion. 1 Packager Brainstorming 1.1 General ideas 1.2 Buildservers 1.3 Repositories 1.4 A packagers world 1.5 Users World 1.6 Packages I can already see some consensus already happening. The single diverting comment from single people is as in all statistics something that goes under and can be eliminated as statistically irrelevant further on. We have a lot of combined experience here and all really good innovative ideas. In general I would think that no idea should be discarded at this stage, since we really have to think outside the square and not just replicate what other distro's do. By simple replication we will not in any way be better or more innovative. Of course there are things that we just have to do to MHO do not restrict your brain to think that only because it has not been done before or is a lot of work something should not be done. If Linus would have thought that way, I am kind of sure we would not even have this discussion on this mailing list today. Let's rather think ideal world first and then once we assess how much resources are required to get this ideal world and how many resources we do de facto have, can we start chipping away at the goal and restrict it. After all I am convinced that if our idea (as in ideal world concept) is that good and potent other people will join and make it happen as we see every day with many great ideas. No idea is too much work unless you have already decided in your mind that you will fail. I see openSUSE and SUSE Linux 1(0) as a great chance to innovate for the sake of the entire Linux community. Let's all think this is special ..... and learn from the others, but go beyond the others. I know this is easier said than done, but we need to start somewhere. A few areas I am personally interested to hear a bit more about: - How is a webinterface for packagers and users going to look like? - How could a webinterface interface with yast? - Is rpm really the end of all package systems? What is missing? - How could a packager be helped to make his life easier? - How could we attract more maintainers of other distro's and have output compiled for us? Review the website as these are just a few points I am interested in. Regards, Andreas Girardet Consulting Architect Novell, Inc., the leading provider of information solutions http://www.novell.com openSUSE is SUPER: To help in the SUSE Performance Enhanced Release project visit http://www.opensuse.org/index.php/SUPER

{>>> On Wed, Sep 7, 2005 at 6:13 pm, in message <431E84ED.7010605@skynet.be>, pascal.bleser@skynet.be wrote:

Pascal, mon' ami, tres bien .. the reformatting is fabulous! It sure makes it very readable. :D good morning by the way ;) Andreas

...

- How could a packager be helped to make his life easier? - How could we attract more maintainers of other distro's and have output compiled for us?

One is get them to use openSUSE. Sounds stupid, I know, but I believe a lot use debian and therefore make deb. How hard is it to write correct specs for SUSE if you already have deb specs? Could a tool be made to do this for them? If yes, then all deb could be made into SUSE rpm's and the other way around as well.

Actually we have such a tool developed already in-house and I guess it is planned to deploy this. Ciao, Marcus

All this talk about who should be able to contribute aside, would anyone be willing to consider an alternative, more user-friendly (compared to RPM) packaging method for add-on applications? The way I picture this is, the core OS (kernel, shell, utilities, drivers etc. + the base desktop system) is still RPM managed and can be updated, if desired or needed, via YaST Online Update. But the add-on applications use a more user friendly, if possible less distribution and distribution version specific packaging. The reason for this is that RPMs can be difficult to install for non technical users, because they have to 1) find the correct RPM for their distro and usually as well for the specific distro version (9.2 packages won't always work on 9.3), 2) attempt to install it, 3) resolve unsatisfied dependancies (goto 1), 4) install dependancies, 5) install package. Now cleverly managed online repositories like Guru's or Packman and tools like apt4rpm alleviate many of these issues, but I wonder if something might not be done to provide more cross-distribution or at least cross-version friendly packaging method. It seems as of late two projects appeared that are worth of notice in this regard: 1. autopackage (www.autopackage.org) 2. klik (klik.atekon.de) Both of these methods shield the end-user from dependancy problem and are therefore friendlier in that way. What is the community's (and SUSE's) take on choosing such or similar methods for packaging of non-core applications in the future? I'm very much looking forward to see how the SUPER KLIK project that Andreas Girardet and the klik maintainer have set up turns out. If it goes well, maybe that's something to consider for SUSE 11? Or 12, seeing as how both autopackage and klik are still in quite early stages and are not yet mature.

On Tue, Sep 06, 2005 at 02:48:31PM +0200, Henne Vogelsang wrote:

You can even have more criteria:

- submitted for the first time - downloaded N times from download.opensuse.org - installed N times on SUSE Linux (would need some "opt in" monitoring app)

- list all reported bugs concerning this package - number of bugs submitted - number of bugs resolved - number of bugs pending - what other users think of this package - the package is 10 (high quality) .. 0 (bad quality) - comments on the package Actually you finally should not decide on such numbers whether you install a package but find out to whom packager you can trust or even to whom person can you trust if he tells you that you can trust to a specific packager. Finally there will never be a technical solution that gives you a definitive answer whether one person that looks smart is really smart or whether he is just very excellent in doing self-marketing without having any technical clue. But the fact that SourceForge is so popular shows that the concept of open contribution actually works. They host crap as well but nobody cares because everybody is free to download there what he likes and leave the other stuff alone. Nobody can tell you now definitelly how this concept works out for openSUSE but I consider trying this as being a very refreshing idea. Finally it all depends in how smart SUSE users are. We will see... And after all those statistical numbers are really funny and thus I am all for it. ;-) Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de

On Tue, Sep 06, 2005 at 04:21:17PM +0200, Henne Vogelsang wrote:

Hi,

On Tuesday, September 06, 2005 at 15:27:57, Robert Schiele wrote:

...

Actually you finally should not decide on such numbers whether you install a package but find out to whom packager you can trust or even to whom person can you trust if he tells you that you can trust to a specific packager.

Only if you want to be dead sure of course. If you want to handle that a bit more sloppy then you can just rely on the numb3rs. And numb3rs shouldnt be everything here. Like you said comments are also a very good way to check the quality. Or we bring trust-rings into play. I trust Pascal. You trust me. So you trust Pascal also.

There are so many ways to cherry pick for quality.....

Exactly. All I wanted to say here is that everybody has to decide on it's own how he or she is handling all that stuff and thus every central partition in stable/unstable or trusted/untrusted is subjective and more or less random. It is in no way of any help for me if someone set a package as "trusted" if I personally consider this person being a moron. In my opinion one of the first things that actually would be useful is that SUSE starts to be more open what their internal build infrastructure is concerned. Currently in my opinion it is unnecessarily complicated to do some things when building packages because information about SUSEs Autobuild is hidden behind the wall. I am pretty sure the better the build infrastructure is that is in public the more package are actually contributed. *hint*, *hint* ;-) If there is good infrastructure in the public and problems concerning quality _actually_ arise, the _next_ step is to find a mechanism to fix them. The current discussion seems to hunt a problem nobody knows whether it will ever exist. Again refer to SourceForge: It has a huge number of software, most of it being really useless stuff but this actually is no problem. --- At least I cannot see the problem. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de

Hi, On Tuesday, September 06, 2005 at 13:48:25, Pascal Bleser wrote:

Henne Vogelsang wrote:

...

On Tuesday, September 06, 2005 at 12:58:43, Pascal Bleser wrote:

...

Quality is definately the most important aspect, much more important than quantity. The problem is identifying quality packages. One solution to this problem is identifying quality over quantity. Another one would be to let the whole of us decide and express our finding of quality in an easy way.

Hey, I was just giving my opinion on the subject :)

Sure. I just wanted to move the discussion away from that one solution :)

...

Im sure there are more ways to talke this problem. I myself find the "quality over quantity" approach not to good. I does not fit into my understanding of "open". And thats what we want to be. openSUSE not somepeopledecidesomenotSUSE..

Henne, who is deciding on what's going into the SUSE media or into the ISOs ? ... see ;)

Well thats not carved into stone...

I don't see your point. Anyone would be invited to join in. Anyone can apply. But that involves: - - being the committed maintainer of the package - - accepting to be reviewed, at least in the beginning - - follow some guidelines on how to write the packages - - maybe also being on a central mailing-list with the other packagers

C'mon, it's the same on packman: someone sends an e-mail "hi I packaged this". Would you just take his RPM and put it in the packman repository as-is, without reviewing or testing it ?

No of course not. But they already walked down that "quality by quantity" street of doing things. They have no other implementation in place were they could handle it differently. With openSUSE we are talking about implementing something from scratch.

What would be nice, regarding that, is to have the possibility of letting users post their experience with the packages through some web interface. When an "unstable" package has a certain amount of positive feedback from users, it's being promoted to "stable".

And "testing" packages simply get promoted to "unstable" when they have been reviewed by at least 1 or 2 experienced packagers.

You see? Thats what im talking about. Why has this to be tied to package classes like stable, unstable, testing? Why cant you just do that for every single package? Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)

On Tuesday 06 September 2005 13:58, Pascal Bleser wrote:

If we split into 2 or 3 repositories (stable/unstable/testing), the user can choose what repos he wants to "see" in YaST2. If he's keen to install bleeding-edge packages, he can add the "unstable" and/or "testing" repositories. If he wants to stay on the safe side, he only adds the "stable" repository.

With red-carpet, you could subscribe to the stable channel, but still install stuff from unstable, and dependencies would be met from the subscribed channels first, and then the unsubscribed ones. Not sure how Yast2 or apt handle these things. -- Simon Crute IS&T Bracknell Novell UK Ltd

On Tue, Sep 06, 2005 at 02:58:38PM +0200, Pascal Bleser wrote:

If we split into 2 or 3 repositories (stable/unstable/testing), the user can choose what repos he wants to "see" in YaST2. If he's keen to install bleeding-edge packages, he can add the "unstable" and/or "testing" repositories. If he wants to stay on the safe side, he only adds the "stable" repository.

I hear everybody here talking about the Debian way of stable, unstable and testing. I would like another way of aproaching and as a user I would like to have just two options. Instaal it or not. With that I come to two repos: recomended and not-recomended. In the first you put all that is standard for a certain distro. That is the safe choice. In the untested you put everything else, untested and tested but of a different version as the standard. An example. With recomended, you will run KDE that comes with your distro. All aplications that are in recomended will work with that KDE version. In not-recomeded you will have a newer version of KDE and applications available there might not be working with the standard KDE that came with your distro. It would also contain un(sufficiently)-tested software. It is a bit of: run at your own risk.

From a programmers point of vieuw I understand the 3 different repos, from a users point of view, two is more then enough and just one would be ideal. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs

On Tuesday 06 September 2005 16:15, Marco Maske wrote:

I think a group like Packman, where the quality is perfect since years

I fear they are very good but not perfect. Sometimes I saw some packages which tried to install files with funny file owners. No problem if that user doesn't exist on your system, it will fall back to root. But if that user exist on your system it may not what you want. BTW, is there a bug-tracking system for packman (I haven't found one) or is this handled by mail? Cheers, Andreas

Hi, On Tuesday, September 06, 2005 at 17:14:13, Andreas Simon wrote:

On Tuesday 06 September 2005 16:15, Marco Maske wrote:

...

I think a group like Packman, where the quality is perfect since years

I fear they are very good but not perfect.

Nobody is perfect :)

Sometimes I saw some packages which tried to install files with funny file owners. No problem if that user doesn't exist on your system, it will fall back to root. But if that user exist on your system it may not what you want.

Sure youre not talking about source rpms?

BTW, is there a bug-tracking system for packman (I haven't found one) or is this handled by mail?

Just write a mail to packman@links2linux.de Henne -- Henne Vogelsang, http://hennevogel.de "Rules change. The Game remains the same." - Omar

Hi, On Monday, September 05, 2005 at 11:33:56, Andreas Simon wrote:

On Monday 05 September 2005 08:32, Andreas Girardet wrote:

...

A few days ago a discussion on the opensuse-optimize mailinglist was started about the future of our distro in regard to its building blocks, the packages. A suggestion was made to extend this discussion to this list and invite anyone on here to add their ideas.

Two points I can't find on the wiki page.

Bug-tracking system. I think it's important to have a bug-tracking system up for contributed packages. Probably we don't need to discuss the advantages of that.

No need for yet another bugtracking system. We already have a bugzilla up dont we? :)

From the wiki: "Packages should be allowed from any source regardless of the packagers seniority or trust level." Are you serious? People should install random software on their systems? Trust is important here. If the first packages arrive which break user systems, delete their data, install backdoors, etc. openSUSE will suffer from it. I too think everyone should be able to contribute packages, including people who have not yet much practise with rpm (I for example am just learning how to do them), etc. But those packages should be reviewed by more expierinces and trusted people before they land in the repositores.

You are showing the classical reflex when it comes to this topic ;) You immediately invent a "inner circle" of people that decide whats good and whats bad. I understand that, that is my first reflex too. But thinking about it, that approach has a lot of disadvantages. Its a bottleneck for * packages - A large sum of packages to handle by a small sum of people * people - For every inner circle there exists an outer circle. You would need to organize the "transfer" of people from the outer circle to the inner circle. That implys some other inner circle that decides these things. * changes - If youre in the outer circle you have to rely on the inner circle to "implement" the change you want. Or you need to go trough the "people" bottleneck to get into the inner circle yourself. You always end at some bottleneck if you want to contribute. Thats not very open i think. Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)

Am Dienstag, 6. September 2005 13:09 schrieb Pascal Bleser:

..., but we can't just let "anyone put anything" in the repository. Well, not into /that/ repository ;)

That's the point. What about having two repositories? One with trusted, checked, well maintained packages, and another where _anybody_ can put in packages, and YaST displaying a BIG RED WARING to the user if he/she selects such an untrusted package for installation? -- mdc

On Tuesday 06 September 2005 13:02, Henne Vogelsang wrote:

No need for yet another bugtracking system. We already have a bugzilla up dont we? :)

Yes, but is Novell willing to use this for all the contributer's packages? We will see. For example Ubuntu's bugzilla is only for their supported main packages. Other packages (their universe and multiverse repositories) have a seperate bug-tracking system, they don't allow them in their main bugzilla.

You are showing the classical reflex when it comes to this topic ;) You immediately invent a "inner circle" of people that decide whats good and whats bad. I understand that, that is my first reflex too. But thinking about it, that approach has a lot of disadvantages.

Yes it's the standard way of many projects. If there's an other way were it is still possible to maintain a high quality, well then even better. :-)

Its a bottleneck for

* packages - A large sum of packages to handle by a small sum of people

Yes, this problem can be seen for example on Ubuntu's universe. They have 20 maintainers, and about 8000 packages or so. No wonder they are not able to get universe into good shape for Ubuntu's release. This is a very big bottleneck.

* people - For every inner circle there exists an outer circle. You would need to organize the "transfer" of people from the outer circle to the inner circle. That implys some other inner circle that decides these things.

But I suppose at least one such inner circle will exist at Novell who will have the last word on SUSE Linux.

* changes - If youre in the outer circle you have to rely on the inner circle to "implement" the change you want. Or you need to go trough the "people" bottleneck to get into the inner circle yourself.

You always end at some bottleneck if you want to contribute. Thats not very open i think.

But how is quality management handled if everyone can upload random stuff? Is a staging, unstable, untested, or whatever you'll call it repository enough? Cheers, Andreas

Tuesday 06 Sep 2005 15:53 samaye houghi alekhiit:

After a certain time when a program has not changed, we must look what is going on. A year?

Six months, warning. A year, dunk, unless it's so vital... (Hey, is KCalc really being updated? Does it *need* to be updated?) --    (o-   Penguin #395953 lives at http://samvit.org    //\   subsisting on ancient Indian wisdom ...    V_/_  and modern computing efficiency! :)