On Thursday 25 March 2010 23:25:28 Tejas Guruswamy wrote:
On 25/03/10 16:45, todd rme wrote:
First, the layout of the repositories. The most basic thing is I think we need separate KDE3 and KDE4 backports repositories. Currently the backports repository is a mix of KDE 3 and KDE 4 software, and without hunting through the dependencies it is impossible to tell what is KDE 3 software and what is KDE 4 software. For people wanting to keep a clean KDE 4 system this a hassle, especially when there are KDE 4 alternatives available.
Agree on further removal/isolation of KDE3 packages from projects. If nothing else it makes it more obvious where a KDE4 alternative is missing.
I also think that the naming of the "playground" repository is misleading. KDE's playground has a specific meaning, which is not the same a the opensuse KDE playground repository. I think if we are using the same names as KDE, it should do the same thing, and if it does something different it should have a different name. Something like "experimental", "testing", or "unstable extras" would be better in my opinion.
What I would really like to see is clarified guidelines on what goes into Playground (or its renamed equivalent) vs Community/Backports (is is alpha? beta? "stable"?). Another big question I have is that what do you do when a package in Playground goes stable? How do you communicate to the users that the upgrade path is to change repositories?
IMO what we have is a conflict between developer/packager requirements and user requirements. The developer/packager would like many projects, each containing only a few tightly related software so that maintenance is easy, lots of chances for branching, and there are not too many people trying to work on the same thing at once. The user wants as much software to be available from one repository as possible so there is less chance of adding conflicting repos, easier updates, etc. How do we reconcile these two conflicting requirements? Do we separate the idea of the repository and the build service project (i.e. multiple projects feeding into one repository), or do we create a new object that it is a set of related guaranteed-non-conflicting repositories and ask users to add/remove those instead? Or something else? This has been pretty much discussed before, especially in the context of the KDE repo layout, and the current situation just about works, so I for one don't want to disturb it.
Speaking of KDE repositories, in my opinion, opensuse could do a better job packaging software from KDE's own extragear repository. For instance the google akonadi resource was released as stable just a week after 4.3 was released, but was not actually packaged by openSUSE until after 4.4 was released over 6 months later. On the other hand things from kde-apps.org and kde-look.org get packaged almost immediately. Kchess, for example, was released on kde-apps.org 2 days ago and is already available from opensuse.
There are similar issues with playground. For instance openSUSE still does not have the mplayer or vlc phonon backends, despite the fact that they are packaged by other distributions and are supposed to be a in a pretty usable state and hosted by KDE, while marave, hosted by google and much newer, is available. Other, probably less stable playground software and third-party software is packaged as well.
This is indicative of the lack of a single to-be-packaged list for packagers. There is a horribly out-of-date and long list of packages on the wiki (http://en.opensuse.org/Package_Wishlist) that noone reads (and has a big notice not to use). There is openFATE, which is nice but is lacking in screening (both in tools and people to do it) and organization features (how can I get a list of all features that are requests for KDE-related packages?).
There is also a strong sense that stuff from kde.org is the "KDE Team" responsibility and that stuff from kde-apps and kde-look is "community" responsibility. Maybe it should be that way, maybe it shouldn't, maybe its unintentional, but that's definitely the way the work is split right now. This is the reason for a lot of the discrepancies you see.
There has long been talk of an automated dashboard that watches kde releases and kde-apps and has an overview of what packages need updating, but it doesn't exist yet. I don't remember whose pet project this was ...
This is something the Boosters team are covering in the build service web frontend. Have a look at this https://build.opensuse.org/project/status?project=openSUSE:Factory&filter_devel=KDE:KDE4:Factory:Desktop&limit_to_fails=false&commit=Filter+results It doesn't solve the googledata resource in extragear that is not separately released as a tarball elsewhere yet though, and it seems to have a problem comparing 0.9 and 0.10 versions atm. Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org