On 09/26/2012 10:37 AM, Kamil Paral wrote: > I personally split maintainers in the distribution into three > categories. > > 1. Packager > > 2, Maintainer > > 3. Upstream maintainer Is this an argument for an additional Fedora package class? At present, it seems there are two well-defined types: "critical path" and "everything else". If gcc is broken, it is a larger issue (it affects a much greater number of users) than when something is wrong with gnome-games. A person who principally uses Fedora to run "Mines" or "Sudoku" may feel differently. Some distributions have a "user-contributed" category (often a separate repository) that formally recognizes packages that are not maintained and tested, or handled in a more casual way than packages with a defined support structure. This looks something like your distinction of "Packager" (one-off effort, person now interested in something else: user contribution category) and "Maintainer" (responds to error reports, communicates upstream where appropriate: distribution category, subject to QA). This is somewhat like the rpmfusion effort, which separates packages that do not meet Fedora license requirements into a separate repository. An rpmuser effort could collect packages that do not meet Fedora QA, test, or maintenance requirements into a separate repository. The best (or maybe the worst) of both worlds. I expect there are many who agree with: On Wed, 26 Sep 2012 10:55:40 +0000, Jóhann B. Guðmundsson wrote: >I prefer few but well maintained packages over many unmaintained >packages. and at least as many who agree with: On Wed, 26 Sep 2012 06:37:35 -0400 (EDT), Kamil Paral wrote: >Having the package for a year or two is better than not having it at >all. I am no stranger to building applications from source. I have the training and experience to think I know what I am doing. When I am lucky, the application author has made it very clear what resources are needed, but most often an iterative process is necessary, where I identify pieces (*-devel packages, libraries) that are needed. This is work that can be factored out by a packager, performed once instead of many times over by users who must start from source, or resolve a series of "shared library not found" issues when an executable file is copied. I can imagine other solutions to make it easy to import into Fedora applications not packaged in rpm files, but nothing that can be established quickly, and likely not as convenient as a yum repository. I want it to be easy for a person to package an application and share his work with the community of Fedora users. A moderated yum repository, which is what Fedora now uses, is a good answer. Additional repositories that identify packages by support characteristics might be useful, especially if they "lower the bar" for casual contributors, but maintain high standards for most-used and critical pieces. As usual, the difficult question is not technical (we know how to create and maintain yum repositories), it is whether more repositories will add enough value to justify the confusion and work that their establishment entails. It has some problems, but the present scheme works (I think suprisingly) well. A lot of people share their talent to make it so. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
