Up to this point how frequently does this need to be updated? Is this mostly when the Fedora ruby guidelines are modified or do upstream Ruby updates entail changes to fedora-review? If the former is the case we should be able to synchronize fedora-review ruby plugin updates to guidelines changes. The later would be more difficult, perhaps the upstream tracking tooling Fedora could be extended / repurposed to assist with these updates. Thoughts? -Mo On 05/03/2015 11:27 AM, Alec Leamas wrote:

Hi, I am the one that reported #225 when I was working on updating fedora-review in regards to Ruby packaging guidelines. I did some changes back then, but there is more that could be done. One think I would like to ask is, if we now have some mechanism on how to distinguish various Fedora versions or whether we should consider fedora-review only for new rawhide packages? somehow maintained by the ruby SIG I could probably help again and make the plugin more relevant (perhaps even create some checks for vagrant plugin packages), but I am not sure I want to maintain it as fedora-review-plugin-ruby package. I will think about it though. Regards Josef ----- Original Message ----- From: "Alec Leamas" <leamas.alec(a)gmail.com&gt; To: ruby-sig(a)lists.fedoraproject.org Sent: Sunday, May 3, 2015 5:27:03 PM Subject: fedora-review ruby plugin Dear ruby wizards, As of now, there are some open bugs in fedora-review's ruby plugin [1] Basically, we need some input on these to sort out how this should work. However, here is also a more basic issue: who should maintain the ruby plugin? Frankly, keeping track of all upcoming changes isn't that easy when lacking specific ruby skills (which is what the open bugs are all about). Since some releases we have "outsourced" the java plugin to the java SIG; the fedora-review-plugin-java is now part of javapackages-tools. I think we have now stabilized the plugin interface. Basically, this has made life easier both for me (no java wizard) and for the java SIG which can enforce their packaging rules by modifying or adding tests. From my perspective it would be nice to apply this organization also to the ruby plugin i. e., create a fedora-review-plugin-ruby package somehow maintained by the ruby SIG. Thoughts? --alec [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1128094 https://fedorahosted.org/FedoraReview/ticket/225 https://fedorahosted.org/FedoraReview/ticket/238 _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

On 06/05/15 17:01, Mo Morsi wrote: Hi again! Sorry for late reply, other things to do... Anyway, I have pushed two feature branches ruby21 (f21) and ruby22 (f22). They are supposed to be identical from a ruby perspective, the commits are identical. These branches - Has the ruby plugin in a separate package (but still same srpm). - Should resolve https://bugzilla.redhat.com/show_bug.cgi?id=1221567 - Contains examples how to handle different fedora versions. - In particular, I don't know how to handle epel packages. I need some help with reviewing and testing. Until this is done, I doubt I can merge this. Instructions how to checkout and run devel version: https://fedorahosted.org/FedoraReview/wiki/UseDevelopmentVersion Cheers!

Hi, so I looked on the results from running your latest changes and I found one problem. It's the GemCheckUsesMacros check, which does not seem to work as expected. Excerpt from the review: Ruby: 151 [ ]: Specfile should use macros from rubygem-devel package. 152 Note: The specfile doesn't use these macros: %exclude 153 /usr/share/gems/cache/spring-1.3.6.gem, 154 /usr/share/gems/specifications/spring-1.3.6.gemspec It seems that the macros are expanded and therefor the check fails since in the spec file %exclude %{gem_cache} and %{gem_spec} are provided. I used rubygem-spring SRPM for this review but tried other gems as well. Regards Josef