Am Friday 08 January 2010 15:14:54 schrieb Dariel Dato-on:

I do like the current repository structure. It seems quite clean and easy to understand for me. Having some easy to enable in YaST makes it dead simple.

Also my point of view

I think what is confusing to me (and what might be frustrating to some people) is the repository structure never seems to remain the same for long. I remember having to change my repository something like three times in order to keep up with the most stable KDE.

I think, this is not an openSuse fault. Every month is an stable KDE4.X.Y release and this hurts openSuse release logic with stable ,....

So I do like the current repository structure, but how long will it be before I will have to change it again?

I think with 11.3 and 4.4 there will be a mor quiet time of repochange.

Thanks for all your hard work.

Cordially, Dariel Dato-on

On 08/01/10 15:41, Daniel Fuhrmann wrote:

Am Friday 08 January 2010 15:14:54 schrieb Dariel Dato-on:

...

I think what is confusing to me (and what might be frustrating to some people) is the repository structure never seems to remain the same for long. I remember having to change my repository something like three times in order to keep up with the most stable KDE.

I think, this is not an openSuse fault. Every month is an stable KDE4.X.Y release and this hurts openSuse release logic with stable ,... +1.

Enough ranting, the anger/accusations is misplaced and way over the top. READ THIS SUMMARY If all you want is a workable version of KDE, stick with what came with the distro when you installed it. Everything else can break your system at any time with no warning because it *will* always be changing. If you want the latest released version of just the applications (e.g. amarok, digikam) use just KDE:Backports. If you want the latest released version (including betas and RCs) of the KDE Desktop _and_ applications use KDE:KDE4:Factory:Desktop. If KDE makes a release when KDE:KDE4:Factory:Desktop is busy, the KDE team may choose to create an additional repository (e.g. KDE:42, KDE:43) in order to package that latest release. Once KDE:KDE4:Factory:Desktop is free again, these additional temporary repositories *will disappear*. If you decide you absolutely must have the latest version and switch to the version specific repos, be aware that they will disappear again in a few months. * That means if you absolutely must have the latest KDE at all times you WILL have to change your repositories occasionally, there is no way around that. Development for the next release, not current users takes priority in these repositories. To keep up with upstream you have to switch from KKFD to KDE:{version} and back to KKFD every few months. * If you want to keep it simple just stick with KKFD until it starts moving again. That is all you should need to know. Normally the only available versions of the KDE desktop you can expect to be available will be 1) The version that was in the last released distro in STABLE 2) The latest released version in FACTORY 3) The bleeding edge in UNSTABLE Any other repository is temporary and there is no guarantee it will still be there tomorrow, if you use one of them it is your job to keep alert of any changes to it. Just stick to the above and you'll be fine. If you choose to use the temporary repositories because you *must* have the latest version please don't complain about the repository layout, the alternative is not to provide the extra repositories at all. END OF SUMMARY If you must know the details: The layout for the KDE *desktop* package repositories is: STABLE (what was released in current openSUSE) what you've already got in 11.2 plus some extra fixes which are being currently tested e.g. for online update FACTORY (going into next version of openSUSE) what is going into the next version of openSUSE and will most likely be the latest released version from KDE (except very close to a openSUSE distro release). UNSTABLE (absolutely bleeding edge straight from KDE trunk, doesn't even build half the time) not for normal users As you can see, there is not much reason to use STABLE (you've already got it if you are running 11.2) or UNSTABLE (it will eat your children). As I said above, if KDE has a release when a) openSUSE Factory is in version freeze in preparation for a distro release b) KKFD has already moved on to the next major beta release (e.g. it is now on KDE4.4 beta/rc) the KDE team may create a temporary version specific repository (e.g. KDE:42, KDE:43). The reason we have these is because people wanted for packages of the latest released KDE, not because the KDE team is masochistic or sadistic. Now that FACTORY is moving again (release of 11.2) (and also KDE has said that there will not be another 4.3.x release) *these repositories will disappear*. Their purpose was to provide the latest released version while FACTORY was busy, that reason is gone, there is no more reason to keep them hanging around. Meanwhile, applications which are released separately (amarok, digikam) have their own repositories because they are not related to the KDE *desktop*. 1) KDE:Backports contains the newest released versions of these apps built against the base distribution. No KDE upgrade needed to run these. 2) KDE:KDE4:Community contains applications/utilities e.g. from kde-look.org that people outside the SuSE KDE team package. 3) KDE:KDE4:Playground contains experimental/bleeding edge/unstable versions of the apps in Community and Backports. Regards, Tejas FWIW, all of this information could have been gotten by a thorough reading of the wiki pages. P.S. I suggest that at some point the KDE4: prefix needs to be dropped from the repository names like it has been from Backports. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Lørdag den 9. januar 2010 09:31:27 skrev Rajko M.:

On Friday 08 January 2010 11:42:08 Tejas Guruswamy wrote: ...

...

Enough ranting, the anger/accusations is misplaced and way over the top.

READ THIS SUMMARY

...

85 lines of text and 6 if-then to explain something.

KDE is beautiful thing, but it is just 1 piece of puzzle. There is kernel, Xorg, YaST and many more.

If each would contain 184 line long list of repos, with 60 lines of links, with explanations that make old SuSE user, like me, think what they mean, then end user is in a very bad shape.

Anyway, I just started to scale down http://en.opensuse.org/KDE/Repositories . I would need help of experienced and inexperienced readers to check my version of the article.

http://en.opensuse.org/Talk:KDE/Repositories

The goal was to hide complex URLs that don't bring much and make list short.

Don't bring much? .. People need to be able to copy/paste the URLs. Forcing them to fire up a browser and browse the repo won't help any... Or your assumption is that people will intuitively realize that right click -> copy link address is the way to go? And the current wiki page has the version numbers you've been crying out for E.g. "STABLE (4.3.4)", but in your edit of the page you've removed that very information too... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Saturday 09 January 2010 04:03:33 Martin Schlander wrote:

Lørdag den 9. januar 2010 10:57:57 skrev Martin Schlander:

...

Lørdag den 9. januar 2010 09:31:27 skrev Rajko M.: ....

...

Anyway, I just started to scale down http://en.opensuse.org/KDE/Repositories . I would need help of experienced and inexperienced readers to check my version of the article.

http://en.opensuse.org/Talk:KDE/Repositories

The goal was to hide complex URLs that don't bring much and make list short.

Don't bring much? .. People need to be able to copy/paste the URLs. Forcing them to fire up a browser and browse the repo won't help any...

Interesting. What they use to see that page?

...

Or your assumption is that people will intuitively realize that right click -> copy link address is the way to go?

Some will copy and paste, as it is part of any context menu (right click) of any browser when viewing a page. That is not used only by users that are totally new to computing and never clicked right mouse button. Other will click trough and have URL in browser address bar ready to highlight, copy and paste. All if them will have page that is not filled with irrelevant information, from nice and visually noisy template VersionNote, to lengthy URLs that is not easy to remember.

...

And the current wiki page has the version numbers you've been crying out for E.g. "STABLE (4.3.4)", but in your edit of the page you've removed that very information too...

The current version information is added visual noise. Title "STABLE: Latest official openSUSE release (KDE 4.3.4)" instead of "STABLE" helps only to add more noise to sink (hide) relevant info in it. That does not belong to any normal, readable title of any section in any article. It belongs to text under the title. Besides current status is 4.3.1, not 4.3.4 :) I'm for named repositories with version in the name. To me 42, 43, 45 is more verbose and consistent information then backports, community, playground. Backports refers to version. Community refers to who packaged software. Playground refers to stability, usability? With my understanding of the word playground, in this context it is the same as "do not use it". Then there is one problem that with numbered names is easy to solve, rollback when you encounter bug that you can't wait until it is resolved. Version numbers are used to enable this, which in turn makes possible debugging with updating and rolling back in search for change that introduced the bug. What repo to use with "descriptive" names to rollback unwanted change? I know that there is no answer for that. Currently, it is either released version, or one in some of repos.

