-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for breaking the thread, but it's on purpose: let's try to focus a bit on _one_ topic, the contrib repository (and please don't reply on minor points, we're discussing the big picture here.. one thing at a time :)). 1) Duplication and home:* is killing the cat^WOBS ================================================= To me, the biggest problem in the OBS (from an user's perspective) is that - - there are way too many home:* repositories with pointless duplication of existing packages (existing e.g. in other OBS repos, or in the Packman repo) - - home:* repositories with different goals and levels of quality: - -- some are just playgrounds to learn about packaging, - -- others are good quality and exist under "home:" because it's either - --- too tedious to get maintainer rights in one of the "real" OBS project (you might think it isn't, but people who contribute many packages in their free time can't just wait for a few hours to get access), or - --- we're lacking several "real" repositories (e.g. nowhere to put Jabber clients, command-line utilities, firewall tools, hardware related packages, ...) We _really_ have to move good packages from home:* repos into the "real" ones and have duplicates removed. 2) OBS: too many repos ====================== Clearly, the number of repositories _is_ a problem. Sorry for anyone denying this, but stuff is way too scattered into a multitude of repositories, and with every repository you add to any package manager, the likelihood of conflicts and other issues (e.g. running into package manager bugs) raises accordingly. 3) One big repository is rubbish ================================ The problem is that it is very complex to solve: having too many repositories (as of now) has a fair load of issues, at least for people who need/use many of them. But having few large repositories has its own share of drawbacks too: - - metadata is huge, takes too long to download just to upgrade a single package (Coolo mentioned that in a previous post) - - side-effects: here and then, you necessarily run into the need of providing newer "distro packages" (= packages included in openSUSE releases, or even in Factory); it's almost always a library that infects all packages that are built in that repository, hence barely giving users a chance of escaping that library package upgrade, even when not needed. Packman is a very good example of this situation (yes, some of us *are* aware of it, but it's very complex to solve and the tooling around RPM and repository metadata is extremely weak, to say the least), with the addition of two factors: - - we (=Packman) always provide the latest upstream versions of packages, which causes side-effects here and then, as described above - - we build+push both often and many packages, which causes very frequent repository metadata changes and, in turn, frequent large metadata downloads for users As said, it's very difficult to solve for Packman (and please don't tell me "just split the big repository", especially with the word "just"), but I'm explaining the above to make sure we try hard to avoid having that in the contrib repository. 4) Factory-staging is pointless =============================== Factory is Novell's kingdom. Period. Maybe that'll change in the future, but right now, Factory is where the upcoming openSUSE distros and the CODE11, CODE12, etc.. will spawn from. Adding more packages to Factory really doesn't make sense. Personally, I'd rather tend to think that the opposite is a much better idea: reduce Factory somewhat, if possible, and have more in online repositories. Note that having a stable contrib repository is clearly an enabling factor for being able to reduce Factory. Always keep in mind that packages in Factory are _very_ different from packages in any other repository, because it means that - - there _must_ be a committed maintainer (security, bugfixes) for every single one of them, currently it even has to be a Novell employee - - every package there has to be maintained for many years (for the lifetime of the corresponding SLE, actually) - - Novell provides support to SLE customers (see level1->level3) for those packages, 24/7 Packages in Factory have a much higher payload in terms of efforts than packages in other repos. More packages in Factory = more work = less time = (less overall quality + less innovation) 5) Mimicking other distros ========================== Obviously, looking at what works and what doesn't in other distros makes sense. But the grass is always greener on the other side. Alexey, are you aware of the issues Debian users are encountering with those 18000 packages ? Don't just throw some numbers into the room. And Fedora isn't openSUSE: Fedora is much more of a playground for experimenting and throwing new stuff at their users than openSUSE is, because openSUSE is the foundation of SLE releases... and because we, openSUSE users, value that relative stability (ok, arguably, GNOME has Pulseaudio in 11.0 but well.. I guess you see my point ;)) 6) Stability is the key ======================= The goal of the contrib repository must indeed be "stability", which essentially means two things: - - feature freeze: when the Factory repository is freezed, the contrib repository must be freezed too; only allow bugfix upgrades (as, clearly, I doubt we'd find enough human resources to backport fixes) and reject feature upgrades - - stable software: packages that are in there need a lot of testing and must hence be picked carefully The point is to make an "additional" type of repository, not an "always the latest". And then we should think about how to have those packages tested properly in order to gain an acceptable level of quality in there when openSUSE distro releases happen (or, rather, when they're freezed). Following the alpha/beta/RC cycles of Factory and issue the same calls for testing could be an option. cheers - -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM::23+24 Feb 2008, Brussels, http://fosdem.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIpiNzr3NMWliFcXcRAu60AJ97nnB2gFFdn9H4zjLVJ4ba/5RlFgCffVrn h5sWCiPqXCuzdyFembHaAq4= =h3hh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org