[katello-devel] moving to ruby 1.9.3

[Dmitri Dolguikh]

On 19/10/12 09:09 AM, Lukas Zapletal wrote:
>> I'll suggest, if you make a pull request for katello in github, that
>> you have resolved gem packaging/build before submitting a patch/code
>> that requires a new gem. In other words - hack away as you want, but
>> once you want it formally in Katello - clean it up and make it
>> easily consumable for all, wanting to install Katello from nightly
>> rpm based yum repos. If a pull request requires a new(er) gem, then
>> it should be rejected until that gem is packaged and available via
>> rpm in one of the usual repos for katello.
>>
> This is *EXACTLY* I wanted to write today.
>
> What Dmitri recommends is okay for me, as long as we define what
> DEVELOPMENT means. For me, the border line is a git pull request. Once
> you make it, you need to have an RPM package, working installation,
> basic sanity tests working.
>
> Cliff wrote it right, there's a nice English word for it: HACKING.
>
> I need to write right here, right now, that this is **VERY** important
> for me. Some folks were working so hard to get our nightly running,
> making all the packages, improving build process and this kind of
> things. Crossing the line would be step back I am not willing to accept.
> Having working RPM-based installation is nothing that is blocking
> something in development, or somewhere else.
>
> Therefore let's use rubygems for development, let's use rubygems.org and
> do what we need to do to make it easier to develop. We are actully doing
> this already, except we have our own repo not to change gem versions too
> often. But the work is still considered done, when RPMs are there,
> installation is tested and all developers and community can check the
> new feature the very next day reporting bugs, giving us feedback.
>
> Splitting our development into phases like hacking and packaging is not
> what we want to do. I want nightly, every single day. Packaging is
> sometimes hard task, sometimes there are dependency issues or license
> issues. Not doing it continuously would be suicide, having all the bugs
> reported in the packaging phase (perhaps at the end of
> week/sprint/release sprint).
>
> LZ
>

The current build process is hinged upon the idea of building for one 
platform (currently f16/rhel 6.x, going to be f17). I know that I'd like 
to have f18 packages (so folks don't need to wait 6 months for us to 
catch up). There's also non-rpm-based linux distributions.


It's because of this zoo the packaging *has* to be a separate stage. A 
build per platform, with platform-specific dependencies, a separate test 
run, etc. Separate, however, doesn't mean second-class. I'll 
wholeheartedly support the notion that broken package is just as 
important to fix as broken tests.

-d