On Sat, 2007-06-02 at 10:22 +0200, Hans de Goede wrote: > Patrice Dumas wrote:s > > On Sat, Jun 02, 2007 at 01:30:16PM +0530, Rahul Sundaram wrote: > >> Toshio Kuratomi wrote: > >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > >>>> Hans de Goede wrote: > >>>>> Not true many reviewers review on the latest stable, it says nowhere > >>>>> that a review should be done on rawhide. > >>>> Review is about guidelines and nowhere in the guideline does it even say > >>>> that the fucntionality of the package should be tested. When I suggested > >>>> that it be added I got back a knee jerk reaction to participate in > >>>> reviews myself. > >>>> > >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > >>> > >>> - SHOULD: The reviewer should test that the package functions as > >>> described. A package should not segfault instead of running, for > >>> example. > >> I suggested that it the "SHOULD" be changed to "MUST". A package that > >> doesnt even start shouldnt be getting past reviews. > > > > For simple applications, sure, but for libs, modules and servers? And for > > example when the package consist in multiple commands should them all be > > tested? > > > > Exactly, there are very good reasons why this is a SHOULD and not a MUST. I'm > sure almost every reviewer will give a program a test run in the simple program > case / scenarion. Why should they and what would this give? "Hello world" links as proof a compiler is functional? Assuring function is an upstream task, but judging whether a package is suitable for public use is the rpm maintainer's job. That's one prime reason why I repeatedly refused to approve certain packages. > Why must everything by regulated with rules, procedures and > more rules? Why can't we just TRUST each other, I'm getting very tired, sick > even, of this! You're not alone - I feel this merger is not a merger but a "hostile take-over by some dark powers". Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list