On Thu, May 17, 2007 at 11:01:48AM -0500, Tom spot Callaway wrote: > On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > > Christopher Blizzard wrote: > > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > >> All we're really trying to do is make good packages. We've tried > > >> really > > >> hard to make guidelines that lead to good, clean, > > >> maintainable-long-after-you-are-dead packages. > > >> > > > > > > I hear what you are saying and I understand. What I'm saying is that > > > there's a fine line between making good packages and going over the > > > edge. So in your example, documenting is good. But if you end up with > > > an exception process? I think that probably crosses the line. Dispute > > > resolution, maybe. But I just worry that we're going somewhere we don't > > > want to be. Not sure how to properly put this into words. > > > > I'm totally in agreement that an exception process isn't somewhere we > > want to go. Arbitration when there's a dispute causes less impedance to > > actually getting things done, while still achieving the same goals. > > But we're not even aware that there is a dispute, when people just > decide not to follow the guidelines. There is no "Packaging QA" group, > constantly auditing spec files. This would still be the same issue if guidelines would tunr into laws with exception policies. "If no one sees the crime, there was no crime." This thread seems to have been spawn by some explicit example of a packager consciously violating the guidelines. But some of us don't know what the example is. Could you post in some URL? Maybe the issue is not solved by turning guidelines into stone, but by something else. -- Axel.Thimm at ATrpms.net
Attachment:
pgpVVTL9nx4JE.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly