fedora-review ruby plugin

[Alec Leamas]

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

[Mo Morsi]

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:
>  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

[Alec Leamas]

On 03/05/15 18:02, Mo Morsi wrote:
>  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? 
The basic idea is that the plugin should be updated iff the ruby 
guidelines changes. Ruby upstream changes shouldn't have a direct impact 
as long as the guidelines don't change.


Cheers!

--alec

[Josef Stribny]

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?

>  create a fedora-review-plugin-ruby package 
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

[Mo Morsi]

On 05/06/2015 08:22 AM, Josef Stribny 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? 
I'd suspect that fedora-review is always targeted at the latest 
guidelines, which would apply to rawhide at the very least as well as 
new and updated packages in existing releases. So even in a single 
Fedora version new guidelines could be adopted and packages updated to 
use them (often with the "if 0%{?fcXY}" checks).


> > create a fedora-review-plugin-ruby package
>  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 
I can help co-maintain if need be.

   -Mo

[Alec Leamas]

On 06/05/15 17:01, Mo Morsi wrote:
>  On 05/06/2015 08:22 AM, Josef Stribny 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? 
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!

[Josef Stribny]

>  I need some help with reviewing and testing. Until this is done, I 
>  doubt I can merge this.
>  
I am on it. If I understand it right I should run ruby21 branch when 
using Fedora 21 workstation, right?
Anyways, it complained about not having licensecheck (from 
devscripts-minimal package if anyone else come across it). I will look 
on what's in the report now.

Josef

[Josef Stribny]

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

[Alec Leamas]

On 22/05/15 15:40, Josef Stribny wrote:
>  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
>  
Thanks for a really good catch! It turned out that this was because 
spec_file.py didn't parse the %files section correctly.

It's actually a pain, but although rpm implements the spec file parsing 
there is no interface to retrieve the raw text. I have had a rpm patch 
reviewed adding an interface, but it was rejected :(

The changes are yet not checked in, but later today I will probably 
merge the ruby-f22 branch.

Cheers!

--alec