On Mon, 2011-11-21 at 13:25 +0000, "Jóhann B. Guðmundsson" wrote: > On 11/21/2011 01:14 PM, Stanislav Ochotnicky wrote: > > Hello fellow devs, > > > > I am sure quite a few of you have done some reviews and thought "Hey, > > a,b,c and d could be automated. For E I could use some more > > information that can be automatically gathered". Some of you even > > wrote your own tools to do some of these things. > > > > Yet there is no unified tool, nor format for package reviews. There > > are more reasons, but I guess biggest one is there are just too many > > guidelines and there is probably no one who knows all of them. So few > > of us got together and hopefully created something that can be used by > > everyone. > > > > fedora-review[1] is now in updates-testing. It provides several checks: > > 66 generic tests (licensing, md5sum sources, bundling, etc.) > > 9 c/c++ specific checks (static libs, ldconfig, headers, rpath etc.) > > 13 java specific checks (javadoc, depmaps, jpackage-utils reqs) > > 8 R specific checks > > > > There are still many more checks waiting to be written. I'd like to > > see Perl, Python and Ruby checks, though I am not *that* familiar with > > their guidelines. I think the important thing here is that checks can > > be written in basically any language. We have simple JSON api[2] using > > stdin/stdout for communication. There is an example external plugin in > > documentation in perl and shell (though that's just mock-check). > > > > Our goal is for each language SIG (or other specific package group) to > > maintain their own checks together with their guidelines. > > > > * How you can help * > > - Tell us what checks are missing > > - Tell us if you think checks are doing it wrong > > - Create new checks (in language of your choice - we have JSON api) > > - do this even if the test cannot be automated. At least it will > > appear on the checklist for your packages! > > - Any ideas, bugreports etc will be much appreciated > > > > > > [1] https://fedorahosted.org/FedoraReview > > [2] https://fedorahosted.org/FedoraReview/browser/api/README > > Is this not something that releng/autoqa could use as well as in run > against all already existing specs and automatically file bugs if they > aren't ( and to keep things ) up to guidelines? As more and more extended tests become available one could think of this. However there are a number of cases where packages go against guideline (especially the rpmlint output must be clean)* for valid reasons. So running blindly the tool without a human look to the output to fill bug reports might not be such a good idea. Pierre * Ok, here we could use the integration between fedpkg lint and the .rpmlint file in the repo -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
