> On Wednesday 28 January 2009 20:16:15 Rex Dieter wrote: > > Eli Wapniarski wrote: > > But I do think that Fedora > > > > > stable releases should make a rule that core backends always be marked > > > as stable by the developers before they are released as stable in > > > Fedora. Not Beta, Alpha, or RC. > > > > Agreed, so what's your definition of "core backends", and does it > > include any or all of glibc, rpm/yum, X, gtk, qt, kde, dbus/hal, > > NetworkManager, or more? > > OK... I'll guess I'll take a stab at this. > > For the following I should add a caveat of reasonableness. The following > should always be stable unless some real nasty springs up and the only way > to fix it is by incorporating something less stable. But only as a very > last resort. > > 1) glibc and kernel (I know... I've never seen unstable kernel released in > Fedora). > > 2) Network Manager and dbus/hal > > 3) XWindows > > 4) Anything releated to package management. If for any reason that breaks > boy are we in trouble. > > 5) All Mail Servers, Database Servers, Web Servers, DNS Servers. > Authentication Services, etc. > > I think the current model regarding things like qt/kde, gtk/gnome etc is > just fine. Despite everything that is being discussed here we ussers and > you packagers need to trust the good faith of developers enough that when > they say stable they mean it. But, it would be good if major changes to > complex software like the change between KDE 3.5 and 4.0 have some way to > get roled back. Of course -- if the resources are there. If not well then > we are the brave we are the foolish we are Fedora users :). I guess we'll > just have jump in with both feet and do what we do so well. Provide polite > and persistent feedback in order to assist in getting the problems solved > and the packages improved. > > All that being said, I still think every effort should be made to initially > release stable versions. updates-testing is a great place to get Beta's and > RC's if required to get fixes to real nasties that come up in the case of > overlooked bugs or regressions. > > Eli What is stable? A short question, but not simple to answer. Me as a simple user, I would say, I don't care as long as all my data - mails, documents, pictures .. - will be ok (of course it's my responsibility to make regular backups). A crashing mail client maybe annoying, but when all my mails are still there, to me, it's not a problem. Just restart the app and i am happy. I can tell the developer and say 'hey man/girl your app crashed, can you look at it?' He or she may say: 'damn this may never happen. Can you tell more what you did?' Why this question? Because he/she wants to solve the problem. Sometimes the problem is solved, sometimes its not. If not, the problem can come from the specific hacks that 'maintainers' have made or sometimes have to make. Maintainers do their best to avoid regressions, I think. 'App A worked in version x, so it have to work in the next version y'. If not, they have a problem. An acceptable solutions have to be found. In this very sort and little 'story' I mentioned tree different groups: users, maintainers and developers. To have these groups in mind is, in my opinion, essential if discussing the stability of applications. What perspective does one takes. I'm not a maintainer, nor a developer, so the only thing I can ask is, if it is normal that the things that look weird are bugs or just by design. And when 'they' don't hear/listen to my questions, I can decide to go searching for an alternative. That's nice with open source. Of course, maintainers and developers wouldn't like to see me leaving - see the discussion about Linus leaving kde - so they will do their best to win me back. So my conclusion must be that every one is doing his/her best, if it's a user, a maintainer or a developer. But with different goals. Martin Kho