Heya I agree with Martin on the strict version separation, but I'd leave the Qt4/KDE4 apps in KDE:Community which are there already and wait for the inevitable next repo reorganisation, more on that later. Am Freitag, 2. April 2010 15:50:56 schrieb Lubos Lunak:
On Friday 02 of April 2010, Martin Schlander wrote:
This is not the usual discussion about the OBS repository structure, but about what packages belong where within the existing structure when and why.
Recently I've noticed a few things that I've been a bit unhappy with in terms of "package placement", so I brought up the subject of repo policies on the IRC meeting, and it was decided to have a discussion here on the ML instead.
What I'm unhappy with is an increasing amount of development releases like BasKet, KChess, Amarok etc. in the KDE4:Community repository and in KDE:Backports - these repos are pushed to casual users via the YaST Community Repositories list, and should be kept relatively safe and conservative. But also KDE4/Qt4 apps like Screenie being in KDE:Community instead of KDE:KDE4:Community.
So I think we should try to agree on some policies and rules to make things clearer for packagers and users alike. Here's my suggestion:
* KDE:Backports Newer versions of apps which are part of the official distribution. Devel releases should be avoided unless there are special circumstances - e.g. the betas are known to be quite stable *and* no functional stable release exists *and* the app provides very important functionality (examples: K3b, Kaffeine, Kile).
The betas occassionally get to Backports because we allow betas in KDE:KDE4:Factory:Desktop, from which they get forwarded to openSUSE:Factory. Since Backports is newer versions of apps which are part of the official distribution, that means Backports simply links o:F. That way it is a minimal amount of work.
I see two ways of fixing the problem, and they both require certain overhead. Either the package in Backports will have build/publish disabled for the time there is a beta in KKFD/o:F, or the package in Backports will be a branch instead of a link and will need manual updates. In both cases the overhead is small, but in the first case people doing updates in KKFD need not to forget to do it, otherwise a beta gets into Backports, in the second case somebody needs to remember to do the update as necessary.
I'd prefer the second option, it's safer and in the usual case it's no rocket science, so it can be done by anybody. It probably could be even scripted to make it even easier. Would be somebody willing to keep an eye on it?
Does the webinterface rework include a version compare between projects? Otherwise it could propable be done easily as a script with osc yes. I would be willing to try it on a few packages first, I'd start with a script that checks the .spec files for versions, is there a policy for unstable package versioning? Looking for alpha, beta, rc and svn/git is simple, otherwise > .50 ? How to manage stuff like k3b which will remain "beta" for quite longer, make a white list?
* KDE:KDE4:Community KDE4/Qt4 apps which are not part of the official distribution maintained by community volunteers. Betas should be avoided if possible unless there are special circumstances - e.g. the betas are known to be quite stable *and* no functional stable release exists.
I'd like to stress one thing here. All of the repositories under KDE: are openSUSE repositories, so all of them are community repositories. Some of the ideas that were mentioned during yesterday's IRC meeting like that KDE:KDE4:Factory:Desktop is Novell-only are mistaken. Repositories are maintained by whoever will do the work and is trusted enough by the rest. That originally was only Novell people but that was because originally only those met the criteria. That is no longer the case.
In order words, anybody here can get a maintainer in KDE: repositories provided the existing maintainers trust them enough and they manage not to mess up way too often :). As for the sooner, there are several people who could ask right now, and others can build up trust by contributing in other ways first, such as doing submit requests. As for the latter, we can keep an eye on new maintainers and help as necessary.
For these reasons I don't like the KDE:KDE4:Community repository. First of all I consider it misnamed, and since I treat it basically like "random people put whatever KDE-related stuff there and nobody else cares", I don't like that this repository is provided by the community repositories list in Yast. So either I need my personal definition of this repo fixed, or it should get renamed and removed from the offered list.
Martin is right, what else to name it, it's mostly things from kde-apps, but also other stuff not directly part of "kde sc".
* KDE:KDE4:Playground Development releases (alphas, betas, RCs) and version control snapshots of KDE4/Qt4 apps.
* KDE:Community KDE3/Qt3 apps maintained by community volunteers and which don't exist in KDE:KDE3. (Maybe this repo should be shut down and everything moved to KDE:KDE3, since KDE:KDE3 is all community maintained now anyway?)
A bit similar to above. And we should consider either removing KDE4: prefixes or adding KDE3: to this one.
Not before 11.3 please =/ And when we touch them we should really go the whole way, remove the 4, unslack most paths, move KDE3:Community into KDE3 etc. and perform other repository moves which became necessary (bad package placement etcI Btw Raymond is on holiday, let's not come to conclusions before he had a word in it =) Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org