[katello-devel] moving to ruby 1.9.3

[Dmitri Dolguikh]

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.

-d


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