> > 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 <[email protected]> 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? > > >
_______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