And another thing. Why would you want Joe User to fsck around with those repos anyway.

Because Joe the user, if ever get hard pressed to open that wiki page, then it is to look for fixes to KDE that are not offered via official update channel. This time it is offered, but that never happened before, so majority of people, that help new users, will propose to perform update.

What Joe User should do, is stay with the supported KDE packages, add KDE:Backports repo and KDE4:Community repo with clicky, clicky in yast Comunity Repositories section - and live happily ever after.

Agree on that one in any normal circumstances, but it seems that KDE is under development and living happily means updating regularly.

The fixes in 4.3.4 over 4.3.1 probably hardly affects any users, and 4.3.4 as we know will be shipped as an official update fairly soon anyway.

Shipping version update of all desktop packages is a big deal and developers agreed that is required. To me that is as far from "hardly affects any users" as it can be.

People are just shooting themselves in the foot, with all this pointless version-whoring.

Talking about shooting oneself in the foot. As explained above, versions are used to have reference to certain build, so that users by simply rolling back to previous version can identify good and bad versions. Current repository structure defeats that efficiently. Developers have to resort to serious tools that users can't use. -- Regards Rajko, openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Saturday 09 January 2010 08:15:34 Tejas Guruswamy wrote:

On 09/01/10 13:16, Rajko M. wrote:

