This is just a collection of random thougths on some of the ideas you presented in this thread. > Nobody is putting burden on anyone other then the maintainers themselves. > > Either they do it directly to themselves ... or it's being > done by other sloppy/non responsive/absent maintainers indirectly > through the component they are supposed to maintain ... > or through various policy's/processes we in place trying to deal with > those. and then later (the text in [] is inserted by me) > But no the proposal [that forces all new packages to have "how to > debug page"] made to FESCO/FPC winded up in *Recommendation* > instead *Requirement* which automatically made that process and effort > to be in vain since I knew that maintainers would not provide that > information if they did not have to and guess what I turned out to be right. > > Same thing goes for "how to test" since maintainers would have to > provide us with the information what was the best way to test their > component ( for the most part anyway ). Without that information process > like proven testers is just a waist of time and unnecessary bureaucracy. > ( just one of the issues why something like proven testers does not and > will not work ). You are contradicting yourself, i.e., you are putting burden on maintainers by requiring them to supply some "how to debug/test" information. Furthermore, you are trying to solve bureaucracy by more bureaucracy. IMHO proventesters' process is waste of time and unnecessary bureaucracy no matter what "how to test" information exists or does not exist. > But basically you winded up being stuck with them since you wanted to > ship component A but to do so you required B), C) and D) but nobody > is/wants maintain B),C) and D). > > Nothing can actually be done here since that's the price one has to pay > wanting to ship component A). Lets suppose that component A is something that is either used by (1) many other components (e.g., some relatively low-level java package) or (2) some leaf package, but one that lots of people use (e.g., libreoffice). Now lets examine these cases one by one: (1) Guess what is going to happen if the maintainer "unburdens" himself of packages he only maintains as dependencies for "his" package (like packages B, C, D from your example). Either _some other maintainer up the stack_ without real interest in them steps in and takes them, effectively leaving the situation as it was before; or we drop them, together with A and everything that depends on A. Good! We got rid of a lot of "poorly" maintained packages and got a much better maintained distro! (E.g., who cares if we just dropped java? What do we need java in Fedora for, anyway?) (2) The same reasoning follows, only with the result that just one package is dropped. E.g., if the libreoffice team decided to give up maintenance of the jfreereport packages, nobody else took them and they were dropped, we would be forced to drop libreoffice as well (actually, we would just use the bundled jfreereport, Fedora policies be damned...) I would really like to see you explaining in release notes how dropping libreoffice increases "the overall quality of distribution". > Not sure what you mean about distro integrity since arguably shipping > few but well maintained components is better then shipping many poorly > maintained or not maintained at all. Arguably the foremost goal of the distribution is shipping useful software. If we stop doing that because some unfortunate (right, lets not call it "stupid") policy demands that we drop "poorly maintained" (but still perfectly functional) packages, we may as well give up the whole effort, because we are becoming yet another niche distro. Just try to understand maintainers do not put software in Fedora for the sake of it--they do it with the idea that it is going to be useful for other people. If I look at a distribution and see that half of the software I use is not there, I will not use that distribution, no matter how "well maintained and tested" the rest is. It is as simple as that. > You may consider this an sloppy I however do not as I see it the how to > debug page for your component is necessary since without having spoon > feeding information on how to do that the reporter will never be able to > provide you with the information you want. > > We simply can not improve reporting in general without having the > necessary documentation on how to obtain that information and what > minimal information the maintainer wants ( the how to debug pages ). This is a fallacy. Even if such documentation existed, who says that an average reporter would (1) read it and (2) act on it? It also assumes that troubleshooting of _every single package_ can be reduced to a couple of instructions and it does not take into account at all that in considerable number of cases it is not clear which component is causing the problem (is it the application? Or is it one of the libraries it uses?) I will use libreoffice as an example again: there is about 20 env. variables that can be used to alter its behaviour (and may point to the problem). Do you think any reporter is going to try to run the application with every single one of them? Fat chance... Lots of problems are caused by extensions. That means the reporter should manually uninstall every user/shared extension and try again. Etc. etc.... I claim that for any sufficiently complex package such a "how to debug" page would be either too long and the actions required too time-consuming to be acceptable for the reporter or too short and simplistic for the information to be useable for the maintainer. Most probably both at the same time. And this does not even touch the issue of abrt bugs, where in many cases the initial report is at both the first and last occassion we hear from the reporter... IOW, _they just do not respond!_ And no amount of "how to debug" documentation is going to change that. > The how to test is was aimed an more general QA activity ( building test > cases either for reporters to use or automation ) If there is a way to test some aspect of a package automatically, it should go into the package's test suite (well, unless it tests something Fedora specific that has no chance to go upstream). Keeping it outside is unacceptable. Uff, that is enough for now... D. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
