[opensuse-kde] Discussion about repo policies/purposes (Att: Packagers)
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). * 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. * 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?) What do you all think about this? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 02/04/10 12:45, 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).
* 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.
* 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?)
What do you all think about this?
General agreement from me, just a question: how to decide if a package is beta if it is not explicitly stated? Does version < 1.0 mean beta? I bring this up because for example tiny applications on kde-apps don't have a consistent version numbering system ... the author just starts at 0.1 by default, bumps it a few times, then abandons it at 0.4 once it is stable ... Or does beta mean that there is a different stable released version also available? Regards, Tejas -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
* Tejas Guruswamy <masterpatricko@gmail.com> [04-02-10 08:58]:
On 02/04/10 12:45, Martin Schlander wrote:
What do you all think about this?
General agreement from me, just a question: how to decide if a package is beta if it is not explicitly stated? Does version < 1.0 mean beta? I bring this up because for example tiny applications on kde-apps don't have a consistent version numbering system ... the author just starts at 0.1 by default, bumps it a few times, then abandons it at 0.4 once it is stable ... Or does beta mean that there is a different stable released version also available?
Another consideration, perhaps. In the titles shouldn't KDE become synonymous with KDE4 and KDE3 be specified, ie: drop the "4", to help gain acceptance and push recognition and dispel some of the hesitancy? This has been pushed in the package names. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Freitag 02 April 2010 15:05:51 schrieb Patrick Shanahan:
Another consideration, perhaps. In the titles shouldn't KDE become synonymous with KDE4 and KDE3 be specified, ie: drop the "4", to help gain acceptance and push recognition and dispel some of the hesitancy?
I agree, esp. since KDE's rebranding, there no longer is a "KDE4". -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 02 April 2010 08:05:51 Patrick Shanahan wrote:
In the titles shouldn't KDE become synonymous with KDE4 and KDE3 be specified, ie: drop the "4", to help gain acceptance and push recognition and dispel some of the hesitancy? This has been pushed in the package names.
+1 -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Freitag, 2. April 2010 17:14:06 schrieb Rajko M.:
On Friday 02 April 2010 08:05:51 Patrick Shanahan wrote:
In the titles shouldn't KDE become synonymous with KDE4 and KDE3 be specified, ie: drop the "4", to help gain acceptance and push recognition and dispel some of the hesitancy? This has been pushed in the package names.
+1
doing that is breaking current repo structure, I vote against doing that before 11.3, afterwards this should be done with a transition phase etc, imho we are breaking the structure way too often =/ Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
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?
* 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.
* 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. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 2. april 2010 15:50:56 skrev Lubos Lunak:
On Friday 02 of April 2010, Martin Schlander wrote:
* 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.
I'd hate to see it removed from "Community Repositories" since it easily provides many additional useful packages for people - with low risk, since it's usually leaf packages only, which may be broken themselves, but at least won't break anything else. Not sure what would be a better name, maybe KDE:Unsupported or KDE:Unofficial or such.
* 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.
This is a bit beyond the topic of the mail, but I'd be in favour of removing the KDE4: prefixes and adding the KDE3: one. And also removing the Desktop "suffixes" (for stable, factory and unstable) which are remnants of old times, which now only serve to make URLs longer and more confusing. Only problem is that changing the URLs causes a lot of trouble for people. Maybe these changes should be done concurrently with the release of 11.3 to minimize the people affected. Maybe we could also figure out how to remove the empty 42/ and 43/ folders which still exist: http://download.opensuse.org/repositories/KDE:/ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 02 April 2010 10:39:35 Martin Schlander wrote:
Only problem is that changing the URLs causes a lot of trouble for people.
Package management, links from the web, links from other opensuse servers. like mail archives, forums. Giving notification in README and new links, or redirect where it makes sense, can help those that are browsing repositories. How it is with people using package management? Is it possible to give a script as update that will look in configured repositories and change them? -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
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
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?
darix in opensuse-buildservice just pointed out another way to do this, the _link supports revisions, so we could just update the _link when the update should be forwarded to :Backports Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 6. April 2010 10:35:26 schrieb Karsten König:
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?
darix in opensuse-buildservice just pointed out another way to do this, the _link supports revisions, so we could just update the _link when the update should be forwarded to :Backports
JFYI, there is "osc linkpac -c" to create a link to the current revisions and you can update the revsion with "osc setlinkrev". -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 02 April 2010 13:50:56 Lubos Lunak wrote:
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?
* 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.
Exactly. I maintain Scribus in KDE3 now, but when we have a stable Qt4 release later this year, it will be pushed to Factory and a backport will go somewhere for current distro -1 or -2 releases eg. 11.1+ As upstream, I really agree with Martin's overall take, but some betas are quite solid. I use Kile daily for real work and no grumbles here.
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.
+1 Dirk, Lukas and Will have been very helpful when needed. Likewise, I am happy to review and assist new folks with getting their packages tidy.
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.
I am not sure, but perhaps like some Gnome leaf packages, instead move them to Contrib, where submissions get reviewed before acceptance. In general, I think the reviews in Contrib have worked well. I know I am quite careful when accepting new packages.
* 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.
This is definitely at or after 11.3 is finished IMO. Cheers, Peter -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Maybe a bit late, but I would like to put my five cents on the table. I have been reading all the comments on the initial email from Martin and I guess the tendency is to avoid putting Beta's in Community unless proven to be stable. Maybe it would be worthwhile to think about a kind of acceptance cycle? Initially Beta's are put in the Playground repository and are available for people to try them out. If they feel that the application is stable enough for a broader audience, then this can be requested on this list. If the request is accepted, then the package can be moved to the KDE:KDE4:Community repo. On 04/02/2010 03:50 PM, Lubos Lunak wrote:
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.
I guess that the Community repository is more expressing that it contains packages/applications/plasmoids/utilities/etc originally created by people not belonging to the KDE project, but wanted to contribute. Of course a package can become so popular/wanted, that it becomes part of the KDE project itself. At that moment it will move from this Community repo to the standard KDE:KDE4:Factory:Desktop repo. So maybe we should just change the description of the repo to make everybody know what he/she can expect there ? Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Tirsdag den 6. april 2010 20:10:15 skrev Raymond Wooninck:
Maybe it would be worthwhile to think about a kind of acceptance cycle? Initially Beta's are put in the Playground repository and are available for people to try them out. If they feel that the application is stable enough for a broader audience, then this can be requested on this list. If the request is accepted, then the package can be moved to the KDE:KDE4:Community repo.
I'd maintain that this should only happen if: 1) there's no officially released, stable software providing the same functionality 2) the app provides functionality that can be said to be genuinely important If those criteria are met, I think the package could be moved to kde4:community, after a few people have tried it out in playground and found it to be usable and fairly safe. If the above criteria aren't met, I'd be against putting development versions in kde4:community no matter how stable. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Hi, Martin: I know that you are my dearest Danish KMid translator :) so I assume that you care enough about this application. My questions below are not addressed only to you. On Wednesday, April 7, 2010, Martin Schlander wrote:
Tirsdag den 6. april 2010 20:10:15 skrev Raymond Wooninck:
Maybe it would be worthwhile to think about a kind of acceptance cycle? Initially Beta's are put in the Playground repository and are available for people to try them out. If they feel that the application is stable enough for a broader audience, then this can be requested on this list. If the request is accepted, then the package can be moved to the KDE:KDE4:Community repo.
I'd maintain that this should only happen if: 1) there's no officially released, stable software providing the same functionality 2) the app provides functionality that can be said to be genuinely important
Both criteria can be more or less subjective, but the second one, "genuinely important", scares me a bit. How are you proposing to evaluate the importance of a package? If you only take into account the number of users, you may be alienating a minority liking (or neededing) the software. For instance, a package used only by disabled people may fail the majority criteria.
If those criteria are met, I think the package could be moved to kde4:community, after a few people have tried it out in playground and found it to be usable and fairly safe.
If the above criteria aren't met, I'd be against putting development versions in kde4:community no matter how stable.
So, you are proposing some kind of voting, or any other formal process in order to accept and remove packages from Community and Playground? Can you please elaborate your proposal? I am a bit worried by this thread, because I'm also confused about the matter. I'm the upstream maintainer of several applications and also a KDE/openSUSE/OBS user (home:plcl:kde4). I've been recently added to the KDE4:Community and KDE4:Playground repos. My applications at home:plcl:kde4 are MIDI-related. MIDI is a small niche market that nevertheless is important enough for some software manufacturers like Apple, but maybe not enough for openSUSE-KDE?. How do you think I should proceed? I've already added VMPK to KDE4:Community, and I would like to add KMid, KMidimon, KMetronome and Drumstick as well. Would you agree? Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Mittwoch, 7. April 2010 13:05:06 schrieb Pedro Lopez-Cabanillas:
Hi,
Martin: I know that you are my dearest Danish KMid translator :) so I assume that you care enough about this application. My questions below are not addressed only to you.
On Wednesday, April 7, 2010, Martin Schlander wrote:
Tirsdag den 6. april 2010 20:10:15 skrev Raymond Wooninck:
Maybe it would be worthwhile to think about a kind of acceptance cycle? Initially Beta's are put in the Playground repository and are available for people to try them out. If they feel that the application is stable enough for a broader audience, then this can be requested on this list. If the request is accepted, then the package can be moved to the KDE:KDE4:Community repo.
I'd maintain that this should only happen if: 1) there's no officially released, stable software providing the same functionality 2) the app provides functionality that can be said to be genuinely important
Both criteria can be more or less subjective, but the second one, "genuinely important", scares me a bit. How are you proposing to evaluate the importance of a package? If you only take into account the number of users, you may be alienating a minority liking (or neededing) the software. For instance, a package used only by disabled people may fail the majority criteria.
I agree, we should try to make some clear rules first and exceptions only be made after proposing and defending them on this list. We can expect from the software developers to release once in a while, it's in there own interest to announce a stable release people can rely on without things beeing too much in flux. So saying no non-release packages in Community sounds good to me. Playground can be used for pre-release versions of the packages. Now there is the case of software that has no (kde4) release yet, I think we can move these into :Community after a short notice on the list as well. Point is too many exceptions make the ruleset pointless.
If those criteria are met, I think the package could be moved to kde4:community, after a few people have tried it out in playground and found it to be usable and fairly safe.
If the above criteria aren't met, I'd be against putting development versions in kde4:community no matter how stable.
So, you are proposing some kind of voting, or any other formal process in order to accept and remove packages from Community and Playground? Can you please elaborate your proposal?
I am a bit worried by this thread, because I'm also confused about the matter. I'm the upstream maintainer of several applications and also a KDE/openSUSE/OBS user (home:plcl:kde4). I've been recently added to the KDE4:Community and KDE4:Playground repos. My applications at home:plcl:kde4 are MIDI-related. MIDI is a small niche market that nevertheless is important enough for some software manufacturers like Apple, but maybe not enough for openSUSE-KDE?. How do you think I should proceed? I've already added VMPK to KDE4:Community, and I would like to add KMid, KMidimon, KMetronome and Drumstick as well. Would you agree?
Regards, Pedro
Yeah voting isn't a good idea as there aren't many people around judging every piece of software. But the proponent should give reasons why to move it to :Community in case there is no proper release. If you are the maintainer of the software and can call a software reasonably stable why not make a release out of it and move that into the :Community repo? That needs no discussion and is what that repository is for. Btw. I also think we had the kde3 versions of these in opensuse, so your midi apps should actually migrate into Factory Cheers, Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wednesday, April 7, 2010, Karsten König wrote:
Yeah voting isn't a good idea as there aren't many people around judging every piece of software. But the proponent should give reasons why to move it to :Community in case there is no proper release.
If you are the maintainer of the software and can call a software reasonably stable why not make a release out of it and move that into the :Community repo? That needs no discussion and is what that repository is for.
What is a proper release for you? all my applications at home:plcl:kde4 have been released and publicly announced. There are freshmeat.net and opendesktop.org pages for them. I have the intention of adding the packages to the Community repo, yes. Unless somebody provides arguments against that.
Btw. I also think we had the kde3 versions of these in opensuse, so your midi apps should actually migrate into Factory
There was a kmid package for kde3 in openSUSE, when kmid was part of kdemultimedia. Now, it belongs to extragear/multimedia. I agree with the migration into Factory, but it is beyond me. It can only be done by a small number of people with permissions in the project KDE4:Factory:Desktop. The other applications have *never* been part of openSUSE. Some of them are available in other distros, though. KMidimon is available in Debian and Ubuntu since a long time ago, when it was a KDE3 application. Also for Fedora, distributed by Planet CCRMA at home. VMPK is available in Debian/Ubuntu, and also in Mandriva Cooker. So, there may be a main mission of the KDE4:Community repository for me: providing Qt/KDE applications that can be potentially valuable for some users, and are neglected in the official openSUSE repositories. This goal requires that KDE4:Community is offered in Yast. Maybe the packages aren't well known, so there is a secondary mission: advertise those programs among the public and people that has power to push them into the official repositories. Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Onsdag den 7. april 2010 19:32:02 skrev Pedro Lopez-Cabanillas:
On Wednesday, April 7, 2010, Karsten König wrote:
Yeah voting isn't a good idea as there aren't many people around judging every piece of software. But the proponent should give reasons why to move it to :Community in case there is no proper release.
What is a proper release for you? all my applications at home:plcl:kde4 have been released and publicly announced. There are freshmeat.net and opendesktop.org pages for them.
Seems to me there's nothing alpha, beta or rc about your applications. I mean if the release announcement doesn't use words like alpha, beta, release candidate, tech preview or similar warnings about the software not being considered ready for mainstream usage by the developers, then the software has to be considered "a proper release" - and should preferably be packaged in KDE4:Community ASAP (assuming it's a KDE4/Qt4 app of course, and doesn't already exist in the distro itself, in which case it should be built in factory and backports ASAP.) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Mittwoch, 7. April 2010 19:32:02 schrieb Pedro Lopez-Cabanillas:
On Wednesday, April 7, 2010, Karsten König wrote:
Yeah voting isn't a good idea as there aren't many people around judging every piece of software. But the proponent should give reasons why to move it to :Community in case there is no proper release.
If you are the maintainer of the software and can call a software reasonably stable why not make a release out of it and move that into the
:Community repo? That needs no discussion and is what that repository is
for.
What is a proper release for you? all my applications at home:plcl:kde4 have been released and publicly announced. There are freshmeat.net and opendesktop.org pages for them.
If you give it a release number without alpha/beta etc it's a proper stable release for me =) No svn / git checkouts... Sure you have a roadmap and ideas for future releases, but you don't do stable release with a big rebuild or a new feature half done.
I have the intention of adding the packages to the Community repo, yes. Unless somebody provides arguments against that.
This is not about keeping packages from Community but about keeping unstable packages from Community and place them in Playground, as the maintainer/developer you are in the best position to judge the state of your releases.
Btw. I also think we had the kde3 versions of these in opensuse, so your midi apps should actually migrate into Factory
There was a kmid package for kde3 in openSUSE, when kmid was part of kdemultimedia. Now, it belongs to extragear/multimedia. I agree with the migration into Factory, but it is beyond me. It can only be done by a small number of people with permissions in the project KDE4:Factory:Desktop.
Still you can get the stone rolling by submit requesting it to :Factory, one path would be through KDE4:Factory:Desktop as devel project or making your own devel project, see this article http://en.opensuse.org/Submit_Request for a few hints on the subject, there is also another specificly dedicated to Factory submits but I can't find it now. Still migrating through KDE4:Factory:Desktop would propably be the best way and the "few people in the obs list" are very responsive and also subscribed to this list, so write a mail or bring it up on next kde meeting, no one is able to track how good or important the things in :Community are.
The other applications have *never* been part of openSUSE. Some of them are available in other distros, though. KMidimon is available in Debian and Ubuntu since a long time ago, when it was a KDE3 application. Also for Fedora, distributed by Planet CCRMA at home. VMPK is available in Debian/Ubuntu, and also in Mandriva Cooker.
The OBS lead to an explosion in available packages that aren't bundled with the main distribution (whatever openSUSE:Factory ships) which is a nice direction as it makes it easier to get and distribute non SuSE shipped stuff. Still this lead to a huge amount of repositories, sometimes incompatible or shipping the same packages etc. Touching your reply to Martin, there currently are no real "what belongs into the main repository" guidelines for openSUSE =( there was the :Contrib repository as an effort to Community managed and "shipped" packages, the state isn't clear anymore though, as basicly everybody can submit to the main repository, if it gets accepted is another question though. Still the path to migrate stuff into main became much easier. Ubuntu has the advantage of Universe which basicly announces that "everything" is in there, the debian guys do awesome work for it. Still nothing like this exists for openSUSE =/ Mandriva and Fedora sit in the same boat as openSUSE here, the non included packages are spread over alot of repositories, OBS made the situation better that it's a single caterer to most free software.
So, there may be a main mission of the KDE4:Community repository for me: providing Qt/KDE applications that can be potentially valuable for some users, and are neglected in the official openSUSE repositories. This goal requires that KDE4:Community is offered in Yast.
+1 to that, that's what it is for and Martin isn't fighting that =)
Maybe the packages aren't well known, so there is a secondary mission: advertise those programs among the public and people that has power to push them into the official repositories.
The process to a "better" spot should be started by the maintainer, openSUSE users barely make public demands, if they find something not satisfying they live with it, go somewhere else or complain loudly on decisions announced and discussed long time ago =( So push your midi software forward, there is nothing comparable for Qt so it's a blank spot waiting to be filled =)
Regards, Pedro
Cheerio, Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday, April 8, 2010, Karsten König wrote:
Maybe the packages aren't well known, so there is a secondary mission: advertise those programs among the public and people that has power to push them into the official repositories.
The process to a "better" spot should be started by the maintainer, openSUSE users barely make public demands, if they find something not satisfying they live with it, go somewhere else or complain loudly on decisions announced and discussed long time ago =(
But sometimes users are also vocal and have some influence on openSUSE policies. The openFATE system (https://features.opensuse.org) allows to request features and packages. Requests are evaluated by somebody, and can be voted. This allows community involvement. I'm thinking about going this way, and request several currently unavailable MIDI packages, not only mine. As a successful openFATE case study, https://features.opensuse.org/306967 :-) Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Onsdag den 7. april 2010 13:05:06 skrev Pedro Lopez-Cabanillas:
On Wednesday, April 7, 2010, Martin Schlander wrote:
Tirsdag den 6. april 2010 20:10:15 skrev Raymond Wooninck:
Maybe it would be worthwhile to think about a kind of acceptance cycle? Initially Beta's are put in the Playground repository and are available for people to try them out. If they feel that the application is stable enough for a broader audience, then this can be requested on this list. If the request is accepted, then the package can be moved to the KDE:KDE4:Community repo.
I'd maintain that this should only happen if: 1) there's no officially released, stable software providing the same functionality 2) the app provides functionality that can be said to be genuinely important
Both criteria can be more or less subjective, but the second one, "genuinely important", scares me a bit. How are you proposing to evaluate the importance of a package? If you only take into account the number of users, you may be alienating a minority liking (or neededing) the software. For instance, a package used only by disabled people may fail the majority criteria.
Clearly it's not easy to make a fixed rule for determining when something is important, but that's why I used Kile as one of the examples, it's not used by very many people, but it's very important to those who do write LaTex. KMid would fit in the same category. But e.g. betas of KChess and BasKet would not, because there are stable alternatives. So they should be kept in Playground for geeks and enthusiasts to play with until there are stable releases targetted at casual users.
So, you are proposing some kind of voting, or any other formal process in order to accept and remove packages from Community and Playground? Can you please elaborate your proposal?
Maybe it comes across like I want some sort of fascist rule, but really I just want packagers to think twice and care a bit more about these decisions and to have some general guidelines - because the vast majority of openSUSE users are silent and casual users - and they will add the backports and community repos via yast community repositories list - and will expect them to be pretty much idiot proof. And I for one care a lot about being able to recommend openSUSE to casual users like my mother and father or the casual people in my lug for example. I'm hoping these issues could be resolved by simply calling attention to the matter, and packager "self-jurisdiction".
I am a bit worried by this thread, because I'm also confused about the matter. I'm the upstream maintainer of several applications and also a KDE/openSUSE/OBS user (home:plcl:kde4). I've been recently added to the KDE4:Community and KDE4:Playground repos. My applications at home:plcl:kde4 are MIDI-related. MIDI is a small niche market that nevertheless is important enough for some software manufacturers like Apple, but maybe not enough for openSUSE-KDE?. How do you think I should proceed? I've already added VMPK to KDE4:Community, and I would like to add KMid, KMidimon, KMetronome and Drumstick as well. Would you agree?
I don't know the the status of these apps. If these are labeled as development releases by upstream (i.e. you), I'd say it's up to the packager (i.e. you) to decide. * Do you think these apps are important for their target audience * Is there no stable alternative in the distro offering the same functionality * Is there a risk that casual users "accidentally" install this and get in trouble and think less of the distribution Also keep in mind I don't have any special say or merit that makes my opinions particularly important. I'm just a useless loudmouth translator trying to have a discussion about something that that makes me a little bit concerned. So you shouldn't be worried by threads that I start :-) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wednesday, April 7, 2010, Martin Schlander wrote:
I for one care a lot about being able to recommend openSUSE to casual users like my mother and father or the casual people in my lug for example.
You are concerned about the quality of some packages, that may damage the image of the distribution. But the image can also be damaged by excessive zeal in package filtering. The following case is from the real life: a Windows user is thinking about migrating to Linux. He asks me if I can recommend openSUSE with some MIDI programs. He is using VMPK and QSynth in Windows among other things. Are they easy to install in openSUSE? I had to answer that neither VMPK nor QSynth are available in openSUSE official repositories. But he can find them in Ubuntu, though. http://packages.ubuntu.com/lucid/qsynth http://packages.ubuntu.com/lucid/vmpk
If these are labeled as development releases by upstream (i.e. you), I'd say it's up to the packager (i.e. you) to decide. Every release is a "development release" for me. If there aren't changes requested or planned for the next release, the application is dead. Let's analyze for instance VMPK: http://vmpk.sourceforge.net
* Do you think these apps are important for their target audience Looks like it may be, 62000 downloads in one year and half. About 80% windows, 7% mac, 13% sources. http://sourceforge.net/project/stats/detail.php?group_id=236429&ugn=vmpk&type=prdownload&mode=alltime&file_id=0
* Is there no stable alternative in the distro offering the same functionality There is an alternative to VMPK in openSUSE: vkeybd, but it offers less functionality. http://software.opensuse.org/search?baseproject=ALL&p=1&q=vkeybd
* Is there a risk that casual users "accidentally" install this and get in trouble and think less of the distribution There is always that risk. I try to fix quickly all critical bugs that have been reported. There is also the problem of sound being the ugly duck.
So, In my opinion it is worth to keep it at KDE4:Community, what do you think?
Also keep in mind I don't have any special say or merit that makes my opinions particularly important. I'm just a useless loudmouth translator trying to have a discussion about something that that makes me a little bit concerned. So you shouldn't be worried by threads that I start :-)
I'm not worried because your comments. I am also concerned about the same things, and your opinion has the same value for me as the opinion of any other member of the KDE community. Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 04/02/2010 03:50 PM, Lubos Lunak wrote:
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.
I guess that the Community repository is more expressing that it contains packages/applications/plasmoids/utilities/etc originally created by people not belonging to the KDE project, but wanted to contribute. Of course a package can become so popular/wanted, that it becomes part of the KDE project itself. At that moment it will move from this Community repo to the standard KDE:KDE4:Factory:Desktop repo.
'Not belonging to the KDE project' is rather fuzzy, and I'd consider that to be a quite unsuitable rule for repository organization anyway. It's currently not the case anyway, KKFD is 'what is in o:F', so it includes also e.g. kde-apps.org stuff if it's worthwhile. So there is a place for second repo, which would be 'what is not in o:F' and contain stuff that would be worth placing at least there. But 'Community' is not a good name for that. Additionally, since it is provided in Yast, I would really expect at least some assurance of quality there[*]. How does KDE:KDE4:Community actually currently work? The repo-wide maintainer list is pretty long and I don't know many of those people, to me it looks like it's some free-for-all repo. Or are others here really fine with providing such a repo in Yast? [*] I mean, WTH is e.g. https://build.opensuse.org/package/show?package=libqt4&project=KDE:KDE4:Community ?? That does not belong there, at all. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Onsdag den 7. april 2010 15:51:49 skrev Lubos Lunak:
'Not belonging to the KDE project' is rather fuzzy, and I'd consider that to be a quite unsuitable rule for repository organization anyway. It's currently not the case anyway, KKFD is 'what is in o:F', so it includes also e.g. kde-apps.org stuff if it's worthwhile.
So there is a place for second repo, which would be 'what is not in o:F' and contain stuff that would be worth placing at least there. But 'Community' is not a good name for that. Additionally, since it is provided in Yast, I would really expect at least some assurance of quality there[*]. How does KDE:KDE4:Community actually currently work? The repo-wide maintainer list is pretty long and I don't know many of those people, to me it looks like it's some free-for-all repo. Or are others here really fine with providing such a repo in Yast?
I think it's very important to have the repo and offer it via yast - no matter what it's called. It enables us to provide more packages as well as new ones appearing with very little hassle for users - like e.g. Synaptiks[*] which didn't exist in time for 11.2 but fills a gaping hole in the kde package set. Therefore having such a repo in yast is a huge asset to the distro - especially from a casual user point of view. We just need a bit of guidelines and some packager discipline to make it a little less messy and risky. And it needs a bit of janitorial work - with kcm_touchpad and plasma-theme-air which should both clearly be removed being my current favourite annoyances. I'm considering looking into whether such janitorial work is managable for someone with my very limited skillz. [*] However the adding of synaptiks to factory seems to have meant it has disappeared from Community and therefore is currently not built for 11.2+4.3.x users :-( -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wednesday 07 of April 2010, Martin Schlander wrote:
Onsdag den 7. april 2010 15:51:49 skrev Lubos Lunak:
So there is a place for second repo, which would be 'what is not in o:F' and contain stuff that would be worth placing at least there. But 'Community' is not a good name for that. Additionally, since it is provided in Yast, I would really expect at least some assurance of quality there[*]. How does KDE:KDE4:Community actually currently work? The repo-wide maintainer list is pretty long and I don't know many of those people, to me it looks like it's some free-for-all repo. Or are others here really fine with providing such a repo in Yast?
I think it's very important to have the repo and offer it via yast - no matter what it's called. It enables us to provide more packages as well as new ones appearing with very little hassle for users - like e.g. Synaptiks[*] which didn't exist in time for 11.2 but fills a gaping hole in the kde package set. Therefore having such a repo in yast is a huge asset to the distro - especially from a casual user point of view.
I think nobody is arguing against that.
We just need a bit of guidelines and some packager discipline to make it a little less messy and risky.
And this is my problem (the lack of this, that is). Let me put it differently. There is KDE:Backports, which is newer versions of what is in the distribution. We can have one more, let's call it KDE:Extra, which would be KDE apps that are not part of the distribution. There's no problem with that. The problem is that KDE:KDE4:Community currently serves this role, and, as far as I understand it, has almost no rules or review (I'm right on this, am I not?). I think we should do a bit better for a repository that is offered to users directly in Yast. So what I propose is that KDE:Extra is created and the workflow is not free-for-all. I.e. repo-wide maintainers are not handed out to everybody but only to some people with certain trust and experience. And by that I don't mean that I myself want to rule the repo with an iron hand, but this should simply assure certain review and prevent obvious screwups like the recent libqt4 inclusion in KDE:KDE4:Community. Repo-wide maintainers would be people willing to take care of the repo as a whole. If somebody would want a package there, they would ask on this list, then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package. Opinion on this? I'm not sure what would be less work, simply keeping KDE:KDE4:Community and doing a cleanup in it to make it this repo, or start from scratch and copy over things.
And it needs a bit of janitorial work - with kcm_touchpad and plasma-theme-air which should both clearly be removed being my current favourite annoyances.
I'm considering looking into whether such janitorial work is managable for someone with my very limited skillz.
[*] However the adding of synaptiks to factory seems to have meant it has disappeared from Community and therefore is currently not built for 11.2+4.3.x users :-(
You can copy it back and build it only for build repositories which do not include it from KKFD yet. I assume that would be similar also for the packages above that you suggest should be removed. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Freitag, 9. April 2010 16:06:40 schrieb Lubos Lunak:
On Wednesday 07 of April 2010, Martin Schlander wrote:
Onsdag den 7. april 2010 15:51:49 skrev Lubos Lunak:
So there is a place for second repo, which would be 'what is not in o:F'
and contain stuff that would be worth placing at least there. But 'Community' is not a good name for that. Additionally, since it is provided in Yast, I would really expect at least some assurance of quality there[*]. How does KDE:KDE4:Community actually currently work? The repo-wide maintainer list is pretty long and I don't know many of those people, to me it looks like it's some free-for-all repo. Or are others here really fine with providing such a repo in Yast?
I think it's very important to have the repo and offer it via yast - no matter what it's called. It enables us to provide more packages as well as new ones appearing with very little hassle for users - like e.g. Synaptiks[*] which didn't exist in time for 11.2 but fills a gaping hole in the kde package set. Therefore having such a repo in yast is a huge asset to the distro - especially from a casual user point of view.
I think nobody is arguing against that.
We just need a bit of guidelines and some packager discipline to make it a little less messy and risky.
And this is my problem (the lack of this, that is).
Let me put it differently. There is KDE:Backports, which is newer versions of what is in the distribution. We can have one more, let's call it KDE:Extra, which would be KDE apps that are not part of the distribution. There's no problem with that.
The problem is that KDE:KDE4:Community currently serves this role, and, as far as I understand it, has almost no rules or review (I'm right on this, am I not?). I think we should do a bit better for a repository that is offered to users directly in Yast.
The intentions were propably meant to be welcoming to new contributions, but definitivly spun out of order.
So what I propose is that KDE:Extra is created and the workflow is not free-for-all. I.e. repo-wide maintainers are not handed out to everybody but only to some people with certain trust and experience. And by that I don't mean that I myself want to rule the repo with an iron hand, but this should simply assure certain review and prevent obvious screwups like the recent libqt4 inclusion in KDE:KDE4:Community. Repo-wide maintainers would be people willing to take care of the repo as a whole.
Sounds to me like you are pressing for this repo to include it in the yast community list for 11.3. Fine by me, but as you pointed out there is more moving around to be done, so we should make sure it will fit in the future layout.
If somebody would want a package there, they would ask on this list, then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package.
Opinion on this?
I like it, but we want that to be open, so the maintainer list needs to be lean, as in one will receive a timely response. Also a further path into :Factory should be documented, Pablo makes a good example with his midi applications that we might want in the main distribution or the contrib repository, though the current state of that initiative is unclear to me.
I'm not sure what would be less work, simply keeping KDE:KDE4:Community and doing a cleanup in it to make it this repo, or start from scratch and copy over things.
Copying over would make it easier to review packages, also for stuff like linking to _home which some aren't happy with, of course a proper ruleset needs to be set before =) Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 09 of April 2010, Karsten König wrote:
Am Freitag, 9. April 2010 16:06:40 schrieb Lubos Lunak:
If somebody would want a package there, they would ask on this list, then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package.
Opinion on this?
I like it, but we want that to be open, so the maintainer list needs to be lean, as in one will receive a timely response.
And is that not currently the case with KKFD? Especially when anybody can prod the maintainers on IRC If needed?
Also a further path into :Factory should be documented
I think you've just volunteered :). -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 12. April 2010 16:05:55 schrieb Lubos Lunak:
On Friday 09 of April 2010, Karsten König wrote:
Am Freitag, 9. April 2010 16:06:40 schrieb Lubos Lunak:
If somebody would want a package there, they would ask on this list,
then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package.
Opinion on this?
I like it, but we want that to be open, so the maintainer list needs to be lean, as in one will receive a timely response.
And is that not currently the case with KKFD? Especially when anybody can prod the maintainers on IRC If needed?
It is more about amount of people or proper task asignment. If there are like 15 good people maintaining the repository stuff might not get reviewed because "there are enough otherones, heck maybe someone reviews it right now!" This wasn't about KKFD, just saying the list needs to be somewhat short so it's clear who is responsible for the repository, as it currently is in KKFD for example ;-)
Also a further path into :Factory should be documented
I think you've just volunteered :).
When the new repo structure is out I'll cook something up Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 9. april 2010 16:06:40 skrev Lubos Lunak:
So what I propose is that KDE:Extra is created and the workflow is not free-for-all. I.e. repo-wide maintainers are not handed out to everybody but only to some people with certain trust and experience. And by that I don't mean that I myself want to rule the repo with an iron hand, but this should simply assure certain review and prevent obvious screwups like the recent libqt4 inclusion in KDE:KDE4:Community. Repo-wide maintainers would be people willing to take care of the repo as a whole.
If somebody would want a package there, they would ask on this list, then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package.
Opinion on this?
Sounds good to me.
I'm not sure what would be less work, simply keeping KDE:KDE4:Community and doing a cleanup in it to make it this repo, or start from scratch and copy over things.
You made some good points earlier about "Community" being unfortunate and misleading naming, so renaming/moving it to KDE:Extra would probably be a good idea, but probably shouldn't be done until 11.3 release to save pain for users. However I think it would be a bad idea to create "Extra" _and_ keep "Community" around, if that's what you meant. Like Karsten I think it should be thought into a context of a full repo restructuring including dropping "kde4" prefix, "desktop" suffix etc. How about something like this: KDE:Distribution:STABLE/openSUSE_11.3 KDE:Distribution:Factory/openSUSE_11.3 KDE:Distribution:TRUNK/openSUSE_11.3 KDE:Extra/openSUSE_11.3 KDE:Playground/openSUSE_11.3 KDE:KDE3/openSUSE_11.3 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 9. april 2010 18:33:38 skrev Martin Schlander:
How about something like this:
KDE:Distribution:STABLE/openSUSE_11.3 KDE:Distribution:Factory/openSUSE_11.3 KDE:Distribution:TRUNK/openSUSE_11.3 KDE:Extra/openSUSE_11.3 KDE:Playground/openSUSE_11.3 KDE:KDE3/openSUSE_11.3
Dammit.. I forgot KDE:Backports -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
At vrijdag 09 april 2010 18:33:38 wrote Martin Schlander:
How about something like this:
KDE:Distribution:STABLE/openSUSE_11.3 KDE:Distribution:Factory/openSUSE_11.3 KDE:Distribution:TRUNK/openSUSE_11.3 KDE:Extra/openSUSE_11.3 KDE:Playground/openSUSE_11.3 KDE:KDE3/openSUSE_11.3
What about using lower case only, something like this: kde:distribution:stable/openSUSE_11.3 kde:distribution:factory/openSUSE_11.3 kde:distribution:trunk/openSUSE_11.3 kde:extra/openSUSE_11.3 kde:playground/openSUSE_11.3 kde:kde3/openSUSE_11.3 -- Richard -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Freitag, 9. April 2010 18:44:26 schrieb Richard Bos:
At vrijdag 09 april 2010 18:33:38 wrote Martin Schlander:
How about something like this:
KDE:Distribution:STABLE/openSUSE_11.3 KDE:Distribution:Factory/openSUSE_11.3 KDE:Distribution:TRUNK/openSUSE_11.3 KDE:Extra/openSUSE_11.3 KDE:Playground/openSUSE_11.3 KDE:KDE3/openSUSE_11.3
What about using lower case only, something like this: kde:distribution:stable/openSUSE_11.3 kde:distribution:factory/openSUSE_11.3 kde:distribution:trunk/openSUSE_11.3 kde:extra/openSUSE_11.3 kde:playground/openSUSE_11.3 kde:kde3/openSUSE_11.3
hmm where would be the benefit? KDE as an abbrevation could justify writing large and openSUSE is the proper name, only STABLE and TRUNK fall out of the usual scheme, no idea why actually. still the other movings can be done inside the kde team repository, for renaming KDE to kde that'd need extra requests on the main obs structure. Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
At vrijdag 09 april 2010 19:10:13 wrote Karsten König:
What about using lower case only, something like this: kde:distribution:stable/openSUSE_11.3 kde:distribution:factory/openSUSE_11.3 kde:distribution:trunk/openSUSE_11.3 kde:extra/openSUSE_11.3 kde:playground/openSUSE_11.3 kde:kde3/openSUSE_11.3
hmm where would be the benefit?
It is less intimidating, upper case is like shouting. php is an abbreviation too, but it is written in lower case: server:/php:/applications Easy to remember and to type too. There are more lower case abbrevations in this repository: http://download.opensuse.org/repositories/server:/ (http, irc, ltsp, etc)
KDE as an abbrevation could justify writing large and openSUSE is the proper name, only STABLE and TRUNK fall out of the usual scheme, no idea why actually.
-- Richard -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 09 of April 2010, Martin Schlander wrote:
Sounds good to me.
I'm not sure what would be less work, simply keeping KDE:KDE4:Community and doing a cleanup in it to make it this repo, or start from scratch and copy over things.
You made some good points earlier about "Community" being unfortunate and misleading naming, so renaming/moving it to KDE:Extra would probably be a good idea, but probably shouldn't be done until 11.3 release to save pain for users.
What pain? If the rename is to happen, then I think it should be done before 11.3, exactly to make it simpler for users. New users will get the repo from the start and won't have an ... well, obsolete repo, and existing users need to switch at some point anyway. The list of repos offered as community repos can be AFAIK modified even after release, but that doesn't help with people who have already added that repo.
However I think it would be a bad idea to create "Extra" _and_ keep "Community" around, if that's what you meant.
Not really. With the new repo I don't see a reason for keeping a worse version of it, except temporarily for transition.
Like Karsten I think it should be thought into a context of a full repo restructuring including dropping "kde4" prefix, "desktop" suffix etc.
How about something like this:
KDE:Distribution:STABLE/openSUSE_11.3 KDE:Distribution:Factory/openSUSE_11.3 KDE:Distribution:TRUNK/openSUSE_11.3 KDE:Extra/openSUSE_11.3 KDE:Playground/openSUSE_11.3 KDE:KDE3/openSUSE_11.3
I like this. With the exception of TRUNK, I think that should stay as UNSTABLE. Trunk is a SVN term that's a) way too technical, b) going away in the future. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 04/09/2010 04:06 PM, Lubos Lunak wrote:
So what I propose is that KDE:Extra is created and the workflow is not free-for-all. I.e. repo-wide maintainers are not handed out to everybody but only to some people with certain trust and experience. And by that I don't mean that I myself want to rule the repo with an iron hand, but this should simply assure certain review and prevent obvious screwups like the recent libqt4 inclusion in KDE:KDE4:Community. Repo-wide maintainers would be people willing to take care of the repo as a whole.
Why do we not follow the setup that openSUSE as a distribution has ? We have the standard repo's (Stable, Factory and Unstable) and then we could have a Contrib repo instead of the Community repo. o:F:Contrib (or 11.2:Contrib) serves the same purpose as that it should offer packages created by the community to enhance what is delivered from the Standard. Contrib alos follows a more strict ruling as that it knows repo-wide maintainers and package-specific maintainers.
If somebody would want a package there, they would ask on this list, then do a submit request resulting in creating the package in the repo. Further updates would be by additional SRs or, if trusted enough, they would get maintainer only for the package.
Opinion on this?
Given the mess that Community went through the last few days, I believe that nobody will oppose this. As has been indicated already before is that Community is used by a big audience and we do not want to suddenly upgrade somebody to something that could harm his/her installation.
I'm not sure what would be less work, simply keeping KDE:KDE4:Community and doing a cleanup in it to make it this repo, or start from scratch and copy over things.
And it needs a bit of janitorial work - with kcm_touchpad and plasma-theme-air which should both clearly be removed being my current favourite annoyances.
I guess that it would be much easier to setup a new repo and move package by package after a careful screening. What would also be good is to have something (osc command) where the repo-wide maintainer could really remove a package from a repo and also clean the files located on download.o.o. I have tried to use wipebinaries, but this is quite complicated and works not always. The two examples could be removed from OBS, but they would still leave some files behind on d.o.o
[*] However the adding of synaptiks to factory seems to have meant it has disappeared from Community and therefore is currently not built for 11.2+4.3.x users :-(
You can copy it back and build it only for build repositories which do not include it from KKFD yet. I assume that would be similar also for the packages above that you suggest should be removed.
As far as I know, Synaptics is not building anymore for 4.3.x users. This would always be the difficulty where we have packages evolving together with the KDE releases and no longer being downwards compatible. The question could become one day that we have version x from a package that builds for 4.3.x and 4.4.x, but the newer version y does no longer build for 4.3.x. What would be then the logic ? Keep version x as that it builds for the larger audience or move to version y and disable the builds for 4.3.x ? Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Samstag, 10. April 2010 19:32:15 schrieb Raymond Wooninck:
On 04/09/2010 04:06 PM, Lubos Lunak wrote:
So what I propose is that KDE:Extra is created and the workflow is not
free-for-all. I.e. repo-wide maintainers are not handed out to everybody but only to some people with certain trust and experience. And by that I don't mean that I myself want to rule the repo with an iron hand, but this should simply assure certain review and prevent obvious screwups like the recent libqt4 inclusion in KDE:KDE4:Community. Repo-wide maintainers would be people willing to take care of the repo as a whole.
Why do we not follow the setup that openSUSE as a distribution has ? We have the standard repo's (Stable, Factory and Unstable) and then we could have a Contrib repo instead of the Community repo. o:F:Contrib (or 11.2:Contrib) serves the same purpose as that it should offer packages created by the community to enhance what is delivered from the Standard. Contrib alos follows a more strict ruling as that it knows repo-wide maintainers and package-specific maintainers.
Hmm Contrib will be frozen from time to time, still I like the idea, for Backports you could always build the Contrib:Factory for 11.2 as well etc. Though I don't really know the current situation of :Contrib, I know it was planned to merge with Factory but that was dropped. So is it there to stay? Anything else to say, like currently only few maintainers or similar?
The question could become one day that we have version x from a package that builds for 4.3.x and 4.4.x, but the newer version y does no longer build for 4.3.x. What would be then the logic ? Keep version x as that it builds for the larger audience or move to version y and disable the builds for 4.3.x ?
The Contrib structure would sort that out, we could make multiple Contrib repos like currently done in the main Contrib repo (version of 11.1, 11.2, Factory). Though this is of course generating more maintainer work =/
Regards
Raymond
Cheers! Karsten -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 04/11/2010 11:09 AM, Karsten König wrote:
Hmm Contrib will be frozen from time to time, still I like the idea, for Backports you could always build the Contrib:Factory for 11.2 as well etc. Though I don't really know the current situation of :Contrib, I know it was planned to merge with Factory but that was dropped. So is it there to stay? Anything else to say, like currently only few maintainers or similar?
As far as I know Contrib is still there to stay, but I am not well informed around this topic :-) However my idea was purely to follow the naming convention and initially a Contrib repo per KDE version.
The Contrib structure would sort that out, we could make multiple Contrib repos like currently done in the main Contrib repo (version of 11.1, 11.2, Factory). Though this is of course generating more maintainer work =/
Well, is this something that we really want ? As indicated I brought Contrib up for naming conventions, but not necessary to follow the exact structure setup. Although it would make sense if we want to provide people with a stable setup. We could say that we have KDE4:Stable and KDE4:Stable:Contrib which are frozen (except serious bugs, security issues, etc). That way it would not be too much work. In my opinion Backports and Playground should stay as they are now (single repo setup for all KDE versions). In Playground we could have more maintainers as that there everything would be theoretically possible. The Contrib repo should be mainly based on SR requests, which are accepted by the repo-wide maintainers. We could have then a few other people maintaining specific packages (e.g. midi-related, etc). Cheers Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (12)
-
Adrian Schröter -
Karsten König -
Lubos Lunak -
Markus -
Martin Schlander -
P Linnell -
Patrick Shanahan -
Pedro Lopez-Cabanillas -
Rajko M. -
Raymond Wooninck -
Richard Bos -
Tejas Guruswamy