...

Talking about shooting oneself in the foot. As explained above, versions are used to have reference to certain build, so that users by simply rolling back to previous version can identify good and bad versions.

Current repository structure defeats that efficiently. Developers have to resort to serious tools that users can't use.

I understand the problem you are putting forward; at least, unlike some others, you have a reasoned argument.

Thanks, trying my best :) The same is valid for you. This whole explanation between <quote> tags should end on the wiki, and it can be used in any future discussion. <quote>

But I think the misunderstanding comes from a difference in expectations of what the openSUSE KDE team is supposed to do.

You are thinking that they should have all recently released versions from the current major branch of KDE packaged at any one time like KDE:42, KDE:43, KDE:44. So that it is possible to switch between each version till you get the right balance of bugs and fixes.

What actually happens is the KDE team has *one* version of KDE packaged at any one time. The most recent released version in KDE:KDE4:Factory:Desktop because that is what will go into the next version of openSUSE and that is what needs work. The KDE team is not interested in any other version. (Okay, so UNSTABLE gets packaged too, but that's just automagic). STABLE is nothing but a testing ground for online updates for the most recent release, no extra work goes into that either.

From the KDE's team point of view, then, there are no rollbacks possible. It's either what came on the SUSE disk or the version in KKFD. The KDE team is not big enough to maintain packages of multiple versions of KDE. Despite the current number of repos, only *one* is actually seeing any real maintenance: KKFD.

KDE:43 (and KDE:42) were extras. People were asking for new 4.3.x when Factory had already moved on to next major release 4.4.x. The KDE team doesn't need to care about these versions, they are never going to go into a release distro. In fact if we look back to last year the original plan with 4.2.x was simply to never package those versions. No extra work has gone into them and the expectation was that they would disappear as soon as they were out of date.

I hope now you can understand why the KDE team is so resistant to changing the repository structure. The structure is for ease of development, all the work goes into the same repository all the time. If we switch to version based repository names both the users and developers would need to switch repositories every time a new version of KDE came out. I know that means that it is not immediately obvious which version is currently in KKFD but improving the wiki page and information distribution should help with that.

Although you all seem confused by the choice of repos, in reality it is only an illusion of choice. The only real choice is between STABLE and FACTORY. </quote>

If you still truly want to change the setup why don't you offer to maintain a set of KDE repositories specifically for the users, organised however you like?

As mentioned in another post wiki transition makes everybody busy. I would need 48h a day to be able to do all I want to :) This digression in KDE topic took time and attention from transition, but as it is my problem with my favorite desktop, it was necessary. Other readers of this email are invited to take action if there is sufficient openSUSE Build Service server resources. <quote>

As for Backports, Community, Playground it's a *completely* different issue, please don't confuse them. Those three contain _applications_ that are released separately from the KDE desktop. There is no versioning that can be applied to them, and there is no overlap with the KK*D repos. </quote>

Regards, Tejas

While you explanation helps to understand why are repos organized as they are, that still leaves room for improvement, in other words, kind of version tracking, as it is common in other places. -- Regards Rajko, openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On 10/01/10 01:15, Tejas Guruswamy wrote:

On 09/01/10 13:16, Rajko M. wrote:

...

Talking about shooting oneself in the foot. As explained above, versions are used to have reference to certain build, so that users by simply rolling back to previous version can identify good and bad versions.

Current repository structure defeats that efficiently. Developers have to resort to serious tools that users can't use.

I understand the problem you are putting forward; at least, unlike some others, you have a reasoned argument.

But I think the misunderstanding comes from a difference in expectations of what the openSUSE KDE team is supposed to do.

You are thinking that they should have all recently released versions from the current major branch of KDE packaged at any one time like KDE:42, KDE:43, KDE:44. So that it is possible to switch between each version till you get the right balance of bugs and fixes.

