On Thu, 29 Jan 2004 12:03:56 +0100, Chris Rouch wrote: > > There is one particular thing I don't understand. Once an arbitrary > > repository contains a new package, people don't hesitate to download > > and install it. When it's broken or not as usable as expected, they > > either downgrade or try the next repository (this experience is based > > on comments seen in message boards), repeating this procedure > > regularly. But when a package of the same software is in a public > > queue of packages to be reviewed before they get published, people > > avoid such packages like the plague and don't give the packages a try > > and don't leave feedback. > > Maybe that's because of the perception that anything in a QA queue is > 'rawhide' quality, whereas anything released by a repository has > undergone some (possibly rudimentary, possibly thorough) testing and is > ready for the real world. And when something passes the QA queue without any changes, how does that fit into your scheme? It's exactly what I describe above. > It's been my experience since redhat 7 that > rawhide mostly works but sometimes doesn't, and e.g. freshrpms almost > always works. The QA queue is not anything like Rawhide, except if heavy package development (including patch-work) is merged into the review stage. The "testing" and "unstable" repositories are the development stream. > Having had such a good experience over time with freshrpms I'm inclined > to keep using it, and other repositories which attempt (not always > successfully) to stay compatible with it. From what I've read fedora.us > and 3rd party repos are making no attempt to be compatible with each > other. This is a shame. Where have you read that? For inter-repository compatibility, it needs global policies which all repositories, which choose to be compatible, agree on and adhere to. I haven't seen any policies or guidelines at freshrpms.net et al, e.g. no package naming guidelines or framework for a new repository to become compatible. Fedora.us has a set of policies and guidelines. But these are not sufficient, because they don't cover details such as low-level package compatibility (e.g. feature set of libraries and applications, creation of sub-packages and other details). Repo compatibility ends already when one repo upgrades the packages of another repo and if only due to a different repo release tag. Btw, it is evident, that in the process of finding a common set of policies, existing repositories might need to modify many of their existing packages, which is a big hurdle and makes them prefer to stay independent and continue the way they've done it so far. Not true? Then I don't understand what exactly happened during fedora.us preparation talks on fedora-devel ML. > > I think > > the community can do better than that. But the Fedora community has a > > long road to take to realize that--like with the Debian GNU/Linux > > project--it's better to spend a combined effort on a primary source of > > reliable and maintained packages than to either want everything > > maintained by Red Hat in "Fedora Core" or to keep an excessive list of > > repositories maintained by individuals and live with interoperability > > problems. > > It would be nice, but I'm not sure it's practical. For example Planet > ccrma builds low latency kernels, atrpms build kernels with the v4l > patches applied. I can't really see one repository maintaining these or > other variants on the redhat kernels. We have different concepts of splitting repository contents: Core, Extras, Alternatives (i.e. substitutes). Let's not mix these. I don't refer to stuff found exclusively in one repository. > What I'd like is for the independent repos to keep doing their > packaging as now, but when a package is released by them it is submitted > to Fedora QA to become a Fedora Extras package. Then people who have > confidence in 3rd party repos could grab new packages early, and people > who require a formally QA'd package could wait for the official Fedora > release. But this will require a degree of co-operation that isn't in > evidence at the moment. Why make it so complicated? Fedora Extras shall have a development/testing stream, too. It is important, that package evaluation and development is kept close to the Fedora Project instead of moving it to 3rd party repositories which don't have open bug tracking systems, for instance. --
