Hello team 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. SUSE.de has already signaled that this would be a fantastic brainstorming opportunity for us, since once 10.0 is released there will be certainly decisions needed on how to proceed on that subject. The community build servers are not that far away (early next year) and that does force us to start thinking about things now and certainly more and more over the next months. This is our chance to define the future and effective growth of our distro. I have started a WIKI site on http://www.opensuse.org/index.php/Packager Which currently contains unsorted ideas from the current discussions. I would think that we should continue to add to that via a discussion here. I can if you want transfer those ideas to the wiki page or someone else can, I prefer the latter, or just do it yourself directly to the WIKI page. After 10.0 is released we can then start to structure those ideas into a more coherent and consistent form, which then could be integrated into things to come. Remember that packages are the building blocks of your distro and the way you will get packages as a user will certainly be defined and define also by how packagers create their packages. One goes hand in hand with the other. The future and innovation of this OS is going to define how quickly we can grow effectively and in a stable manner into the future and create enough innovative force to allow our distro to prevail in the commercial reality, which needs this innovation to give us the competitive edge. In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come. Thanks for listening and happy brainstorming ;) Regards, Andreas Girardet
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
Soory for the long post. In short: This is about pro-active looking for programs to put in the packager. My main concers is that there will be Fedora, Mandrake and SUSE packages out there. They are all rpm's and at least the ones I used from fedora or Mandrake seem to work just fine. I am not familiar with eitehre Fedxora or Mandrake, but would it be feasable to see what wither has and the openSUSE packager has not? Se could just look or perhaps even just copy them (as long as this is allowed by the licences of said packages) Perhaps we could even look what debian has to offer. THis to do a pro-active search for rpm packages. Another way and place to look for packages is freshmeat. On the first page it gives updates of software. This could be used in first instance to fill in software. e.g. GNU gengetopt 2.14 is standing at top of the list as the latest update. As we have NO packages in openSUSE packager (openPACKAGER? :) ) we could grab it and start with that. Package one added. The next packages that comes along will be non existing and added as well. Now when GNU gengetopt 2.15 comes by, we see that 2.14 exist, so we can add it. I am not sure how much of this could be automated or how much need human intervention. One could use the rss as a basis. That explains the licence and gives the link. The link then gives the Tar/BZ2, RPM package, CVS tree and what not you might want. That means you can get stuff directly from the source. Some examples that came in with RSS. These are the links to the packages itself on freshmeat: http://freshmeat.net/projects/perlboxvoice/?branch_id=45586&release_id=205939 That one has Tar/GZ, Tar/BZ2, RPM and DEB packages. You could either use the sources or the rpm directly. http://freshmeat.net/projects/lpgr/?branch_id=22027&release_id=205938 No direct link to the source file, so human intervention is needed to tell what the correct one is. http://freshmeat.net/projects/iozone/?branch_id=4504&release_id=205935 has TAR/GZ and src.rpm files directly linked. Either could be used http://freshmeat.net/projects/hextk/?branch_id=37356&release_id=205929 Only has a tgz file. The advatange is that the developers don't have to wory how to be included and we don't have to worry we miss something that is already on at least freshmeat. I could see it working on a semi-automatic basis Check rss for GPL software | Is it GPL (or other usable) -> No -> check next Alo on the page check OS, programming language and the like | What links are there |________________ RPM -> Use that | |________________ rpm.src -> Use that | |________________ tgz, bz2 and the like -> use that | |________________ unknown -> ask a human for the correct URL The last could be done by a link to an HTML page where the remaing info can be added by a humang being. That human is either anybody, or a group of admins. This is brainstorming and I can see that a LOT of ways that it won't work. It could be something that grows and we could just start with the humans getting it all in. From that point on you could see what repetetive moves are done and those could be automated. Another place to look might be the dep repisories. As I says, I am thinking about pro-active looking for things to be added to the packager and not just waiting for people to add stuff. This should be done TOGETHER with people adding stuff. By no means should this be a replacement for people adding stuff. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
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
On Tue, Sep 06, 2005 at 01:15:18PM +0200, Andreas Simon wrote:
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?
I understand. I am just trowing ideas in the group. So what you are saying that the basics (looking at freshmeat) is good, but the implementation should be done differently? Is there any way to check SPECS automaticaly? -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
Posting my idead in different sub-threads, so followup is easier. There could be a check on how long a package has not been updated. Say one year. Some things won't need updates, some will become obsolete and yet other are already in a much later version, but the maintaner forgot to contact the packager or was not aware that somebody else added his package. A human or group should then decide to either continue it and leave it there for another year, ditch it or update it. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Monday 05 September 2005 08:32, Andreas Girardet wrote:
Hello team
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.
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. 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. 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). 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. 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. 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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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-----
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. 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 -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)
-----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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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-----
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? 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. 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. What would we need for such a model to work? Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
-----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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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-----
On Tue, Sep 06, 2005 at 02:15:50PM +0200, Pascal Bleser wrote: > > 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 ;) 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 ;-) > > 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. 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 ;-) 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? Let's think further than the Debian model, please. (And thanks for the feature requests.) Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
-----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. (<rant>hmm.. does that sound like Fedora ? ;)</rant>) 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. <blatant-self-promotion> 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 ;))) </blatant-self-promotion> cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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-----
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.
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.
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 ;-)
- - 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).
- - 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. 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) 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. (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.) Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
-----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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v ===> FOSDEM 2006 -- February 2006 in Brussels <=== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHbcXr3NMWliFcXcRAl1SAJ0WPNQSZg9dvbBXpoLSDlpF839sAQCfc0kA gTeSTeN0rh7spLTTwr2Jzj4= =7Axy -----END PGP SIGNATURE-----
On Tue, Sep 06, 2005 at 05:34:47PM +0200, Pascal Bleser wrote:
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".
Yes. Especially if we can find organizations who'd like to donate build power on other platforms than ix86 and amd64. This opens up another can of worms, though: how can we trust a package which we didn't even build ourselves? Anything can happen on a remote build host, and reviewed spec files and patches won't help us a bit. How does Debian deal with that?
Now, what was so wrong with what I wrote in my previous mails ? ;) [...] How is that so different from the current situation ? (besides enhancing YaST2 to use such "package sets" (= installation sources) with more ease)
Remember where the discussion started: giving up the idea of centralized control, and of having only stable/unstable/testing as repositories. Package sets are mini repositories where we can loosen much of the control and allow more experimental stuff to happen, without losing the possibilitiy to have a tight review process on _some_ of them. Don't even think that we'll allow random submissions into the core code base that will also be used for the $$$ products.
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).
I'm not familiar with GNOME internals, so forgive me if I get the dependencies wrong, but one way could be: - Packager A maintains a package set "bleeding edge GNOME" which, amongst others, contains the newer gtk2, and overrides the GNOME packages in SUSE Linux core. All other packages needed for a complete system are taken from SUSE Linux core. - Packager B provides the newer gimp and marks it as dependent on the package set "bleeding edge GNOME" because it needs the newer libraries. - Packager C notices that xchat doesn't work with the newer gtk2 and rebuilds it against "bleeding edge GNOME", provided that it still builds. If not, she provides a patch. In any case, this is now a variant of the xchat package. Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Girardet wrote:
Hello team Hi Andreas ... I have edited http://www.opensuse.org/index.php/Packager and added
Thanks for the hard work :)
whatever I could to several categories to start structure the discussion.
I've done some wiki reformatting of the content structure, should be a bit more readable now. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHoTtr3NMWliFcXcRAiRBAKCz1NZE8csPSPhRRHKY+5XGhIwrTwCgvdaw ZR+YdlStDHLKpuwbmQRfnPU= =GbGS -----END PGP SIGNATURE-----
{>>> 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
On Tue, Sep 06, 2005 at 10:11:23PM -0600, Andreas Girardet wrote:
I have edited http://www.opensuse.org/index.php/Packager and added whatever I could to several categories to start structure the discussion.
Many, many thanks. <snip>
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?
I am sure you mean the technical side and not so much desgn. I would be thinking something like SourceForge.net or Freshmeat, or even SF for developers and FM for users. Not identical, but along those lines. I would ask the question in another way and then see where we get. What do you expect from a packager website, what do you expect from a user website. Isn't it a bit early to ask those things, as we have no idea yet what we will come up with.
- How could a webinterface interface with yast?
xml, would be my guess as it already uses those things. It could interface as it does now interface with e.g. guru or packman.
- Is rpm really the end of all package systems? What is missing?
Sometimes still dependency hell. apt should solve this. Myself and some others killed their system with apt, so not really a good alternative for the normal user.
- 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. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
- 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
On Wed, Sep 07, 2005 at 09:15:36AM +0200, Marcus Meissner wrote:
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.
Will that stay in house, or become OSS? -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
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.
Hi, On Tuesday, September 06, 2005 at 14:04:28, Sonja Krause-Harder wrote:
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?
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) stuff like that. Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)
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
Hi, On Tuesday, September 06, 2005 at 15:27:57, Robert Schiele wrote:
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.
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..... Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)
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
Sorry, I couldn't read all the posts :-) so I may duplicate some advices. However I thing the discussion is taking a wrong direction. We, here, are talking of driving a _distribution_, not a test site for individual packages. There are already very nice repositories for developpers, not to mention Sourceforge. Why duplicate them? Package tests is the work of _package developpers_, not _distribution developpers_. Here, we need just see if the package inserts itself well in the actual SUSE 10.0. Only bug resorting on this insertion are of our goal, not bug about the package itself. It's a all work in itself :-) IMHO the first goal we should acheive rapidly is a categorisation of the packages and a (?) vote system to know what package must be included among all of the same kind. For example, what cd writer package do we need? what editor? of course it can be a "s" at any one (we can choose more than one). For most of these packages we then can, as it's already done, use the actual source. then, we can setup a "new package proposal commission". That is a group that goal is to make a survey on the new apps available elsewhere. _not_ to host them and debug them, but to look at the already done work and see if it may be included (list of dependencies...). If a package seems promising, a member of the commission could be in charge to join the package dev team in the goal of making a SUSE 10.0 rpm. Usualy it's a volunteer who makes suse rpm for not distro included product (was the case, I remember for lyx or audacity at the beginning). And then the new package go to the category folders. Of course we can have packages sorted also in "included", "optional", that is tested, available on the ftp, but not on the CD's, "untested" (that is proposed by voluteers, but not yet tested by the opensuse team). should also be a category "rejected", for example for impossible to meet dependencies. sincerely jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
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)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:
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: 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...
Nice to hear so ;) ...
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?
Because to me, IMVHO, the best option to implement that would be to have different repositories. One for stable, one for unstable and one for testing (or call it "trusted", "untested" and "untrusted"). Like that every user can choose what repositories he wants to see in YaST2. In a way, it actually is a state or "quality label" that's down to every single package. But there's also another aspect: the version of the software itself. Let me pick an example. I package gqview. There are two versions: one stable (2.0.x) and one beta version (2.1.x). Let's say SUSE 10.1 ships gqview 2.0.x, because until now, the policy at SUSE has always been to rather pick the stable version than the bleeding-edge one, which is at least the impression I get from the outside, very understandable and certainly the best choice. Now, during the lifecycle of a distribution version (say, 10.1), SUSE is "only" providing updates for its packages when there's a security fix, or maybe sometimes when there's a severe bugfix. I would like to package the latest 2.0.x and 2.1.x versions of gqview. Users who want to stay on the safe side of things pick the 2.0.x one, and those who want to give the latest bleeding-edge version a try want to pick the 2.1.x version. Unfortunately, apt, yum and YaST2 don't really support that kind of things. If someone adds my repository into, say, YaST2 and refreshes the sources, he'll see that there's a gqview 2.1.4 available, but he won't see gqview 2.0.18. 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. Of course, this system isn't perfect, and might bring us in the same issues that Debian sometimes has. If someone decides to package the latest-and-greatest development version of some GNOME libraries and someone else builds the latest GIMP devel version that requires those latest GNOME libraries, we're in for a massive library upgrade and that will most likely nuke all the other GNOME applications on the system (<personal-rant>because, as we know, GNOME libs are sooo backwards-compatible</personal-rant>). But then again, if I want to package the latest GIMP and I require the latest GTK version for that... well, I'll just have to put my package into the "unstable" repository, where the latest GTK version is in as well. Now, to get back to that idea of a "quality label", it's more or less the same thing. What's really difficult to handle is the dependencies between packages that are not in the same repository - although having dependencies towards packages that are in "stable" or in the stock SUSE distribution is not an issue at all. Note that you're all ranting on what I say and beating me up in every reply, but up to now I'm the only one proposing concrete implementation ideas ;P So, if you have better ones, go ahead =) Henne, how do you want to implement "Why cant you just do that for every single package?" ? cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHZJ+r3NMWliFcXcRAmLiAJ9okGefmBTF/hdfuB+C9hCTQ51srgCgqO+k vCwZtjHLl8n1j3z+1vtcp6o= =ZPiW -----END PGP SIGNATURE-----
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
Hi, On Tuesday, September 06, 2005 at 14:58:38, Pascal Bleser wrote:
Henne Vogelsang wrote:
On Tuesday, September 06, 2005 at 13:48:25, Pascal Bleser wrote:
Henne Vogelsang wrote:
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?
Because to me, IMVHO, the best option to implement that would be to have different repositories. One for stable, one for unstable and one for testing (or call it "trusted", "untested" and "untrusted"). Like that every user can choose what repositories he wants to see in YaST2.
In a way, it actually is a state or "quality label" that's down to every single package.
Its a quality label of a whole "package set". The problems is see with this approach are: Who controls what is in these package sets? A small group of people like a technical board? Does Novell engeniering do? How do you decide "package sets"? Does the technical board have a look at the individual packages? Or do you just trust some maintainers? You see were that gets you at? It takes away the power from all people and puts that into the hand of some.
But there's also another aspect: the version of the software itself. Let me pick an example. I package gqview. There are two versions: one stable (2.0.x) and one beta version (2.1.x).
[ ... ]
Unfortunately, apt, yum and YaST2 don't really support that kind of things.
Cool. Something to improve to make the (openSUSE) world a better place :)
Note that you're all ranting on what I say and beating me up in every reply
C'mon! We all love you and you know that :) Were just discussing on how to approach packaging here and i very much like that we are comparing these two approaches. Only good things can come out of this!
Henne, how do you want to implement "Why cant you just do that for every single package?" ?
In the surrounding system that you use as frontend to /bin/rpm. In the package manager, installation source creation and in the website. Or do you mean implementation details? I dont have those. Thats why we are discussing here. To find out what we want :) Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)
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
Pascal Bleser wrote:
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
Yep, I agree 100%. I think a group like Packman, where the quality is perfect since years and packagers who I know, (all of them are well known if you worked with SuSE for a while ;-) is a good way. I can trust them, add their install source to Yast and import their key to my RPM-database. Same with some suser on: http://ftp.gwdg.de/pub/linux/misc/suser-*/ This smaller groups can easier managed, look for Quality, licences and so on. I think their is no a need for one big SuSE/openSUSE RPM Pakager Group. .. But for a global one SuSE/openSUSE RPM www archive, database It's easier to make one point in www for this. All small Packager groups around the world can have a base here. The user can chose what he want and then add their installsources in Yast. There can be one database for all packages from all packager groups with a uservoting like on http://www.kde-apps.org/ -- Ciao Marco, registered GNU/Linux-User 313353
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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, noone's perfect ;)
BTW, is there a bug-tracking system for packman (I haven't found one) or is this handled by mail?
By mail. Send your comments, rants, reports to packman@linux2linux.de - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v ===> FOSDEM 2006 -- February 2006 in Brussels <=== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHbLmr3NMWliFcXcRApzgAKCy8aAja4GtGYQJdmXQ8YMkhLfiRQCeJP6i E5MH4JLIbROUlF+B5YJaA9o= =KjFu -----END PGP SIGNATURE-----
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
On Tuesday 06 September 2005 11:17, Henne Vogelsang wrote:
Just write a mail to packman@links2linux.de
Henne
Or write the maintainer directly, if one is listed for the package... One time, I think on 9.0, a freshly uploaded packman rpm installed correctly but didn't run. I studied the situation for maybe ten minutes and determined that a small file was missing. I e-mailed the maintainer and got a response back about an hour later informing me the repaired rpm had been uploaded. Sure enough, I installed it and the problem had been resolved. I love those guys! (and gals?) Carl
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)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote: ... >> 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? :) Depends on how much we want to get weaved into Novell ;-) >> 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, ... > 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 But unmaintained and/or badly written spec files must not make their way to the users. You can install it on your own PC, send it to some friends or put it on your website, but it must not be, say, automatically available through an installation source in YaST2, nor part of a trusted package repository. I might be wrong, but I think it's the latter we are talking about, aren't we ? ;) > * 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. It especially implies - - style guides - - rules - - reviews > * 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. I think that's required, indeed. If a package is not actively maintained by the person who is the designated maintainer, it should be given to someone else (or tagged as "unmaintained" and a "would you like to join in and maintain that package ? click here..." on a/the website). > You always end at some bottleneck if you want to contribute. > Thats not very open i think. Maybe, but I think we're talking about a federated, trusted source of packages. Everyone is free to put his RPMs on his website, but when it comes to having it from a trusted source, it's a different thing. Don't get me wrong, I'm not being "elite" here, I'd be very happy if we had a lot more good packagers join the move, and I'd even be willing to give away all my packages and stop baking RPMs alltogether, but we can't just let "anyone put anything" in the repository. Well, not into /that/ repository ;) - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHXjNr3NMWliFcXcRAjJnAJ4sjgii4WUj3jlnWjxhkRKeUO6sTACfcSOg G1JDEGEbExADsxaa5SkhiuI= =pW22 -----END PGP SIGNATURE-----
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 Tue, Sep 06, 2005 at 03:07:37PM +0200, meister@netz00.com wrote:
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?
If there is a convinient way to move from one to the other, that would be great. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
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
Hi, On Tuesday, September 06, 2005 at 13:28:38, Andreas Simon wrote:
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.
I dont see a reason why we wouldnt allow that. (NOTE: im not involved with decisions about bugzilla in any way)
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. :-)
Thats exactly what we should try to find out together! Is there an other way were it is still possible to maintain a high quality? Henne -- Henne Vogelsang, Subsystems "Rules change. The Game remains the same." - Omar (The Wire)
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
I have answerd before, but I have not seen the reply, so if this is double, I am sorry. What I would like is to have pro-active looking for RPM's. e.g. look at the rss feed from freshmeat.net. If a new files arrives, check if it is already added to the packaging and if not add it. If it is already added, update it. In the beginning a lot would be needed to be done by humans. After a while it would become clear that things could be done atomaticaly. The rss feed points to the freshmeat page and already includes licencing info. The freashmeat page gives info about other things and links to RPM/TGZ/CVS files wich could be used The main idea is that we need to have a way to pro-active look for things to add to the packager. I understand that in the beginning this would need a lot of human interaction, but after a while a lot of parts could be largely automated. If there is a tgz file, downloading and compiling could perhaps be largely automated. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
Different ideas, different sub-threads. After a certain time when a program has not changed, we must look what is going on. A year? Some programs do not need an update, others might be abandoned and again others might have been summitted, enhanced and the enhancements were never submitted. This need to be done by human interaction. Somewhere there would be an anouncement, and then the people who check it would need to decide what status it in. Still working, abandonend or the wrong version. According to each, steps must be taken. If abandoned, perhaps it should be removed (or at least marked as such) if not updated, the link to the correct version must be updated. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
What I would like is to have pro-active looking for RPM's. e.g. look at the rss feed from freshmeat.net. If a new files arrives, check if it is already added to the packaging and if not add it. If it is already added, update it. In the beginning a lot would be needed to be done by humans. After a while it would become clear that things could be done atomaticaly. The rss feed points to the freshmeat page and already includes licencing info. The freashmeat page gives info about other things and links to RPM/TGZ/CVS files wich could be used The main idea is that we need to have a way to pro-active look for things to add to the packager. I understand that in the beginning this would need a lot of human interaction, but after a while a lot of parts could be largely automated. If there is a tgz file, downloading and compiling could perhaps be largely automated. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Monday 05 September 2005 16:42, houghi wrote:
What I would like is to have pro-active looking for RPM's. e.g. look at the rss feed from freshmeat.net. If a new files arrives, check if it is already added to the packaging and if not add it.
IIRC Gentoo has a script which checks freshmeat daily and informs package maintainers about new versions. Something like this could be a first start. Another thing which would be cool would be to automatically check other distribuions' bug-tracking systems for patches. The aim would be to make such patches and bug fixes easily available to the openSUSE's package maintainers. Surely they couldn't be applied automatically but having them compiled in a nice list would be very convenient. Isn't Ubuntu working on such a thing in the long term? Cheers, Andreas
On Mon, Sep 05, 2005 at 12:32:50AM -0600, Andreas Girardet wrote:
In my opinion this discussion needs to start now for us to have enough time to come to a clear consensus, convince most and create the foundations for years to come.
Different ideas, different sub-threads. After a certain time when a program has not changed, we must look what is going on. A year? Some programs do not need an update, others might be abandoned and again others might have been summitted, enhanced and the enhancements were never submitted. This need to be done by human interaction. Somewhere there would be an anouncement, and then the people who check it would need to decide what status it in. Still working, abandonend or the wrong version. According to each, steps must be taken. If abandoned, perhaps it should be removed (or at least marked as such) if not updated, the link to the correct version must be updated. -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
On Tue, Sep 06, 2005 at 12:23:54PM +0200, houghi wrote: <snip> Sorry for the multiple posts. I must have been too impatient. It will never happen again (I hope). -- houghi http://www.opensuse.org/index.php/Making_a_DVD_from_CDs
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! :)
Monday 05 Sep 2005 12:02 samaye Andreas Girardet alekhiit:
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. SUSE.de has already signaled that this would be a fantastic brainstorming opportunity for us, since once 10.0 is released there will be certainly decisions needed on how to proceed on that subject. The community build servers are not
Are we looking at a different kind of package other than RPM or DEB here? Rathen than a *Red Hat* Package Manager file - is there any necessity/scope for an openSUSE Package Manager file - OPM? (Too close to opium, yikes!) Nothing against Red Hat of course [nods to the friendly spies], but just being a little bit extra pro-SuSE. :) -- (o- Penguin #395953 lives at http://samvit.org //\ subsisting on ancient Indian wisdom ... V_/_ and modern computing efficiency! :)
participants (16)
-
Andreas Girardet -
Andreas Simon -
Carl Hartung -
Henne Vogelsang -
Henne Vogelsang -
houghi -
jdd -
Marco Maske -
Marcus Meissner -
Matija -
meister＠netz00.com -
Pascal Bleser -
Robert Schiele -
Shriramana Sharma -
Simon Crute -
Sonja Krause-Harder