[katello-devel] moving to ruby 1.9.3

Hugh Brock hbrock at redhat.com
Fri Oct 19 17:14:45 UTC 2012


On Fri, Oct 19, 2012 at 02:25:24PM +0200, Martin Povolny wrote:
> On Thu, Oct 18, 2012 at 04:33:13PM -0400, Hugh Brock wrote:
> > We did this for a while with Aeolus. Unfortunately it confuses the hell
> > out of ruby developers who don't know anything about RPM.
> > 
> > Imagine for a moment that you are a top-notch rails programmer. Unless
> > you already work at Red Hat, chances are you've never had to write an
> > RPM spec before.
> > 
> > Now let's say by some miracle you become interested in contributing to
> > upstream Katello, or Aeolus. You poke around, talk to people, figure out
> > that the feature you want isn't already in progress and that upstream
> > would like to have it. So you go off and write the thing. Along the way
> > you add your friend's handy gem that does XYZ.
> 
> You yourself used so many conditions, that the case is really unrealistic
> ;-)
> 
> If someone comes with great code and does not know the RPM stuff I am
> sure someone will be happy to do the rpm-specific work for him. 
> 
> But that's just placing one more hypothesis on top of another.

I completely disagree. I have *lost good ruby developers* because they
thought our obsession with packaging was crazy. This is not a made-up
case. 

> > 
> > When you submit your patch upstream, we say, oh, gee, sorry, we don't
> > take patches that add gem dependencies unless you also wrap them up in
> > this arcane packaging format that is redundant (for rubyists) and not
> > the least bit useful to you.
> > 
> > I don't think I need to describe what the typical reaction would be...
> > 
> > If we ever want any of these projects to fly on their own without 100%
> > support from Red Hat, we have to stop doing things that make them weird
> > to non-RH folks. Like even talking about RPM... or, god help us,
> > Fedora. 
> > 
> 
> I have to say that the reasons for doing RPM builds as a integral part of
> the development process seem very valid to me. And also valid in the
> context of Conductor.
> 
> I would point out 2: 
> 
> Unless you work on the packages all way through the project, there will
> surely come some very unpleasant surprise when the time comes to release
> (examples where given in the discussion and also seen in the project
> history!).

We've been through this, and frankly we overstate the problem. Yes,
packaging involves pain. Yes, sometimes you add gems that cause problems
later. But why does the review of "I want to have this gem" have to
involve "Go package this thing as an RPM"? We can, and should, carefully
review gems that we add to the project to make sure that they are
licensed correctly and that the code is reasonable. No decent Ruby
developer would argue with that. This does *not* mean that we have to
then force people to deal with re-packaging those things as RPMs. That
is a *productization* task and it should be handled by a
*productization* team.

> If every developer is working in his own setup on his own virtual
> machine using his very special environment including downloading gems
> from rubygems and pulls code from github and on the other side the user
> or customer uses and RPM install on a different distribution and on
> variety of real hardware, then the gap between the customer and the developer
> is getting HUGE.
> 
> I believe that Red Hat has the tools to make the gap as small as
> possible, and has people with the expertise to use them. 

Yes. In the productization phase, we have that. It is part of the
expense we bear when we're dealing with rolling stuff up and hardening
it. It does not need to happen upstream.

> Automated package build tools and tool to install nightly build packages
> to freshly installed distros providing developers access to their new
> code running in the environment the customer/user will have is the way to
> close the gap I think.
> 
> Why not to see the problems the packaging may bring or the user might
> experience as early in the development process as possible?

Because it pollutes the upstream development process and makes it
completely foreign to non-Red Hat developers. Building community is hard
enough without putting roadblocks in the way.

--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



More information about the aeolus-devel mailing list