On Fri, Jan 14, 2011 at 8:54 AM, Mohammed
> On 01/14/2011 04:08 AM, Vít Ondruch wrote:
>> Dne 14.1.2011 09:50, Mohammed Morsi napsal(a):
>>> On 01/14/2011 02:58 AM, Mohammed Morsi wrote:
>>>> On 01/12/2011 11:29 AM, Vít Ondruch wrote:
>>>>> Are we really going to replace Rails 2.x with Rails 3.0.x or should
>>>>> live side by side? Your specs shows the later and I am also fan of
>>>>> later. However, I am not sure everybody else will be happy with this
>>>>> step. Was it discussed before? Sorry, I am not following Fedora
>>>>> development that long :/
>>>> Yea, we went back and forth on this a few times and I believe the
>>>> general consensus was to do the update.
>>>>> Dne 11.1.2011 19:11, Mohammed Morsi napsal(a):
>>>>>> The Rails 3.0.3 RPMs for Fedora are just about ready to
>>>>>> look at and review the Specs and SRPMs below:
>>>>> There are missing dependency on railties and bundler, where there is
>>>>> enforced reference to rake which should not be necessary according
>>>>> rails gemspec:
>>>> Good catch on these, I probably already had them installed when I was
>>>> building these rpms. I'll add them to a revised set of rpms which
>>>> send out soon. I also noticed a missing activemodel dependency for
>>>> activeresource (which isn't a big deal since activemodel 3.0.3 has
>>>> submitted to Fedora) as well as a rack ~> 1.2.1 dependency for
>>>> actionpack. The latter is a little more concerning as the current Rack
>>>> version in Fedora is 1.1.0 and if Rails 3 doesn't play well with
>>>> (we can try patching rails itself) we may have to update that as well.
>> Well I did not have chance to go through all the specs, so it was the
>> first thing I spotted ;)
>>>> ruby-sig mailing list
>>> I just ran the actionpack 3.0.3 test suite against Rack 1.1.0 and
>>> everything passed. Also the Rails 3 commit updating the dependency to
>>> Rack 1.2.1 seems pretty trivial, the only actual code change is to a test.
>>> Of course ideally we'd just update Rack to the latest upstream release
>>> (1.2.1) in F15. Filed a request w/ the maintainer (jeroen) to do so.
>>> ruby-sig mailing list
>> I have good experience with Rack backward compatibility. Actually the
>> Rack API is so simple that it would be surprising if it didn't work :)
>> But what prevents us from updating Rack?
> We don't own Rack :-) Nor are either of us co-maintainers. Its really
> up to the owner to push updates to the package. Now that being said,
> there are steps which can be taken if a package goes stale for too long
> after an update request.
>> And regarding the required versions, I am sure that Rails are pushing as
>> new gems as they can, which is not always what we need for Fedora. It
>> seems to me that the same case is with Arel. Rails are requesting Arel
>> 2, but the Arel 1 should be compatible IMO (I did not tested it though).
>> ruby-sig mailing list
> Good to know. I had the feeling that this was the case when I sent out
> my original list of rubygem packages that would need to be updated to
> work with Rails 3. Do you know of any way to test this short of running
> each package's test suite against the older versions of the deps?
> Perhaps we can develop some more cross-gem compatibility test cases at
> some point. This all will get trickier as more projects use bundler as
> we'll have to patch them to remove the specific versioned dependencies.
> ruby-sig mailing list
I think I am an owner of Rack. If you ask for co-maintainer status,
I'd be happy to grant.
ruby-sig mailing list
Hrm, according to the pkg db, kanarip is the owner, and you have
watchbugzilla / watchcommits rights but 'commit' is still awaiting
review and you haven't applied for 'approveacls'. Is this information
I applied for all the rights myself and have sent and update request to
Jeroen. We can take it from there.