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.
Aditya
On Fri, May 29, 2015 at 11:45 PM, Sarup Banskota <sbanskota08(a)gmail.com>
wrote:
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.
>
+1.
What do you think, @Emily?