[katello-devel] moving to ruby 1.9.3

[Ivan Nečas]

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
>>
>> -d
> Yes, Aeolus is already doing this and IMO it is the only sane way to
> develop upstream. There is a natural split between upstream gem-only and
> distro-specific product packaging, let's let it happen.
>
> This means that some unlucky set of souls from each team is going to
> have to deal with the packaging each release, but that's the price we're
> going to pay regardless. We'll just rotate the personnel and let
> everyone feel the pain equally (this will also help keep a lid on the
> inclination to add things to Gemfile willy-nilly).
>
> --Hugh
>


-- 
Ivan