What actually happens is the KDE team has *one* version of KDE packaged at any one time. The most recent released version in KDE:KDE4:Factory:Desktop because that is what will go into the next version of openSUSE and that is what needs work. The KDE team is not interested in any other version. (Okay, so UNSTABLE gets packaged too, but that's just automagic). STABLE is nothing but a testing ground for online updates for the most recent release, no extra work goes into that either.

Oh, Tejas, Tejas...... Apologies my friend but me thinks that there is either a language barrier or interpretation problem between the English language and whatever language KDE developers use :-( . It sounds very much like the sign my wife and I saw in Hong Kong some years ago which stated, "All Deliveries in Backside" (meaning, all deliveries to be made at the back of the shops). "STABLE is nothing but a testing ground....." No, STABLE means not unstable; not experimental; rock solid; not going to fall down; tried, tested and proven to work. Stable does not imply "testing ground". "Stable" is stable. "Unstable" is not stable, is experimental, very likely to fall over at any time. I feel that rather than defend the indefensible terminology which someone came up with in the last century, terms which describe closely what a repo is all about would be of immense benefit to everyone concerned and so do away with all the non-productive arguments about what this or that repo is supposed to do, or not to do, and if you want to do this then you need to use <this-repo> and not <that-repo>, and so on, and so forth, and "etc, etc, and etc" (The King and I) :-) . PRODUCTIVITY is what we all want and not wasting our time and energy on useless arguments (unless, of course, we have to respond to an inane response :-D ). BC -- Take the bull by the tail and look the facts in the face. W C Fields -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Saturday 09 January 2010 06:32:48 Tejas Guruswamy wrote:

Maybe the simple solution is to split up the page. I will see if I can contribute something later today.

Just a remark. (a long one, sorry) Please don't use subpages which is the name for: article_title/subpage1/subpage2 like it is now used all over the wiki. I convinced people on a wiki team to avoid them with exception of special case where page is just container for text that is used in a main article page, in other words wiki readers will never request that page as it is invoked only in a main page, but not as a plain browsable link. Example usage for this case is extension InputBox as in http://wiki.opensuse.org/openSUSE:Sandbox . Page http://wiki.opensuse.org/openSUSE:Sandbox/editintro_comment is invoked only with: editintro=openSUSE:Sandbox/editintro comment Similar with http://wiki.opensuse.org/openSUSE:Sandbox/preload preload=openSUSE:Sandbox/preload Current text is just demo what can be done using InputBox. We will try to move all pages that use them to sane title without slashes in them. It will not happen soon as we are now busy with transition http://en.opensuse.org/Transition_guidelines Creation of article groups will be trough Categories and/or top navigation bar, like the one in the http://en.opensuse.org/Installation, that is defined with template http://en.opensuse.org/Template:InstallationNav . Did I mentioned that we are looking for volunteers to join the team :) -- Regards Rajko, openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On 13/01/10 02:45, Lubos Lunak wrote: [pruned]

[*] Seriously, Basil, if you fail to understand even basic things like the fact that the "STABLE is nothing but a testing ground....."

Seriously, Lubos, if you do not understand plain English...... *STABLE* : abiding, constant, deep-rooted, durable, enduring, established, fast, firm, fixed, immutable, invariable, lasting, permanent, reliable, secure, sound, steadfast, steady, strong, sturdy, sure, unalterable, unchangeable, unwavering, well-founded. The English Thesaurus. Where is "testing ground" mentioned? If you want to call it "testing ground" then call it "Testing Ground". STABLE is stable; Testing Ground is testing ground; Experimental is experimental - or maybe even Developmental or UNSTABLE. But don't call a 'testing ground' "stable"! On 5 December, Will Stephenson wrote: QUOTE The KDE and maintenance teams are taking the unprecedented step of a point release update to KDE SC 4.3.4 in our 'STABLE' repository and from then as an online update to 11.2. UNQUOTE Anyone who understands English understood that what was going into STABLE will be transferred into the actual release repo for 11.2. The material there was STABLE. After reading that, I switched over to this STABLE repo so that I could have the STABLE version of 4.3.4 and not have to fool around with any TESTING GROUNDS or EXPERIMENTAL or DEVELOPMENT stuff which one finds in FACTORY. BC -- Take the bull by the tail and look the facts in the face. W C Fields -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On 09/01/10 03:01, Martin Schlander wrote:

Fredag den 8. januar 2010 13:38:17 skrev Basil Chupin:

...

Will not put up with the "repository fiddle-faddle" much longer!!

Here's a crazy idea. Just don't fiddle-faddle and use official repos.

I didn't write this, BTW. If you are going to quote then please use the correct quote attributed to the person who wrote the quote you are quoting :-) . BC -- Take the bull by the tail and look the facts in the face. W C Fields -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org