[katello-devel] moving to ruby 1.9.3

[Cliff Perry]

On 10/18/2012 01:14 PM, Bryan Kearney wrote:
> 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 :)
>>

In the middle - don't standardize - cos people will then complain. We 
are all grown adults and can adapt to everyone's habits.

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

Personal opinion.

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.

Cliff

> -- bk
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel