[katello-devel] moving to ruby 1.9.3

David Davis daviddavis at redhat.com
Thu Oct 18 12:45:06 UTC 2012 

+10

David

----- Original Message -----
> From: "Hugh Brock" <hbrock at redhat.com>
> To: "Bryan Kearney" <bkearney at redhat.com>
> Cc: katello-devel at redhat.com
> Sent: Thursday, October 18, 2012 8:22:47 AM
> Subject: Re: [katello-devel] moving to ruby 1.9.3
> 
> On Thu, Oct 18, 2012 at 08:14:42AM -0400, Bryan Kearney wrote:
> > On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote:
> > >On 18/10/12 09:22 AM, Ivan Nečas wrote:
> > >>On 10/17/2012 07:18 PM, Hugh Brock wrote:
> > >>>On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote:
> > >>>>On 17/10/12 05:04 PM, Jason Rist wrote:
> > >>>>>On 10/17/2012 09: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.
> > >>>>>>
> > >>>>>>
> > >>>>>>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).
> > >>Let's call it Fedora 18 support :)
> > >>>>>>
> > >>>>>>
> > >>>>>>-d
> > >>>>>>
> > >>>>>>_______________________________________________
> > >>>>>>katello-devel mailing list
> > >>>>>>katello-devel at redhat.com
> > >>>>>>https://www.redhat.com/mailman/listinfo/katello-devel
> > >>>>>I think this is what we should have been doing.  Can we not
> > >>>>>develop
> > >>>>>upstream in a more normal rails fashion and then deal with
> > >>>>>packaging and
> > >>>>>the like downstream? Or is that too much work?
> > >>>>>
> > >>>>I'm not sure why we aren't doing this atm. Considering that we
> > >>>>have
> > >>>>a suite of integration tests that is being run *after* katello
> > >>>>has
> > >>>>been packaged, it's safe to split development and packaging -
> > >>>>we are
> > >>>>able to catch the issues.
> > >>Here are some reasons why we care about RPM packages from the
> > >>beginning:
> > >>
> > >>1. Katello as a working thing by far isn't just a Rails app and
> > >>outside of the Ruby word gems mean nothing.
> > >>2. The installation process is part of the whole project. Using
> > >>the
> > >>installation process that will be used in production from start
> > >>means
> > >>catching the issues sooner than just before release
> > >>3. Creating an RPM forces you to thing about the license soon.
> > >>It's
> > >>not pleasant to find out that your code is not shipable because
> > >>of the
> > >>licensing issues
> > >>4. The code has to work on the target platform (which is Fedora
> > >>an
> > >>RHEL for us), and (as Metallica sings) nothing else matters
> > >>5. Things like selinux need to be solved as well.
> > >>6. This approach is Continuous Delivery compliant: and now we are
> > >>having 2-months CR release cycle
> > >>
> > >>You can do whatever you want on the development machine. And I
> > >>have
> > >>nothing against improvements that will make development on
> > >>non-Fedora
> > >>based systems easier. But when you want to merge into the master,
> > >>you
> > >>have to count on the fact that somebody will want to install it
> > >>on
> > >>test or production machine.
> > >>
> > >>Unlike Aeolus, we don't try to get Katello into Fedora official
> > >>repos
> > >>yet (though our client packages are already there). And getting
> > >>the
> > >>packages to Fedora it the thing that makes the packaging harder
> > >>and
> > >>slows down the process: waiting for 2 weeks till the library can
> > >>be
> > >>used is just too much. Therefore we have our own Koji instance,
> > >>where
> > >>the deps go in the first place, and then we can work on getting
> > >>them
> > >>to Fedora later while development goes on.
> > >>
> > >>So what I'm saying is: it would be great if someone clones our
> > >>repo,
> > >>runs bundle install and the server runs on every platform (though
> > >>I
> > >>don't thing forcing the developer to run all the deps (like Pulp,
> > >>Candlepin, Katello-Cli) from source would make the Rails
> > >>developer
> > >>happy. But giving up our nightly builds and all the good things
> > >>that
> > >>go with it just for this reason is really huge step backward. And
> > >>I
> > >>don't see a reason that this two things couldn't co-exist
> > >>together.
> > >>
> > >>-- Ivan
> > >
> > >I think we need to standardize on whether replies go above or
> > >below the
> > >original comment :)
> > >
> > >
> > >I don't think anybody participating in this thread suggests that
> > >packaging is not important. Nor is anyone talking about about
> > >abandoning
> > >nightly builds, etc.
> > >
> > >I'm suggesting that we remove development process dependency on
> > >build
> > >artifacts. Let's use rubygems.org in development (I know of
> > >several
> > >people who are doing this already; it's *very* useful to be able
> > >to add
> > >new dependencies in development quickly). Let's use
> > >system-provided gems
> > >in packaged Katello.
> > >
> > +1
> 
> This is exactly the mode we are pushing to in Aeolus. I should point
> out
> that it is not only the normal mode for upstream Ruby projects, it is
> the normal mode for *almost all* upstream projects that are not
> completely Red-Hat centric.
> 
> libvirt is a good example of this. It is a C project, as you know,
> and
> Red Hat delivers it entirely packaged as RPM. But Daniel Veillard,
> the
> libvirt maintainer, *will not even allow rpm spec files* in the
> libvirt
> tree upstream, just as he does not allow debian package
> instructions. libvirt upstream is delivered and installed with tar
> -xvzf
> libvirt.tgz; ./configure; make; make install.
> 
> The libvirt crew, because they work for Red Hat, also get to spend a
> good bit of time maintaining the Fedora and RHEL rpm specs. This is
> an
> overhead investment that is worth the effort because it makes it
> easier
> for Red Hat to deliver libvirt. The libvirt crew *also* spend some
> amount of time maintaining the .deb build, becasue it's good for
> community adoption, but this is also done out of band. Core libvirt
> contributors however do not get concerned with packaging.
> 
> I see no reason why any of our Ruby projects should follow a
> different
> development mode than this.
> 
> --Hugh
> 
> --
> == Hugh Brock, hbrock at redhat.com                                   ==
> == Engineering Manager, Cloud BU                                   ==
> == Aeolus Project: Manage virtual infrastructure across clouds.    ==
> == http://aeolusproject.org                                        ==
> 
> "I know that you believe you understand what you think I said, but
> I’m
> not sure you realize that what you heard is not what I meant."
> --Robert McCloskey
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

More information about the katello-devel mailing list