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?