Bug 412722

First I need a list of the bugs you want to cover

Anja, those are the bugs that are blocking this bug (see dependencies at the bottom of the page).

Yes, please scroll down to where it says "Dependencies".  There are these bugs there:

336735: Slab and Intlclock always show on display :0.0 in TwinView/Non-Xinerama 

350513: gnome proxy settings dialog input disabled

395146: change time - wrong date

402256: main-menu process high cpu usage

406741: .ogg / realplayer default

411497: devhelp crash when 'Ctrl+c'

412719: Backport from svn for gnome-panel

I'm strictly against "little bunch of bug fixes" behind one swampid. The only bug in your list I would approve an update for is #402256, all others belong in 11.1 or GNOME:STABLE build service repo.

What is the policy for which updates to accept?

All of these are valid fixes for bugs which people see directly; as far as I can tell none of them is for "internal" issues.

We can't expect that people will take the trouble to look for the correct bugs, and hope that the fixes will have gone into an external repository *and* that the developer will have taken the trouble of documenting that in the bug :)

People expect to get a constant stream of fixes/improvements when they do online updates.

We only do maintenance updates for severe issues and we usually put a bunch of smaller issues in one package as soon as we find a severe issue with it (e.g. security updates include fixes for smaller issues). And no, we don't update packages for valid fixes. 

But again: use a build service repo if you decide to maintain the 11.0 stack more agressivly.

When this very old fashioned policy will be dropped openSUSE will become better, because the current situation, I'm sorry, but I can't really find a better word, sucks.

The main reasons of this are the following:

- We don't get updates for "non-serious" (what does this mean?) problems which annoy us (users) everyday. 

- When a patch is provided, it takes too long. In some cases it takes months to have a patch in the official update repository after the bug is marked as fixed in bugzilla (See gaim not connecting to ICQ bug 405632 - Yast-gtk bugs for _some_ example). This has been justified with the need of quality assurance, but it seems a bit strange that to check some RPM's it takes so long.
Moreover, in my opinion a bug is fixed when the user _receives_ the patch, or bugzilla becomes inconsistent for who reads it without knowing how it works. So a "patch to be released" solution should be added.

- It looks a bit irrespective both for the users that found the bug and helped in identifying the problem, and for the developers who invested their in fixing it.

- Buildservice is not a valid solution, because is case of problems, you leave the user alone with the "what is on BS is at your own risk" answer.

We asked to reconsider the patch policy many times, at least on IRC, but, for what I know, the request was ignored or didn't see any kind of discussion about this at least.
I might agree with the current policy if openSUSE were released always in good conditions, matching quality requirements, because it would help to keep the system stable. However, this has not been the case for a long time now, and a revision of the current policy seems really necessary at least to reduce the annoyances to the users.

Regards,
Alberto

I'm really surprising about that..

the patch provided bye gnome team looks fix problems..

criticals or not they are annoinig.

an END USER whant his system works and nothing more..

you should thake the patch, if it is valid you MUST use it, if not, you should fix the patch and then apply.

Criticals are not, if a bug is aannoining for lots of users, is a MUST for a BIG distro like suse to fix them, and not always give suse like a beta for SLES/SLED