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