[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.



Raphael Hertzog  wrote / napísal(a):
On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
Yes, bugs are unavoidable. However, testing is often in situation "whole system broken" or "nearly useless". I see difference here; occassional bug in desktop app is acceptable. Whole system unreliable is not acceptable.

Have you facts to assert this?

Just a personal experience.


I've been an happy user of testing. It happens that some packages are not
upgradable during a timeframe however the installed packages are not broken
and thus the system is perfectly reliable.

You can't just get the latest version and hope that it won't break
anything.
That should be verified in light of broad experience (I don't have any). Does it happen often that GNOME version change breaks many things? The only my try was to put GNOME 2.0 to Debian Woody (ugly GNOME 1.2), and I was succesful.

You can't generalize based on a single experience like that.

Yes, I admired that openly.

Your
restricted yourself to software published by the Gnome project. Check how
many applications depend on Gnome and yet are not developed following
Gnome's schedule. Those are the applications which have not been tested by
upstream with the new Gnome and which are the more likely to break.

Could we put more pressure on them to follow some rules? Make it compliant or be not released at all?
I'd expect that enterprise is already making pressure on this..


You can't rely on upstream to do this testing for you. We have a purpose,
we don't stabilize our distribution just because it sounds nice, it's
really needed in many cases.

Don't get me wrong however, I'm all in favor of having backports
integrated in Debian and make it a viable alternative for many users.
But you simply can't drop newer upstream version in what we call "stable"
like you suggest.

I respect Your opinion and probably You know what You're speaking about, however the interests should come to some balance (stability vs available labour force vs usability vs bug reporting vs security).

Maybe, there could be these levels in release cycle:
-stable (security fixes are backported, depending on popularity and demand the packages have) -recent (tested, functional fresh packages, that could stable be upgraded by, w/o breaking deps, officially supported)
-testing (stabilisation playground for next libraries platform)
-unstable (new software packages)


Peter


We don't really need more discussion on that topic. We need improvements
to make that a realistic goal.

Cheers,



Reply to: