> Also, some of the packages you list above are what I'd class as
> development or test packages, which should be much lower priority for
> you. Focus on packaging runtime dependencies and you'll get there quicker.
Yeah, non-test, non-development ones seem to be more available than others.
Thanks for links btw, Dominic.
we update Ruby on Rails
> and many other gems. That means all packaged applications have to be
> updated as well. And that's why we
> have only one Rails app in Fedora.
Now there are two ;) I promise I will help with packaging. And don't worry
Sarup, I will do it on my own time.
A production ready application with unpackaged dependencies > one with all
> dependencies packaged but won't see use because of unfinished crucial
> features. The reverse would be true if we had several people working on the
> project simultaneously,
We will also need to bring Kushal on board with this.
Thanks a lot guys. You have been really helpful. I will read everything and
get back to you if I need help.
On Fri, May 29, 2015 at 11:45 PM, Sarup Banskota <sbanskota08(a)gmail.com>
> Very resourceful discussion.
> I have zero experience with packaging stuff myself, so what I may write in
> this email might be naive thinking.
> My short-term suggestion: IMO, you should continue with your work as usual
> on the git server and SparkleShare side of things for now. A production
> ready application with unpackaged dependencies > one with all dependencies
> packaged but won't see use because of unfinished crucial features. The
> reverse would be true if we had several people working on the project
> simultaneously, because someone's time spent packaging would mean another
> could work on features. Right now it's mostly you doing any programmatic
> activity, so how you spend your time affects when we can let people use it.
> Once we're into production ready phase, we can do two things in parallel:
> one, try to work with any feedback we may receive and two, start with
> packaging production gems (following the process Ken laid out). In fact,
> when it's visible people are using the application, we're more likely to
> see folks from the Ruby SIG want to guide us package gems, and we could
> definitely use that guidance.
> > Phase 1) Create an RPM that more-or-less follows all the packaging
> > guidelines, but bundles all its dependencies. You can build/ship this
> > RPM via Copr.
> > Phase 2) Switch your application from using Bundler to using
> > https://rubygems.org/gems/bundler_ext
> > Phase 3) Start dropping your bundled gems one by one and use the
> > system gems instead.
> > In hindsight I wish that I had taken this approach with Gitorious or
> > Gitlab, instead of only starting at the base of the dependency tree
> > and working my way upwards. It's probably good to work from both
> > directions at once. But starting at the top, with the app itself, will
> > give you the satisfaction and internal motivation of having something
> > that works today, even if it's not up to Fedora's standards.
> What do you think, @Emily?
Dear ruby wizards,
As of now, there are some open bugs in fedora-review's ruby plugin 
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
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.
Vít Ondruch wrote on 04/28/2015 11:52 PM:
> Dne 28.4.2015 v 11:35 Kalev Lember napsal(a):
>> On 04/28/2015 10:16 AM, Vít Ondruch wrote:
>>> Dne 28.4.2015 v 00:45 Kalev Lember napsal(a):
>>>> rubygem-rugged tdawson
>>> I am not maintainer of this, but please do not remove this. Rugged was
>>> broken by unannounced libgit2 update and there is still not official
>>> release fixing the compatibility. Removing this rubygem will mean just
>>> more work for everybody involved.
>> libgit2 is at 0.22.2 and looks like there's a matching new Rugged
>> release at https://rubygems.org/gems/rugged/versions/0.22.1b1 and the
>> package just needs updating. I am not sure what's up with the
>> maintainer, but maybe you could help them out by comaintaining
> If you take a look on version history , you'll notice that the "b"
> in version stands for beta. I have not checked with upstream what is the
> plan, though.
>  https://rubygems.org/gems/rugged/versions
But this is branched as "maint/v0.22", and I think using this beta
is much preferable than to keep broken deps, thought?
By the way, I am not a maintainer of rubygem-rugged, either, and
I don't use rubygem-rugged (currently). Anyway I want to know
how the current maintainer think of the current status.
If the current maintainer has no interest on this package,
maybe it is better to get this retired.
>> When it comes to shipping F22, I don't think it makes sense to include a
>> package that is so horribly broken that it cannot even be installed. But
>> if you guys are actively working on fixing it, I am sure we can try and
>> convince releng to give it a few more days before blocking so that it
>> can be pulled in through the freeze through the FE process:
>> Also, please note that Fedora policies allow adding new packages in the
>> updates repo, so even if something gets dropped now, it can always be
>> fixed and shipped in the updates repo at a later date.
> Which means re-review ...
Today while looking into the status of a Fedora / EPEL related issue, I
made good use of the isitfedoraruby website lookup the package
dependency tree . From what I know this visualization / data
aggregation is not available anywhere else and it still looks and works
Again kudos goes to all the students involved with the project over the
years for building a solid app!