On Thu, 08 Jan 2004 00:14:24 -0500, Jef Spaleta wrote:
I'm not going to take anything away from someone who is able to build 500 packages and place them into a repository and build a userbase.
But is it a userbase that uses all 500 packages? Or is it a userbase that uses only a fraction of the available packages? IMHO, it is the latter. If Joe User is smart enough to install and configure a package tool to point it to one repository, he's also smart enough to point it to a different repository in case the former one provides a non-working package. Don't count on Joe User to take the time and submit a bug report by private mail or via a mailing-list. He would rather proceed and try an alternative package or downgrade or build from tarball. It's a similar scenario when Joe looks for a newer version. If repo X doesn't include it, he takes it from repo Y. If he's courageous enough at all, he posts in a web-based message board and is pointed to an arbitrary package offered at some site which is reported as working. It is a common attitude that plain users expect the developers to fix problems automatically, disregarding the possibility that the developers might not even know about a problem.
If for some reason, god forbid, Dag had to stop producing packages for personal reasons, that's a big blow to the archipelago concept since there are no written policies that I know of that others can follow to reproduce what he has accomplished.
Excellent example. One can argue whether all of Dag's tools are available and documented and whether someone could mirror the src.rpms and take over the repository in such a case. But one would still need to duplicate the infrastructure, the man-power and the commitment which is required to maintain all that.
And now we come to the crux of the issue. Coming to a consensus among ALL the interested parties about what the actually priorities are in the process pretty much defines what the packaging community is going to look like: How transparent do the QA processes NEED to be?
QA is a _huge_ problem, in particular if there is no complete list of what to check, but also if there is a list and reviewers go through it step by step and don't develop a feeling for what other issues could be important. Package reviewers have a very different point of view with regard to package quality. Some would want to actually test-drive the built software for an extensive time while others would concentrate on technical details.
How much input from the community does there NEED to be?
Certainly bug reports, RFEs and communication/feedback from users.
How hard do you want to try to make sure all the packages meet the same level of quality?
Define "quality".
How important is it to make sure all the packagers are using common conventions and best practices when writing build scripts?
The user doesn't care about technical issues, such as spec files or included patches and integration work. But if multiple developers are supposed to maintain a package, they better agree on how to package everything.
Fedora.us supplies a spec file template. A skeleton of how an initial spec could/should look like and what is considered readable and clear. But it should not be misunderstood to such a degree that upon minor package upgrades, packagers start changing indentation style and order of spec file fields to match the latest template closely.
Packaging is not "art", it is an engineering task. We should focus on packaging software correctly, not on beautifying a build script. We should avoid trying to be overly smart and not use lots of macros or conditionals to make a package build on more than our target platforms. Spec files should contain comments where it helps to understand the process of setting up and building a piece of software.