[katello-devel] moving to ruby 1.9.3

[Lukas Zapletal]

Well, we have been there :-)

Ten months ago we have decided to remove Gemfile.lock from our git.

The issue with lock file that time was it was difficult to track changes
in it. Since we use github pull requests now, it should be much more
easier to keep it fit and refuse any version changes which are not
appropriate.

It is also necessary to have the ability to run against Ruby 1.8 and
Ruby 1.9. Dmitri has a new version of Gemfile that works with both, and
we should keep it in this state for a while. It's a good to have ability
to run unit tests also on older 1.8 for some time IMHO, because we can
be asked to backport some feature onto RHEL6 SE.

So, yes, basically this is +1 :-)

LZ

On Fri, Oct 19, 2012 at 08:14:49AM -0400, David Davis wrote:
> I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea.
> 
> David
> 
> ----- Original Message -----
> > From: "Lukas Zapletal" <lzap at redhat.com>
> > To: katello-devel at redhat.com
> > Sent: Friday, October 19, 2012 4:21:23 AM
> > Subject: Re: [katello-devel] moving to ruby 1.9.3
> > 
> > On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote:
> > > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote:
> > > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom
> > > >ruby
> > > >repository for bundler-based installs, and switch to rubygems.org
> > > >repository instead. Folks still would rather use Fedora-provided
> > > >gems
> > > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are
> > > >yum-aware. This would simplify dependency management during
> > > >development.
> > > 
> > > this sounds appealing, what is the best way to 'try it out' from a
> > > fresh install perspective?
> > 
> > I like the idea of getting rid of our gem repo, but lemme ask this.
> > Is
> > there any way of controlling how folks are updating versions in lock
> > files?
> > 
> > I mean, we built our gem repo because of "instability" of
> > Gemfile.lock
> > file. Very often someone commited a version bump of something
> > incompatible - bang.
> > 
> > I expect this should be much better now since we use review request
> > and
> > we will discuss every single Gemfile change. But in any case, we
> > should
> > take care!
> > 
> > > >As the next step I'd like to propose to switch to rails 3.2 (the
> > > >version
> > > >of Rails that's going to be shipped with f18) in master (which is
> > > >what
> > > >Aeolus folks did).
> > > >
> > 
> > Why not, but I vote for only upgrading Rails and keeping other
> > libraries
> > on oldest versions possible. I mean, not doing "bundle update" for
> > all,
> > but just for Rails and doing this carefully step by step, library
> > after
> > library. Of course, while keeping versions in our spec files in sync.
> > 
> > ps - But what I do not agree is splitting up into development phase
> > and
> > packaging phase :-) I sent another reply in the thread. Every single
> > dev can do the split on his own - making "longer" development cycle
> > in
> > his own branch and preparing packages just before the git pull
> > request.
> > 
> > LZ
> > 
> > --
> > Later,
> > 
> >  Lukas "lzap" Zapletal
> >  #katello #systemengine
> > 
> > _______________________________________________
> > katello-devel mailing list
> > katello-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/katello-devel
> > 

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine