Hello,
I have the AI from the last meeting to sum up the new structure and naming here before we do a poll about the choices, so here it goes. According to the discussion the repositories should be reorganized this way, with the following names and purpose:
(note: KKFD = KDE:KDE4:Factory:Desktop, o:F = openSUSE:Factory)
- backports repository - name KDE:Backports, it contains latest versions of KDE applications that are usable of any supported openSUSE release and do not require newer KDE platform. In other words, all applications from the factory development repo (current KKFD) but built against the distributions instead of against KKFD. This repository is offered in repositories list in YaST. Technically, this repo will only contain links to openSUSE:Factory for the packages. Maintainers of the repository shouldn't need to do more than enable/disable build and 'osc linkrev' to update to newer versions (the links will point to specific revisions of o:F packages to avoid beta packages appearing in KDE:Backports when they get submitted to o:F).
- unstable repository - name KDE:UNSTABLE, currently KDE:KDE4:UNSTABLE:Desktop. Basically, SVN upstream snapshots, that's it.
- development repository - current KDE:KDE4:Factory:Desktop, suggested name KDE:Distribution:Factory or others (see below). This repository contains all packages maintained by the KDE team that are in o:F. Note that KDE team does not mean just Will and me.
- stable repository - current KDE:KDE4:STABLE:Desktop, suggested name KDE:Distribution:STABLE or others (see below). Contains all packages maintained by the KDE team that are in the latest stable openSUSE release. In other words, when there is a new distribution release, contents of the above (~KKFD) repo get copied here and the repo is used for preparing online updates and similar.
- additional packages repository - suggested name KDE:Extra or others (see below), for packages which are not in o:F (like current KDE:KDE4:Community but hopefully without the random state of things). This repository is offered in repositories list in YaST. Only stable releases of packages are allowed here, or a reasonably stable beta release if an official stable release is not available. Repository-wide maintaners are only people who maintain the repository as a whole. People willing to contribute packages will do submit requests that will be reviewed by maintainers, when trusted enough they get maintainership only for their package(s). Current KDE:KDE4:Community will be eventually deleted after packages are moved to this new repository (not necessarily all of them).
- playground repository - name KDE:Playground, contains any KDE packages without any guarantee (alpha versions, whatever). Not as strongly reviewed and maintained as the other repositories (I don't know what the best way to handle this in practice would be, depends also on manpower, but I think there still should be only few repo-wide maintainers who would give package maintainership to others).
That's all as far as the reorganization goes. This will be done before 11.3 is released, we will try to keep links for backwards compatibility for some (unknown time). Please review and comment/fix/etc.
Also please raise your hand again if you'd be willing to do a repository maintainer for any of these. There were several people for KDE:Backports (where it should be pretty simple) and KDE:Extra stepping up during the meeting, so I'd like just to have a written overview here.
Naming: Since we are already going to do repository renaming to e.g. remove 'Community' from the name of the repository with additional packages to avoid suggesting that it is the only repository where community can contribute, we decided to do it all at once and also do other renaming to fix other problems with repository naming. For example, in KDE:KDE4:Factory:Desktop the 'KDE4' is superfluous and 'Desktop' is just a part of the contents, and we could use a better word than 'Factory' to suggest that it is packages that will be in the distribution.
Therefore, here is a list of names that were proposed during the meeting. For some the consensus seemed clear, so there is just one, but feel free to suggest other options there too.
- backports: - KDE:Backports - unstable: - KDE:UNSTABLE - KDE:Unstable - development: - KDE:Distribution:Factory - KDE:Distro:Factory - KDE:Base:Factory - (KDE:SC:Factory is not listed as the contents are not just KDE Software Compilation) - ? - stable: - KDE:Distribution:STABLE - replace 'Distribution' with all choices above for it, and STABLE can again get different capitalization - ? - additional: - KDE:Extra - KDE:Contrib (this is not very liked, as it has similar implications like 'Community') - playground: - KDE:Playground
After feedback (or if there is none :) ), I will create polls for the possibilities and best names will be chosen. After that, we will create the new structure, setup maintainers for the repos and start moving contents.
On Tuesday 27 April 2010 17:46:19 Lubos Lunak wrote:
Also please raise your hand again if you'd be willing to do a repository maintainer for any of these. There were several people for KDE:Backports (where it should be pretty simple) and KDE:Extra stepping up during the meeting, so I'd like just to have a written overview here.
Hi Lubos,
As discussed in the meeting already, you can put me up for maintenance ship for KDE:Extra and KDE:Playground. If you need a helping hand with KDE:.....:Factory, just let me know :-)
Regards
Raymond
Tirsdag den 27. april 2010 17:46:19 skrev Lubos Lunak:
- unstable repository - name KDE:UNSTABLE, currently
KDE:KDE4:UNSTABLE:Desktop. Basically, SVN upstream snapshots, that's it.
- unstable:
- KDE:UNSTABLE
- KDE:Unstable
Are you deliberately excluding the "Distribution" middle part for Unstable? I think it's desirable to have the various "base flavours" (stable, factory, unstable) "grouped together", and separated a little bit from the "add-on" repos (extra, playground, backports).
If the reason is that Unstable isn't strictly Distribution related - then I'd prefer "Core" or "Base" for the middle part, instead of "Distribution", to allow the three flavours being grouped.
On Tuesday 27 of April 2010, Martin Schlander wrote:
Tirsdag den 27. april 2010 17:46:19 skrev Lubos Lunak:
- unstable repository - name KDE:UNSTABLE, currently
KDE:KDE4:UNSTABLE:Desktop. Basically, SVN upstream snapshots, that's it.
- unstable:
- KDE:UNSTABLE
- KDE:Unstable
Are you deliberately excluding the "Distribution" middle part for Unstable? I think it's desirable to have the various "base flavours" (stable, factory, unstable) "grouped together", and separated a little bit from the "add-on" repos (extra, playground, backports).
Yes, it was deliberately suggested to be removed during the meeting (after 16:56 in the transcript). I think this depends a lot on Dirk and Raymond whether they want this repo to be seen as belonging together with the other two.
If the reason is that Unstable isn't strictly Distribution related - then I'd prefer "Core" or "Base" for the middle part, instead of "Distribution", to allow the three flavours being grouped.
On Tue, Apr 27, 2010 at 11:46 AM, Lubos Lunak l.lunak@suse.cz wrote:
Hello,
I have the AI from the last meeting to sum up the new structure and naming here before we do a poll about the choices, so here it goes. According to the discussion the repositories should be reorganized this way, with the following names and purpose:
(note: KKFD = KDE:KDE4:Factory:Desktop, o:F = openSUSE:Factory)
- backports repository - name KDE:Backports, it contains latest versions of
KDE applications that are usable of any supported openSUSE release and do not require newer KDE platform. In other words, all applications from the factory development repo (current KKFD) but built against the distributions instead of against KKFD. This repository is offered in repositories list in YaST. Technically, this repo will only contain links to openSUSE:Factory for the packages. Maintainers of the repository shouldn't need to do more than enable/disable build and 'osc linkrev' to update to newer versions (the links will point to specific revisions of o:F packages to avoid beta packages appearing in KDE:Backports when they get submitted to o:F).
- unstable repository - name KDE:UNSTABLE, currently
KDE:KDE4:UNSTABLE:Desktop. Basically, SVN upstream snapshots, that's it.
- development repository - current KDE:KDE4:Factory:Desktop, suggested name
KDE:Distribution:Factory or others (see below). This repository contains all packages maintained by the KDE team that are in o:F. Note that KDE team does not mean just Will and me.
- stable repository - current KDE:KDE4:STABLE:Desktop, suggested name
KDE:Distribution:STABLE or others (see below). Contains all packages maintained by the KDE team that are in the latest stable openSUSE release. In other words, when there is a new distribution release, contents of the above (~KKFD) repo get copied here and the repo is used for preparing online updates and similar.
- additional packages repository - suggested name KDE:Extra or others (see
below), for packages which are not in o:F (like current KDE:KDE4:Community but hopefully without the random state of things). This repository is offered in repositories list in YaST. Only stable releases of packages are allowed here, or a reasonably stable beta release if an official stable release is not available. Repository-wide maintaners are only people who maintain the repository as a whole. People willing to contribute packages will do submit requests that will be reviewed by maintainers, when trusted enough they get maintainership only for their package(s). Current KDE:KDE4:Community will be eventually deleted after packages are moved to this new repository (not necessarily all of them).
- playground repository - name KDE:Playground, contains any KDE packages
without any guarantee (alpha versions, whatever). Not as strongly reviewed and maintained as the other repositories (I don't know what the best way to handle this in practice would be, depends also on manpower, but I think there still should be only few repo-wide maintainers who would give package maintainership to others).
That's all as far as the reorganization goes. This will be done before 11.3 is released, we will try to keep links for backwards compatibility for some (unknown time). Please review and comment/fix/etc.
Also please raise your hand again if you'd be willing to do a repository maintainer for any of these. There were several people for KDE:Backports (where it should be pretty simple) and KDE:Extra stepping up during the meeting, so I'd like just to have a written overview here.
Naming: Since we are already going to do repository renaming to e.g. remove 'Community' from the name of the repository with additional packages to avoid suggesting that it is the only repository where community can contribute, we decided to do it all at once and also do other renaming to fix other problems with repository naming. For example, in KDE:KDE4:Factory:Desktop the 'KDE4' is superfluous and 'Desktop' is just a part of the contents, and we could use a better word than 'Factory' to suggest that it is packages that will be in the distribution.
Therefore, here is a list of names that were proposed during the meeting. For some the consensus seemed clear, so there is just one, but feel free to suggest other options there too.
- backports:
- KDE:Backports
- unstable:
- KDE:UNSTABLE - KDE:Unstable
- development:
- KDE:Distribution:Factory - KDE:Distro:Factory - KDE:Base:Factory - (KDE:SC:Factory is not listed as the contents are not just KDE Software Compilation) - ?
- stable:
- KDE:Distribution:STABLE - replace 'Distribution' with all choices above for it, and STABLE can again get different capitalization - ?
- additional:
- KDE:Extra - KDE:Contrib (this is not very liked, as it has similar implications like 'Community')
- playground:
- KDE:Playground
After feedback (or if there is none :) ), I will create polls for the possibilities and best names will be chosen. After that, we will create the new structure, setup maintainers for the repos and start moving contents.
A couple comments:
I agree with Martin that Unstable should be in the same directory as Stable and Development.
I have never liked the inconsistent capitalization in the repository names. I think you should stick to one capitalization convention.
What is happening with the KDE 3 repos? The backports directory is only going to allow KDE 4 applications, right? I think that needs to be made clear either way.
I assume there are still going to be Stable, Unstable, and Factory versions of Extra and Playground? If so I think they should follow the same layout pattern as the Distribution directory. So like this:
KDE:Backports KDE:Distribution:Factory KDE:Distribution:Stable KDE:Distribution:Unstable KDE:Extra:Factory KDE:Extra:Stable KDE:Extra:Unstable KDE:Playground:Factory KDE:Playground:Stable KDE:Playground:Unstable
This is because, once again, I never really liked the inconsistent naming between the Desktop and Community/Playground sub-directories. Further, how we have Community and Playground now with one big directory containing 3 versions of each directory for each version of openSUSE leads to a huge directory and really long file names. Backports is excluded from this, of course.
Finally, I might consider "Experimental" instead of "Playground". I would also consider "Development" and/or "Next" as options in the poll in addition to "Factory".
-Todd
On Tuesday 27 of April 2010, todd rme wrote:
What is happening with the KDE 3 repos? The backports directory is only going to allow KDE 4 applications, right? I think that needs to be made clear either way.
KDE:KDE3 stays in its current unsupported way. The other KDE3-based repos can go (unless, of course, somebody would take care of them, but that means in practice that they can go).
I assume there are still going to be Stable, Unstable, and Factory versions of Extra and Playground?
Neither KDE:KDE4:Community nor KDE:KDE4:Playground have that now, and I seriously doubt people work find it worth the effort. Besides, Extra:Unstable is Playground and Playground:Stable is Extra and since the packages are not in the distribution I don't see a reason for the split.
This is because, once again, I never really liked the inconsistent naming between the Desktop and Community/Playground sub-directories. Further, how we have Community and Playground now with one big directory containing 3 versions of each directory for each version of openSUSE leads to a huge directory and really long file names. Backports is excluded from this, of course.
I think you are confusing the repository itself (what it contains) and build repositories (what it is built against).
Yes, it was deliberately suggested to be removed during the meeting (after 16:56 in the transcript). I think this depends a lot on Dirk and Raymond whether they want this repo to be seen as belonging together with the other two.
I think keeping it consistent is important, both for users and for making it easier to maintain. If you think Unstable doesn't belong under the heading "Distribution", then I would think changing the name of the folder as Martin suggested would be preferable to making a single special case that is inconsistent. In terms of its contents and purpose I think Unstable is basically the same as Factory and Stable.
I think having it in the same sub-directory as Stable and Factory makes 2 things clear to users that I think would not be clear otherwise. First, it makes it clear that Unstable is not just a generic place to put unstable packages, Unstable is specifically for an unstable set of core KDE packages. Second, putting them all together makes it more clear that you would only want to have Factory, Stable, or Unstable enabled at any one time.
I think putting Unstable in a different place than Factory and Stable would make it seem to users that it is somehow fundamentally different, when really it just contains a different version of the same basic packages (plus or minus some package changes between KDE versions, but Factory has the same issue). There is also the issue that at certain points Unstable moves to Factory (usually around the first RC release, if I recall correctly), so putting them together seems logical to me.
So to summarize, I think that if there is a problem with the naming, I think it is better to fix the naming rather than break the folder structure.
On Wed, Apr 28, 2010 at 11:18 AM, Lubos Lunak l.lunak@suse.cz wrote:
On Tuesday 27 of April 2010, todd rme wrote:
What is happening with the KDE 3 repos? The backports directory is only going to allow KDE 4 applications, right? I think that needs to be made clear either way.
KDE:KDE3 stays in its current unsupported way. The other KDE3-based repos can go (unless, of course, somebody would take care of them, but that means in practice that they can go).
What about backports? Is it only going to contain KDE 4 application or is it going to continue to have KDE 3 applications as well? If there are going to continue to be KDE 3 applications for which there is no KDE 4 alternative, I would prefer there to be a separate KDE 3 repo, such as KDE:Legacy, for such applications, rather than having backports containing a mix of KDE 3 and KDE 4 applications like it does now.
This is because, once again, I never really liked the inconsistent naming between the Desktop and Community/Playground sub-directories. Further, how we have Community and Playground now with one big directory containing 3 versions of each directory for each version of openSUSE leads to a huge directory and really long file names. Backports is excluded from this, of course.
I think you are confusing the repository itself (what it contains) and build repositories (what it is built against).
Perhaps I am. Whatever the reason, currently, for instance, the Community repository has these directories in it:
Community/openSUSE_11.0/ Community/openSUSE_11.0_KDE4_Factory_Desktop/ Community/openSUSE_11.0_KDE4_UNSTABLE_Desktop/ Community/openSUSE_11.1/ Community/openSUSE_11.1_KDE4_Factory_Desktop/ Community/openSUSE_11.1_KDE4_UNSTABLE_Desktop/ Community/openSUSE_11.2/ Community/openSUSE_11.2_KDE4_Factory_Desktop/ Community/openSUSE_11.2_KDE4_UNSTABLE_Desktop/ Community/openSUSE_Factory/ Community/openSUSE_Factory_KDE4_UNSTABLE_Desktop/
Before long there will also be 11.3 versions, adding another 3 folders. I think this is needlessly complicated and inconsistent with how the core KDE repositories are laid out (what is called Distribution under the proposal we have). I am suggesting it be like this:
Community/Stable/openSUSE_11.0/ Community/Stable/openSUSE_11.1/ Community/Stable/openSUSE_11.2/ Community/Stable/openSUSE_Factory/ Community/Factory/openSUSE_11.0/ Community/Factory/openSUSE_11.1/ Community/Factory/openSUSE_11.2/ Community/Unstable/openSUSE_11.0/ Community/Unstable/openSUSE_11.1/ Community/Unstable/openSUSE_11.2/ Community/Unstable/openSUSE_Factory/
I know that Stable/, Factory/, and Unstable/ will all have the same packages (well, Stable might not because some community packages might not be compatible with the stable KDE from older openSUSE versions). But I think, even if all of the packages are the same (just built against different target) I still think it would be better to organize it this way to maintain consistency and to avoid a needlessly long and complicated folder with needlessly long and complicated names.
-Todd
Torsdag den 29. april 2010 18:52:13 skrev todd rme:
What about backports? Is it only going to contain KDE 4 application or is it going to continue to have KDE 3 applications as well? If there are going to continue to be KDE 3 applications for which there is no KDE 4 alternative, I would prefer there to be a separate KDE 3 repo, such as KDE:Legacy, for such applications, rather than having backports containing a mix of KDE 3 and KDE 4 applications like it does now.
KDE3 apps would only be relevant in Backports if a KDE3 app which is still included in the official distro would make a new release. Does that really still happen?
If it does then such a release should go to Backports.
On Thu, Apr 29, 2010 at 3:16 PM, Martin Schlander martin.schlander@gmail.com wrote:
Torsdag den 29. april 2010 18:52:13 skrev todd rme:
What about backports? Is it only going to contain KDE 4 application or is it going to continue to have KDE 3 applications as well? If there are going to continue to be KDE 3 applications for which there is no KDE 4 alternative, I would prefer there to be a separate KDE 3 repo, such as KDE:Legacy, for such applications, rather than having backports containing a mix of KDE 3 and KDE 4 applications like it does now.
KDE3 apps would only be relevant in Backports if a KDE3 app which is still included in the official distro would make a new release. Does that really still happen?
If it does then such a release should go to Backports.
At least as an example, kscope is a KDE3 app and is currently in factory. At the very least I think they should probably have KDE3- in front of them so that people know easily that it is a KDE3 application. Currently there is no way to differentiate KDE3 from KDE4 apps without browsing the dependencies, and only then if you know what to look for. It is currently not very easy for people trying to avoid installing KDE3 applications (which would, in turn, pull in KDE3 libraries).
-Todd
Torsdag den 29. april 2010 21:30:39 skrev todd rme:
At least as an example, kscope is a KDE3 app and is currently in factory. At the very least I think they should probably have KDE3- in front of them so that people know easily that it is a KDE3 application. Currently there is no way to differentiate KDE3 from KDE4 apps without browsing the dependencies, and only then if you know what to look for. It is currently not very easy for people trying to avoid installing KDE3 applications (which would, in turn, pull in KDE3 libraries).
Sounds like a "bug".
It was already decided long ago that kde3-stuff should be prefixed with kde3. And kde4 prefix should only be used in special cases such as 'kde4- filesystem', where the name would be pretty useless without the prefix.
On Thursday 29 of April 2010, todd rme wrote:
Yes, it was deliberately suggested to be removed during the meeting (after 16:56 in the transcript). I think this depends a lot on Dirk and Raymond whether they want this repo to be seen as belonging together with the other two.
I think keeping it consistent is important, both for users and for making it easier to maintain. If you think Unstable doesn't belong under the heading "Distribution", then I would think changing the name of the folder as Martin suggested would be preferable to making a single special case that is inconsistent. In terms of its contents and purpose I think Unstable is basically the same as Factory and Stable.
I think having it in the same sub-directory as Stable and Factory makes 2 things clear to users that I think would not be clear otherwise. First, it makes it clear that Unstable is not just a generic place to put unstable packages, Unstable is specifically for an unstable set of core KDE packages. Second, putting them all together makes it more clear that you would only want to have Factory, Stable, or Unstable enabled at any one time.
I think putting Unstable in a different place than Factory and Stable would make it seem to users that it is somehow fundamentally different, when really it just contains a different version of the same basic packages (plus or minus some package changes between KDE versions, but Factory has the same issue).
That is the question. Unstable can be seen as Factory with the latest upstream snapshot, but it can be also seen as the latest upstream snapshot with some more packages added. If it's the sooner, Unstable should be kept with Stable and Factory, if it's the latter and it won't follow Factory closely, then IMO it should be kept separately.
Dirk, Raymond: Which of those two should it be?
There is also the issue that at certain points Unstable moves to Factory (usually around the first RC release, if I recall correctly)
It doesn't, Factory is always the ultimate development repository, at most taking some changes from Unstable that are needed for newer KDE versions.
On Wed, Apr 28, 2010 at 11:18 AM, Lubos Lunak l.lunak@suse.cz wrote:
On Tuesday 27 of April 2010, todd rme wrote:
What is happening with the KDE 3 repos? The backports directory is only going to allow KDE 4 applications, right? I think that needs to be made clear either way.
KDE:KDE3 stays in its current unsupported way. The other KDE3-based repos can go (unless, of course, somebody would take care of them, but that means in practice that they can go).
What about backports? Is it only going to contain KDE 4 application or is it going to continue to have KDE 3 applications as well? If there are going to continue to be KDE 3 applications for which there is no KDE 4 alternative, I would prefer there to be a separate KDE 3 repo, such as KDE:Legacy, for such applications, rather than having backports containing a mix of KDE 3 and KDE 4 applications like it does now.
KDE:Backports contains backports of latest KDE apps from openSUSE:Factory, and given that there are almost no KDE3 apps by now, this point is almost moot. As for a separate repository for such KDE3 apps, it's the same like with KDE:KDE3 - there's first somebody who'd take care of the repository needed, and we all know how it is with people who'd actually do some work with KDE3.
This is because, once again, I never really liked the inconsistent naming between the Desktop and Community/Playground sub-directories. Further, how we have Community and Playground now with one big directory containing 3 versions of each directory for each version of openSUSE leads to a huge directory and really long file names. Backports is excluded from this, of course.
I think you are confusing the repository itself (what it contains) and build repositories (what it is built against).
Perhaps I am. Whatever the reason, currently, for instance, the Community repository has these directories in it:
...
Community/openSUSE_11.2/ Community/openSUSE_11.2_KDE4_Factory_Desktop/ Community/openSUSE_11.2_KDE4_UNSTABLE_Desktop/
A repository is where the sources for what will be built are. A build repository is for what the sources are built. So here is a repository called Community that contains various packages and they are built in the first case for plain 11.2, in the second case for 11.2 with KKFD added, etc.
...
Before long there will also be 11.3 versions, adding another 3 folders. I think this is needlessly complicated and inconsistent with how the core KDE repositories are laid out (what is called Distribution under the proposal we have). I am suggesting it be like this:
...
Community/Stable/openSUSE_11.2/
Which means you cannot have this, there is no third component. It also actually does not make sense, there is no stable, factory or unstable Community, there is just Community and it is build for just (each of) one build repository.
On Friday 30 April 2010 17:11:07 Lubos Lunak wrote:
That is the question. Unstable can be seen as Factory with the latest upstream snapshot, but it can be also seen as the latest upstream snapshot with some more packages added. If it's the sooner, Unstable should be kept with Stable and Factory, if it's the latter and it won't follow Factory closely, then IMO it should be kept separately.
Dirk, Raymond: Which of those two should it be?
In my opinion I think it would be the latter. Unstable is constantly based on the KDE trunk with weekly snapshots. Also support packages (e.g. akonadi, soprano, etc) are updated with later snapshots as required. I am trying to keep as much as possible the openSUSE specific patches, but the main target is to get the package build. So in the process one or more patches might get lost.
I wanted already to discuss this topic with Dirk to see if we can really disconnect Factory and Unstable with regards to the support packages. It is quite often that we have broken packages in Unstable, just because of a small change. This despite that we already have a higher version in Unstable.
As you also mentioned further, Factory is taking some changes from Unstable, but Unstable is not a development repository where we are preparing the next KDE version for a new openSUSE version.
So personally I would welcome a clear split.
Dirk, any opinion from your side ?
Raymond
On Friday 30 April 2010, Lubos Lunak wrote:
That is the question. Unstable can be seen as Factory with the latest upstream snapshot, but it can be also seen as the latest upstream snapshot with some more packages added. If it's the sooner, Unstable should be kept with Stable and Factory, if it's the latter and it won't follow Factory closely, then IMO it should be kept separately.
Dirk, Raymond: Which of those two should it be?
When it started, it was supposed to be the Factory packages with latest upstream snapshots. Meanwhile, since Raymond is doing the work almost exclusively without my intervention or help, he redefined the purpose of KKUD to be independent from Factory packaging, just have the latest upstream development available (plus additional packages that he considers fitting into the repo).
I am personally not very touched to either of the two options, those who do the work should decide. While I tried to keep packaging (splitting, package names etc) similar to KKFD to make it a drop-in replacement that users can switch to, it has turned out to be a somewhat of a pain, so I'm fine with letting it go and packaging it differently if that is better.
Therefore I think leaving out the :Distribution: is a good idea.
Greetings, Dirk
On Tuesday 18 May 2010 11:46:21 Dirk Müller wrote:
When it started, it was supposed to be the Factory packages with latest upstream snapshots. Meanwhile, since Raymond is doing the work almost exclusively without my intervention or help, he redefined the purpose of KKUD to be independent from Factory packaging, just have the latest upstream development available (plus additional packages that he considers fitting into the repo).
I am still trying to keep the Factory structure (meaning spec-files and patches) as much as possible. As you already indicated it would be good to have already the learning for the next KDE release in the KKUD, so that with minor efforts the packages could be transferred to KKFD.
Based on some requests from the community I have tried to have the full KDE functionality available by adding optional packages to the Build Requirements. Also it seems that KDE trunk is getting more and more additional required packages (e.g. grantlee library to build kjots, etc).
I agree with you to take the :Distribution part out of the name.
Regards
Raymond
Tirsdag den 18. maj 2010 14:17:02 skrev Raymond Wooninck:
On Tuesday 18 May 2010 11:46:21 Dirk Müller wrote:
When it started, it was supposed to be the Factory packages with latest upstream snapshots. Meanwhile, since Raymond is doing the work almost exclusively without my intervention or help, he redefined the purpose of KKUD to be independent from Factory packaging, just have the latest upstream development available (plus additional packages that he considers fitting into the repo).
I am still trying to keep the Factory structure (meaning spec-files and patches) as much as possible. As you already indicated it would be good to have already the learning for the next KDE release in the KKUD, so that with minor efforts the packages could be transferred to KKFD.
Based on some requests from the community I have tried to have the full KDE functionality available by adding optional packages to the Build Requirements. Also it seems that KDE trunk is getting more and more additional required packages (e.g. grantlee library to build kjots, etc).
I agree with you to take the :Distribution part out of the name.
But then how about replacing "Distribution" with something else. Like "Base" or "Core" or "Main" or whatever. So that we can keep the repos with the basic stuff (stable, factory, unstable) grouped together _and_ separated from the add-on repos (extra, playground, backports).
On Tuesday 18 of May 2010, Martin Schlander wrote:
Tirsdag den 18. maj 2010 14:17:02 skrev Raymond Wooninck:
On Tuesday 18 May 2010 11:46:21 Dirk Müller wrote:
When it started, it was supposed to be the Factory packages with latest upstream snapshots. Meanwhile, since Raymond is doing the work almost exclusively without my intervention or help, he redefined the purpose of KKUD to be independent from Factory packaging, just have the latest upstream development available (plus additional packages that he considers fitting into the repo).
I am still trying to keep the Factory structure (meaning spec-files and patches) as much as possible. As you already indicated it would be good to have already the learning for the next KDE release in the KKUD, so that with minor efforts the packages could be transferred to KKFD.
Based on some requests from the community I have tried to have the full KDE functionality available by adding optional packages to the Build Requirements. Also it seems that KDE trunk is getting more and more additional required packages (e.g. grantlee library to build kjots, etc).
I agree with you to take the :Distribution part out of the name.
But then how about replacing "Distribution" with something else. Like "Base" or "Core" or "Main" or whatever. So that we can keep the repos with the basic stuff (stable, factory, unstable) grouped together _and_ separated from the add-on repos (extra, playground, backports).
Isn't the whole point of what's written above _not_ to keep Unstable grouped together with Stable/Factory?
Tirsdag den 18. maj 2010 16:20:16 skrev Lubos Lunak:
On Tuesday 18 of May 2010, Martin Schlander wrote:
Tirsdag den 18. maj 2010 14:17:02 skrev Raymond Wooninck:
On Tuesday 18 May 2010 11:46:21 Dirk Müller wrote:
When it started, it was supposed to be the Factory packages with latest upstream snapshots. Meanwhile, since Raymond is doing the work almost exclusively without my intervention or help, he redefined the purpose of KKUD to be independent from Factory packaging, just have the latest upstream development available (plus additional packages that he considers fitting into the repo).
I am still trying to keep the Factory structure (meaning spec-files and patches) as much as possible. As you already indicated it would be good to have already the learning for the next KDE release in the KKUD, so that with minor efforts the packages could be transferred to KKFD.
Based on some requests from the community I have tried to have the full KDE functionality available by adding optional packages to the Build Requirements. Also it seems that KDE trunk is getting more and more additional required packages (e.g. grantlee library to build kjots, etc).
I agree with you to take the :Distribution part out of the name.
But then how about replacing "Distribution" with something else. Like "Base" or "Core" or "Main" or whatever. So that we can keep the repos with the basic stuff (stable, factory, unstable) grouped together _and_ separated from the add-on repos (extra, playground, backports).
Isn't the whole point of what's written above _not_ to keep Unstable grouped together with Stable/Factory?
No, I think the point is not to associate Unstable closely with the distribution, which makes some sense.
But not grouping repos that contain different flavours of basically the same stuff, does not make sense. That just makes it more confusing and increases the risk of people mixing incompatible repos imo.
On Tuesday 18 of May 2010, Martin Schlander wrote:
Tirsdag den 18. maj 2010 16:20:16 skrev Lubos Lunak:
On Tuesday 18 of May 2010, Martin Schlander wrote:
Tirsdag den 18. maj 2010 14:17:02 skrev Raymond Wooninck:
I agree with you to take the :Distribution part out of the name.
But then how about replacing "Distribution" with something else. Like "Base" or "Core" or "Main" or whatever. So that we can keep the repos with the basic stuff (stable, factory, unstable) grouped together _and_ separated from the add-on repos (extra, playground, backports).
Isn't the whole point of what's written above _not_ to keep Unstable grouped together with Stable/Factory?
No, I think the point is not to associate Unstable closely with the distribution, which makes some sense.
That wasn't my question, although now I see I probably wasn't entirely clear on that. The question was whether KKUD is something that belongs together with KKSD/KKFD or not, not whether it belongs in the distribution.
But not grouping repos that contain different flavours of basically the same stuff, does not make sense. That just makes it more confusing and increases the risk of people mixing incompatible repos imo.
First of all, I think somebody installing from a repo called "Unstable" and then getting confused by the fact that it is broken is just dimwitted by definition and should not touch it anyway. Which is just one more reason to move it completely away from KKSD/KKFD so that such people don't try it.
Additionally, we've already talked at least once in the past that it would be nice if it actually was possible to install KKUD alongside normal install, for various reasons like testing whether a bug still exists upstream without having to completely break the stable KDE installation. There again a separation would help.
Finally, KKUD is not the same stuff like KKFD. KKFD is KDE SC + random apps that are in the distro, but KKUD is KDE SC + whatever it needs, and it doesn't need to have all those apps.
Tirsdag den 18. maj 2010 16:56:22 skrev Lubos Lunak:
On Tuesday 18 of May 2010, Martin Schlander wrote:
But not grouping repos that contain different flavours of basically the same stuff, does not make sense. That just makes it more confusing and increases the risk of people mixing incompatible repos imo.
First of all, I think somebody installing from a repo called "Unstable" and then getting confused by the fact that it is broken is just dimwitted by definition and should not touch it anyway. Which is just one more reason to move it completely away from KKSD/KKFD so that such people don't try it.
But by moving it away from Stable and Factory you are placing it in the root of the project instead, alongside the "add-on" repos with leaf packages only (backports, playground and extra).
And I expect that will confuse people.
"What's the difference between playground and unstable?"
"Hi, I'm using Factory KDE with Unstable version of Amarok, why doesn't it work?"
.. and so forth.
On Tuesday 18 May 2010, Martin Schlander wrote:
But by moving it away from Stable and Factory you are placing it in the root of the project instead, alongside the "add-on" repos with leaf packages only (backports, playground and extra).
And I expect that will confuse people.
"What's the difference between playground and unstable?"
"Hi, I'm using Factory KDE with Unstable version of Amarok, why doesn't it work?"
You're raising a good point here. *sigh*. I suggest "Desktop" instead of "Distribution".
KDE:Desktop:Factory KDE:Desktop:UNSTABLE
I'm not sure that we really need to express the policy "only packages in opensuse:Factory are in KDE:*:Factory" by naming the project "Distribution". It seems like a nuiance to me.
Greetings, Dirk
On Thu, May 27, 2010 at 8:53 AM, Dirk Müller dmueller@suse.de wrote:
On Tuesday 18 May 2010, Martin Schlander wrote:
But by moving it away from Stable and Factory you are placing it in the root of the project instead, alongside the "add-on" repos with leaf packages only (backports, playground and extra).
And I expect that will confuse people.
"What's the difference between playground and unstable?"
"Hi, I'm using Factory KDE with Unstable version of Amarok, why doesn't it work?"
You're raising a good point here. *sigh*. I suggest "Desktop" instead of "Distribution".
KDE:Desktop:Factory KDE:Desktop:UNSTABLE
I'm not sure that we really need to express the policy "only packages in opensuse:Factory are in KDE:*:Factory" by naming the project "Distribution". It seems like a nuiance to me.
Greetings, Dirk
The problem is that this conflicts with the new KDE branding, where "desktop" refers to a specific implementation of the KDE workspace. It is also, in my opinion, a poor description of what the repository actually contains, since it contains a lot of software (Amarok, Koffice) that is neither part of the KDE SC releases nor is it related to the desktop or desktop environment in any meaningful way.
-Todd
On Thursday 27 May 2010, todd rme wrote:
The problem is that this conflicts with the new KDE branding, where "desktop" refers to a specific implementation of the KDE workspace.
Which is however the one we're building here (unlike the Netbook edition in some other KDE: project).
It is also, in my opinion, a poor description of what the repository actually contains, since it contains a lot of software (Amarok, Koffice) that is neither part of the KDE SC releases nor is it related to the desktop or desktop environment in any meaningful way.
There are addon packages like amarok or koffice that are not part of KDE Desktop module definition indeed.
We could add them to a different project as well. However, I'm not attached to the:Desktop: prefix at all, choose any other term that fits better.
Greetings, Dirk
On Thursday 27 May 2010 19:15:24 Dirk Müller wrote:
On Thursday 27 May 2010, todd rme wrote:
The problem is that this conflicts with the new KDE branding, where "desktop" refers to a specific implementation of the KDE workspace.
Which is however the one we're building here (unlike the Netbook edition in some other KDE: project).
We're not tied to that and actually, we're building plasma-netbook too, the only thing making plasma-desktop start by default is the upstream setup we ship. Since 'our' KDE repos are the feedstock for the KDE:Netbook project and should be for other projects, i don't think we should prematurely specialise them by naming.
It is also, in my opinion, a poor description of what the repository actually contains, since it contains a lot of software (Amarok, Koffice) that is neither part of the KDE SC releases nor is it related to the desktop or desktop environment in any meaningful way.
There are addon packages like amarok or koffice that are not part of KDE Desktop module definition indeed.
We could add them to a different project as well. However, I'm not attached to the:Desktop: prefix at all, choose any other term that fits better.
No problem then :)
Will
I seriously don't like the "STABLE" part. I'd rather see it replaced with "supported", "latestSUSE", or so. Even with "Distribution" in between, still lots of people will ask why it doesn't contain the latest KDE SC release.
Am Dienstag 27 April 2010 17:46:19 schrieb Lubos Lunak:
Hello,
I have the AI from the last meeting to sum up the new structure and naming here before we do a poll about the choices, so here it goes. According to the discussion the repositories should be reorganized this way, with the following names and purpose:
(note: KKFD = KDE:KDE4:Factory:Desktop, o:F = openSUSE:Factory)
- backports repository - name KDE:Backports, it contains latest versions of
KDE applications that are usable of any supported openSUSE release and do not require newer KDE platform. In other words, all applications from the factory development repo (current KKFD) but built against the distributions instead of against KKFD. This repository is offered in repositories list in YaST. Technically, this repo will only contain links to openSUSE:Factory for the packages. Maintainers of the repository shouldn't need to do more than enable/disable build and 'osc linkrev' to update to newer versions (the links will point to specific revisions of o:F packages to avoid beta packages appearing in KDE:Backports when they get submitted to o:F).
- unstable repository - name KDE:UNSTABLE, currently
KDE:KDE4:UNSTABLE:Desktop. Basically, SVN upstream snapshots, that's it.
- development repository - current KDE:KDE4:Factory:Desktop, suggested name
KDE:Distribution:Factory or others (see below). This repository contains all packages maintained by the KDE team that are in o:F. Note that KDE team does not mean just Will and me.
- stable repository - current KDE:KDE4:STABLE:Desktop, suggested name
KDE:Distribution:STABLE or others (see below). Contains all packages maintained by the KDE team that are in the latest stable openSUSE release. In other words, when there is a new distribution release, contents of the above (~KKFD) repo get copied here and the repo is used for preparing online updates and similar.
- additional packages repository - suggested name KDE:Extra or others (see
below), for packages which are not in o:F (like current KDE:KDE4:Community but hopefully without the random state of things). This repository is offered in repositories list in YaST. Only stable releases of packages are allowed here, or a reasonably stable beta release if an official stable release is not available. Repository-wide maintaners are only people who maintain the repository as a whole. People willing to contribute packages will do submit requests that will be reviewed by maintainers, when trusted enough they get maintainership only for their package(s). Current KDE:KDE4:Community will be eventually deleted after packages are moved to this new repository (not necessarily all of them).
- playground repository - name KDE:Playground, contains any KDE packages
without any guarantee (alpha versions, whatever). Not as strongly reviewed and maintained as the other repositories (I don't know what the best way to handle this in practice would be, depends also on manpower, but I think there still should be only few repo-wide maintainers who would give package maintainership to others).
That's all as far as the reorganization goes. This will be done before 11.3 is released, we will try to keep links for backwards compatibility for some (unknown time). Please review and comment/fix/etc.
Also please raise your hand again if you'd be willing to do a repository maintainer for any of these. There were several people for KDE:Backports (where it should be pretty simple) and KDE:Extra stepping up during the meeting, so I'd like just to have a written overview here.
Naming: Since we are already going to do repository renaming to e.g. remove 'Community' from the name of the repository with additional packages to avoid suggesting that it is the only repository where community can contribute, we decided to do it all at once and also do other renaming to fix other problems with repository naming. For example, in KDE:KDE4:Factory:Desktop the 'KDE4' is superfluous and 'Desktop' is just a part of the contents, and we could use a better word than 'Factory' to suggest that it is packages that will be in the distribution.
Therefore, here is a list of names that were proposed during the meeting. For some the consensus seemed clear, so there is just one, but feel free to suggest other options there too.
- backports:
- KDE:Backports
- unstable:
- KDE:UNSTABLE
- KDE:Unstable
- development:
- KDE:Distribution:Factory
- KDE:Distro:Factory
- KDE:Base:Factory
- (KDE:SC:Factory is not listed as the contents are not just KDE Software
Compilation)
- ?
- stable:
- KDE:Distribution:STABLE
- replace 'Distribution' with all choices above for it, and STABLE can
again get different capitalization
- ?
- additional:
- KDE:Extra
- KDE:Contrib (this is not very liked, as it has similar implications
like 'Community')
- playground:
- KDE:Playground
After feedback (or if there is none :) ), I will create polls for the possibilities and best names will be chosen. After that, we will create the new structure, setup maintainers for the repos and start moving contents.
On Tue, Apr 27, 2010 at 5:03 PM, Markus kamikazow@web.de wrote:
I seriously don't like the "STABLE" part. I'd rather see it replaced with "supported", "latestSUSE", or so. Even with "Distribution" in between, still lots of people will ask why it doesn't contain the latest KDE SC release.
Based on this line, a couple of more suggestions for names:
Stable: "supported" "latestSupported" Factory: "unsupported" "latestUnsupported" "latest"
-Todd
Guys, I think we forgot something: The KDE Platform's new profile system. http://ervin.ipsquad.net/2010/04/29/kde-platform-profiles-its-alive/
If we ignore this now, it'll come back at us in 6 or so months. So even if Build Service won't build all available profiles right from the start, because Novell isn't interested to create a Netbook, Smartphone, or Tablet variant of openSUSE, the repo structure should at very least support it if some community members step in an create a repo for KDE SC Mobile or so.
I don't know which profiles are available and how their names are exactly, but after reading the thread on kde-core-devel I guess it's Desktop, Netbook, Tablet, and Mobile (=Smartphone/Handheld).
This means, whatever the deeper subfolders will be called, there should be KDE:Desktop KDE:Netbook KDE:Tablet KDE:Mobile ...
Inside them there could be KDE:Desktop/Supported KDE:Desktop/Extra KDE:Desktop/Playground ...
Am Dienstag 27 April 2010 17:46:19 schrieb Lubos Lunak:
- backports:
- KDE:Backports
- unstable:
- KDE:UNSTABLE
- KDE:Unstable
- development:
- KDE:Distribution:Factory
- KDE:Distro:Factory
- KDE:Base:Factory
- (KDE:SC:Factory is not listed as the contents are not just KDE Software
Compilation)
- ?
- stable:
- KDE:Distribution:STABLE
- replace 'Distribution' with all choices above for it, and STABLE can
again get different capitalization
- ?
- additional:
- KDE:Extra
- KDE:Contrib (this is not very liked, as it has similar implications
like 'Community')
- playground:
- KDE:Playground
After feedback (or if there is none :) ), I will create polls for the possibilities and best names will be chosen. After that, we will create the new structure, setup maintainers for the repos and start moving contents.
On Friday 30 of April 2010, Markus wrote:
Guys, I think we forgot something: The KDE Platform's new profile system. http://ervin.ipsquad.net/2010/04/29/kde-platform-profiles-its-alive/
If we ignore this now, it'll come back at us in 6 or so months. So even if Build Service won't build all available profiles right from the start, because Novell isn't interested to create a Netbook, Smartphone, or Tablet variant of openSUSE, the repo structure should at very least support it if some community members step in an create a repo for KDE SC Mobile or so.
That is a rather big 'if'. I somehow can't quite imagine enough people to take care of tripple the amount of current repositories, so we might as well just end up with more complicated layout that is needlessly deep.
I don't know which profiles are available and how their names are exactly, but after reading the thread on kde-core-devel I guess it's Desktop, Netbook, Tablet, and Mobile (=Smartphone/Handheld).
This means, whatever the deeper subfolders will be called, there should be KDE:Desktop KDE:Netbook KDE:Tablet KDE:Mobile
The current structure actually does support this, in a way. The current profile is the default, and if one day there really will be people packaging other profiles, then KDE:Profile can be simply added as a specialization. I personally think that doing more would be thinking way too big.
On Friday 30 April 2010 10:33:28 Lubos Lunak wrote:
The current structure actually does support this, in a way. The current profile is the default, and if one day there really will be people packaging other profiles, then KDE:Profile can be simply added as a specialization. I personally think that doing more would be thinking way too big.
Gentlemen:
I would like to make an observation re; labeling. I understand the consternation the subject causes almost everyone. The problem with labels is the background of whoever is making and reading them. Simplicity is also the key and part of the problem.
Developers/programmers have a special language and words have specific, special meanings many of which are a foreign language to the common user. As an example think of what the term factory means to each . Factory to the user may mean the place you go to get the original whatsis. To the developer it may mean the place you go to get the latest play piece of the whatsis.
Confusion is the result.
Many users, who encounter the confusion simply say, screw it and go on to something else rather than get embroiled in some seemingly petty argument.
The solution is not really obvious. The choices are to create a new common language, or keep things as they are and explain things repeatedly, or seek the common meaning of terms and use them. Either may require having a document which defines the use of each term and provides a standard for the developer. If the greater number of readers are the users then the preferred method might be to use the common definition.
Since there is no 'Term God' that I know of, someone will have to step up and become Him, maybe?
My suggestion would be to adopt the common meaning rather than the special meanings to the developer.
Regardless, it's good to know you folks are at least addressing the problem of communications. I'll add my thanks to all of you for your unceasing efforts to improve the Linux experience.
Regards, Richard
Am Dienstag, 27. April 2010 17:46:19 schrieb Lubos Lunak:
- development:
- KDE:Distribution:Factory
- KDE:Distro:Factory
- KDE:Base:Factory
- (KDE:SC:Factory is not listed as the contents are not just KDE Software
Compilation)
- ?
Maybe we also should consider to rename the 'Factory'-part as this leads sometimes to confusion between openSUSE:Factory and KDE:...:Factory
Maybe one could use Testing instead of Factory this might also explain the purpose of this repository better to people not so familiar with openSUSE.
Christian
Fredag den 30. april 2010 09:55:33 skrev Christian Trippe:
Am Dienstag, 27. April 2010 17:46:19 schrieb Lubos Lunak:
- development:
Software
- KDE:Distribution:Factory
- KDE:Distro:Factory
- KDE:Base:Factory
- (KDE:SC:Factory is not listed as the contents are not just KDE
Compilation)
- ?
Maybe we also should consider to rename the 'Factory'-part as this leads sometimes to confusion between openSUSE:Factory and KDE:...:Factory
Maybe one could use Testing instead of Factory this might also explain the purpose of this repository better to people not so familiar with openSUSE.
But the full URL would be KDE:Distribution:Factory:openSUSE_11.2. How could that be understood as anything other than factory KDE packages built for 11.2?
Am Freitag, 30. April 2010 10:13:27 schrieb Martin Schlander:
Fredag den 30. april 2010 09:55:33 skrev Christian Trippe:
Am Dienstag, 27. April 2010 17:46:19 schrieb Lubos Lunak:
- development:
Software
- KDE:Distribution:Factory
- KDE:Distro:Factory
- KDE:Base:Factory
- (KDE:SC:Factory is not listed as the contents are not just KDE
Compilation)
- ?
Maybe we also should consider to rename the 'Factory'-part as this leads sometimes to confusion between openSUSE:Factory and KDE:...:Factory
Maybe one could use Testing instead of Factory this might also explain the purpose of this repository better to people not so familiar with openSUSE.
But the full URL would be KDE:Distribution:Factory:openSUSE_11.2. How could that be understood as anything other than factory KDE packages built for 11.2?
I do not know. I have only seen occasionally some misunderstanding. I am fine with keeping Factory. Just thought I mention it.
-
Christian Trippe -
Dirk Müller -
Lubos Lunak -
Markus -
Martin Schlander -
Raymond Wooninck -
Richard Atcheson -
todd rme -
Will Stephenson