swerdna: can you rely suggestions from this topic to the mailing list? I suspect that some users dont use the mailing list. As a suggestion, i guess a new version of KDE for Tumbleweed users would be nice, like kde 4.7.4 version found in upstream repos KDE repositories - openSUSE
I’m waiting for the latest Intel graphic driver xf86-video-intel 2.17.0 release to be packaged in the xorg-x11-video-driver rpm, but thus far it has not shown up in Factory. [as openSUSE-12.1 only has the 2.16.0 driver]. I note it available on the Intel site but thats not enough. Its component requirements include :
Thats a nice list, but it does not answer my question. I asked :
My guess is they are the same version as 12.1. They are not yet updated.
Now I could be wrong, but I believe if we constantly force the Tumbleweed packager to check a version, because we can’t be bothered to check, it will create undue extra work on the packager, that could be better spent by the packager migrating packages to Tumbleweed that DO have updated versions. Ergo, I think it not all that useful to recommend packages which have the same versions (in factory) as those in 12.1. One should first check that they are updated and save forcing the Tumbleweed packager to have to do that work.
My apologies for the emphasis on ‘updated’ but that was a key point that I was trying to make that I think was missed.
Well, Rosegarden was available in Tumbleweed’s 2011 repo (along with jack and qjackctl), and was often updated. However it didn’t make the 12.1 distribution but appears to be available in Factory, from Build Service under multimedia:apps:
sorry, I just checked whether they are available in the factory repo or not, didn’t check the version no. I believe what you are trying to point out is that I should check whether the version of a particular package in tumbleweed repo and factory repo are the same or not. if the version in factory is newer, i should notify it here. am i correct?:shame:
Yes, you definitely should check the version. Factory should have most packages (of the same version) as are in the OSS repository, and factory, as time goes by, will have more and more newer packages. Currently MANY of the Factory package versions are the same versions as the 12.1 OSS/Update package versions.
If the version in factory is newer, of the one you are interested in, and if you really want it in Tumbleweed, you should report it on the Tumbleweed mailing list. Please see Swerdna’s first post in this thread.
Now Swerdna has volunteered to help out in his 3rd post, if users don’t access the mailing list, … but in this case I recommend the mailing list. My experience with such volunteer efforts, is after time it does grow to be a burden. For example I once volunteered to help users with migration of PC information to the HCL, but after a couple of years I stopped doing so. Typically users who asked for help made no effort themselves to migrate their information to the wiki, the information they provided was either too detailed or too sketchy, and I had to keep going back to them to get more information, sometimes I had to teach them how to get the information … it was very time consuming … then the wiki went through a dramatic reformatting exercise where for a brief time after the change, the effort was massive for even the smallest change, and finally the work level for me to handle the hardware HCL requests was simply more than I could handle. It was a dedicated volunteer effort, and I wanted to spend MY volunteer time elsewhere. So I stopped. IMHO for somethings, its better if users take the extra time to learn how to do these “some” things themselves in a free open source operating system.
Joining a mailing list is not too difficult. As mailing lists go, Tumbleweed is nominally fairly quiet and not too disruptive to one’s email program (although I recommending joining all mailing lists with a separate email address).
I would like Tumbleweed to be rolling system update, not applications update.
So for example - new kernel, samba and CUPS, glibc, mesa, drivers, xorg, desktop environments, gcc, c++ and multimedia libraries, pulseaudio etc, hardware and filesystems, things you can find in “base system” and “base build” repositories.
It’s very easy to add additional Banshee or Libreoffice repository (some of them are already in “Tumbleweed flavour”) if you need it.
And it’s rather impossible to render your system useless by doing it.
But updating system is much more difficult and there are no stable repositories to do it.
By using factory system repos you will roll into 12.2 but sooner or later your OS will be messed beyond repair.
Moreover, different people use different apps - some need updated PHP repository, others would prefer Amarok.
But everybody are using base system, so this is what i would like to see updated.
Based on my limited understanding, reading some posts in other threads and even here in this thread, I too think there are those who have even less an understanding than I of Tumbleweed.
CLEARLY just because an application is in Factory, does NOT mean it MUST go into Tumbleweed. That was never stated in this thread to the best of my knowlege.
Rather it was stated for it to be considered in Tumblweed, an UPDATED version MUST be in Factory in order to be considered.
And I emphasize (from my understanding) : JUST because an App is in factory does NOT mean it will go in Tumbleweed. Does NOT !!! But it MUST be there 1st to be considered. This is just a first step in the packaging/stability process that is needed to make Tumbleweed viable. At least that is my limited view/understanding on this.
INDEED during the openSUSE-11.4 release cycle, there were many X and graphic driver updates that did NOT make their way into Tumbleweed because they were NOT considered stable enough.
I perfectly understand what you mean, there’s no need to repeat. And I don’t want unstable packages to be included in Tumbleweed.
I just suggest, that maybe it could concentrate more on base&system related packages, instead of applications.
So take stable packages from a fixed set of factory repositories (and fixed set of things that are included in Tumbleweed project) and push them into Tumbleweed.
And leave applications for users to decide. They can update them easily without Tumbleweed (and without sacrificing much of stability, as there are lots of non-factory stable and updated repos for many apps and even whole desktop environments).
This is only a suggestion, and it should decrease the number of packages to take into account, because selection of pure core system packages/repositories is quite limited.
Yet it would be probably a step closer to true rolling distribution,