Home Home > 2009 > 02 > 19
Sign up | Login

Archive for February 19th, 2009

Status russian mirrors

February 19th, 2009 by

Some times ago Russian and Ukrainian users noticed strange connection drops from Yandex. I can’t solve this problem, because I’m not Yandex employee.

Russian mirrors problems are mostly solved by introducing new mirror (Thanks to Yuri xnu!! Tsarev). This mirror have all openSUSE related stuff, 100 Mbit connection, 1Tb storage drive. After testing period now we can see that mirror is ready for main workload. So we adjust priorities and if you are try to access download.opensuse.org from Russian IP you should be redirected to this new mirror.

Due problems with foreign bandwidth we can’t serve Ukrainian users with Peter Poeml help we switch they directly to German mirrors.

If you have problems with Russian mirror accessing via download.opensuse.org please contact me directly. I’ll try to solve this

Why the Buildservice is currently not for endusers

February 19th, 2009 by

Everytime, when I hear people rendering homage to the openSUSE Build Service as “nice tool for endusers to get packages”, I’m a bit confused. From my point of view, the Build Service in it’s current state is not really usable for endusers.

Here are some reasons why:

  1. No displayed License before adding the repository (have a look at the Non-OSS or Education Repositories to get an idea how this works) – this might be important if people crash their hardware after adding a repository with special kernel modules without being informed about possible problems…
  2. No package groups called “patterns” – so people can’t get an easy overview about the various software areas a project provides (using YaST -> Software -> RPM Groups is not usable for me since someone decided to show just a plain structure there).
  3. No package translations (sometimes I like to see the Summary and Description of a package translated in my own language to understand the real area of application for this package).
  4. As the Repositories change over and over again (sometimes just because a dependend package in another project has changed), you need to download at least the metadata of a project again and again. For the Education repository in the Build Service this means: transfering 4MB of data each time you call “zypper”. Not really nice for people with a low bandwith.
  5. Endusers will “upgrade” their installed packages again and again – without knowing the real reason for this upgrade until they can have a look at the package changelog (hoping the developer has added some informations there). Not even the Factory distribution has this problem with automatic rebuilds (resulting just in increased release numbers) and no information for endusers why they had to download tons of MB each week…
  6. Real Packagers use their Build Service repositories for development and testing – so some packages will likely be broken during this phase – and just the packager knows when it will be really “stable”. (I’m talking about “real packagers” as I often see people using their home projects in the Build Service just to create an own repository containing packages they use – just by linking packages from other projects without any changes. But this is another topic…)

Projects like KDE or GNOME try to balance some of this problems by using the “publish disabled” option until they want to release a new version of their project. But this makes testing for developers and testers harder: with publish disabled, developers and testers can’t easily download and test new packages via the synced, public repositories – they have to download their packages via the API of the Build Service one by one.

With the upcomming releases of the Build Service, this will hopefully change. Up with 1.5 project admins can create a “full featured YaST Repository” for their projects covering the points 1, 2 and perhaps 3. But I think we also need more or less “frozen” repositories beside the current project repositories to cover 4, 5 and 6.

These “frozen” repositories should IMO be placed in separate directories (like the official openSUSE distribution directories) to make it clear to everyone that these repositories have an “enduser focus” and not a “developer focus”. This way, a project like KDE or GNOME could:

  • use the current repositories below download.opensuse.org/repositories as their “bleeding edge”  development repos for packagers and testers.
  • have a separate enduser repository with additional features like patterns and translations using the “ftp tree generation” feature.

…and thats the reason why the summary of this blog contains the word “currently” – I think the Build Service is on a good way to be a really good solution for developers and endusers. But we should find a final solution for the open issues mentioned above before we point endusers to this tool.

How developers see openSUSE

February 19th, 2009 by

You probably know that a lot of openSUSE developers are sitting in the SUSE office in Prague, Czech Republic. They are also openSUSE users.

The whole story started by a flame on a mailing list why some of us are not happy with the current state of openSUSE. It turned out there is a lot of different issues. So, we’ve met on a raining winter Friday 3 weeks ago to collect those issues as well as things that people consider to be good about openSUSE.

The result of the hours-long discussion is a list of positive and negative things about openSUSE, very subjective view of the group of developers in Prague. Go, look at the list. There is a lot of problems that I personally see lurking in our community, spelled out loud. The range is wide, from basic community issues to very technical problems that are basically missing features in the distribution.

So, we have collected the feedback. But the question is, what to do with it?

Firstly, I believe the lists are great food for thought. You might not agree with everything, but still, there is some truth in it. At least, those are problems that people consider important enough to try to solve them – encouraging.

Secondly, consider this blog as call for contribution. If you believe some of the areas are really worth improving, get in touch with people listed on the wiki, improve the description  in the wiki, propose solutions. One restriction though – please, do not add additional items to the page. We want to keep the ideas where they belong – features eventually to end up in openFate, project-related problems on the mailing lists, …Also, this is not a general list of issues the openSUSE project needs to address. As I’ve written above – the page is a subjective view of a group of people. If you think we need a more general approach, please, bring the idea on openSUSE mailing lists.

Looking forward to your feedback!