[katello-devel] moving to ruby 1.9.3

[Bryan Kearney]

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