Hello! Am Sonntag, 4. Juni 2006 01:47 schrieb Andreas Hanke: > I'm not sure that using these packages really helps finding and fixing > bugs for the next release. The best and maybe even the only way to do > that is using factory.
You are saying that using factory 10.2 (most bleeding edge, as somebody called it) for SuSE 10.0 is less risky than the Build-Service? > 10.1 + build service is not what will become the next release - that is > factory and nothing else. There might be artifacts because the way the > base system and the KDE packages are combined is different from what > will become the next release. There might be even wrong bug reports > because of that, which might actually consume additional time and effort > instead of helping. A KDE-bug will be in the build-service, as well as in the factory-packages, so it does not matter which ones one uses. Especially since people report most KDE-bugs to KDE ond not Novell. Those few which are packaging-specific, do consume extra-time, yet the majority are genuine KDE-bugs and hence help KDE and thus SuSE. > > Further he is using a bugfix-release, hardly any bugfixes are backported > > and supplied via YOU, so this is the only choice apart from more risky > > (betas and alphas) or more inconvenient methods (compiling). > > Of course bugfixes will be supplied via YOU. Actually there was already > a qt3 + kdebase3 bugfix YOU. I said "hardly any", if you search the archives you will find that YOU is not supplying bugfix-releases but just some bugfixes which are considered important enough. However, for the user even non-critical bugs can be very annoying, hence the wish to not only get the critical bugs fixed, but the whole bugfix-release. I am not sure if it was backported, but there is for example a bug in kmail that was fixed in 3.5.3 and leads to it loosing folder-settings when it quits, very annoying, yet not a security or critical bugfix. > The packages in the build service are not bugfix releases. Don't mix up > the upstream development with the packaging work: From the stand point > of upstream development, KDE 3.5.3 is clearly a bugfix release, but > packaging software is much more than downloading it and making it > compile. There is integration work to do, and a version upgrade to > something that is published as bugfix release from upstream does not > necesserily have to behave like a bugfix package because upstream > development and packaging are very different things. Since bugfix-releases of NLD and SLD, apparently including KDE-versions, are supplied they are possible. The KDE-website refers to them as bugfix-releases and they fix a lot of bugs if packaged correctly, which I think is part of something which is offered as "genuine added value". Hence I still regard them as bugfix-releases. > > If Novell would think this is too risky for users, it would not call > > it "genuine added value" but "genuine added risk". > > Added value == added risk. There is no contradiction here. So Novell is advertising that it supplies an extra value called risk? Who would "sell" risk as something valueable, apart from adventure-travel-companies? > Sometimes I seriously dislike the way people expect these extra packages > to work. Some users expect them to have the same or even higher quality > than the originally distributed ones because the difference between the > version-release number and the work that has to be done to make packages > behave as expected is not clear. > > And claiming that using these packages helps improving the quality of > the next release is a very problematic thing. This might be true in many > cases, but there might be exceptions, caused by artifacts and possibly > invalid bug reports as described above. Ein bisschen Schwund ist immer. > Sometimes I just don't understand why these extra packages are so > popular among consumers. The packagers are spending huge amounts of time > for doing integration work and bugfixes only, everyone who read > opensuse-commit in the last months is able to know that, and then > consumers just throw everything away because there's something available > that looks like a bugfix update because it has a higher version-release > number. Good question, I guess it is because they hope to get rid of bugs that annoy them, no matter if they are relevant enough for YOU or not. So if there were none in the first place, they might have less need to do so. Further, if you report bugs, you are very often told to check whether it is really fixed. So either you quit reporting bugs, compile e.g. KDE BRANCH SVN, or as a middle course use the build-service packages. And of course, if you look at KDE 3.4 and 3.5 there are some nice new features, which people want to use without having to install a completely new system. Although this is another matter, but KDE and alike need beta-testers, so supplying beta- or RC-packages does help those projects, because compiling is really not that easy for most users. Of course one can expect even less support for those packages from SuSE, except maybe to trigger a rebuild in order to incorporate changes in SVN, but they do help. And regarding the false alarm you mentioned, at least for me I can say that 99% of the bugs I reported to KDE were not due to packaging and hence did help to improve KDE. Yet if there was no build-service, I would have to compile KDE, which I tried some time a go, but did not succeed. I do not have time to worry about compiling, but I want to contribute to KDE by at least reporting bugs. So at least for me, SuSE is giving back KDE by supplying packages for its users that help finding bugs. > By the way, splitting KDE itself and the most popular KDE applications > into separate repositories is a great step forward compared to the old > supplementary FTP. It can prevent some common problems and > misunderstandings - if people appreciate and follow the split instead of > quickly adding both repositories to their $PACKAGEMANAGER configuration > just because they can... That's true. So there is less integration to be done for those? Sven --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
