Drop toolchain support for rtems4.8, rtems4.9 and CentOS5?

[Oyake, Amalaye (3496)]

Ah ... This is about CentOS 5 ... I see your point.

On 3/15/13 3:46 PM, "Joel Sherrill" <Joel.Sherrill at OARcorp.com> wrote:

>The crux is the matter is that we host old binaries that will never be
>updated. That is how it has always been. CentOS 5 has simply reached the
>point where the pain for Ralf (a volunteer) exceeds what he is willing to
>put into it for free.
>
>I agree that there are users on old versions. They have not communicated
>their maintenance requirements to the community and not sponsored any
>continued maintenance.
>
>Sorry to sound callous but if they place value on CentOS 5 having
>continued support, it needs to be communicated and be worth the pain.
>Ralf builds binaries for a wide variety of OSes and distributions. He
>generally holds on as long as it doesn't cause excessive pain. CentOS 5
>has ancient tools and it is difficult to build modern tool versions. Not
>impossible just work.
>
>--joel
>
>
>
>"Oyake, Amalaye (3496)" <amalaye.oyake at jpl.nasa.gov> wrote:
>
>
>Dear RTEMS Maintainers ...
>
>with respect to older toolchains, I would check if older Space missions
>are using the older builds. I think that ESA is baselined rtems 4.8 or
>some variant thereof ... It would be difficult to do some software
>maintenance/update on an older spacecraft if the toolchains needed are
>gone.
>
>The thing to note is that Legacy Hardware pretty much does one function
>well and stays in use for a long long time ...
>
>
>On 3/15/13 12:38 PM, "rwas" <rbtwas at gmail.com> wrote:
>
>>Ralf Corsepius wrote:
>>>  Hi,
>>>
>>>
>>>  * rtems4.8, rtems4.9 (All host OSes): I do not see much use in
>>>  keeping these. RTEMS-4.8 and 4.9 and their toolchains haven't seen
>>>  any activities for a long time and are de-facto dead.
>>>
>>>  Keeping the packages, to me only means carrying around historic
>>>  ballast of questionable value, I'd rather get rid off, ASAP.
>>
>>This sort of talk makes me real nervous. Recently, in an attempt to
>>reconstruct
>>the bsp development for the mvme167, I found myself downloading older
>>gdb, gcc,
>>and rtems versions. The gdb, and gcc projects apparently see the value
>>in archiving
>>older versions. IMO there is at least one very valid reason for doing so.
>>
>>Your attitude seems to not only forget the past, but to eliminate any
>>trace of it. I for one
>>view it as data, important data. The cost of keeping it on today's very
>>inexpensive harddrives
>>seems well worth the potential value obtained for end users for things
>>like version archeology.
>>
>>Recently, you removed perfectly good tools from the rtems system for
>>opensuse11.3. A version
>>of suse I was still using. I can understand dropping maintenance of the
>>tools. But why you felt it
>>necessary to *burn the books* (so to speak) on perfectly good tools is
>>beyond my reasoning.
>>
>>My project uses 4.9.3 and its tools. My project has suffered many slips
>>in schedule and really can't
>>afford the down time to convert to 4.10'ism's. When I say the project
>>can't afford it, I mean any slips
>>put the project at risk of cancellation. That and the ~30jobs that go
>>with it.
>>
>>  It's still not clear to me that 4.10 for the mvme5500 is ready for
>>primetime. We have been successfully
>>using 4.9.3 for >3yrs. It's not broke, I don't have time to fix it.
>>
>>If it's a matter of disk space, let me know. I'm sure I can come up with
>>a harddrive for the rtems project.
>>
>>Robert W.
>>
>>
>>
>>_______________________________________________
>>rtems-users mailing list
>>rtems-users at rtems.org
>>http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>_______________________________________________
>rtems-users mailing list
>rtems-users at rtems.org
>http://www.rtems.org/mailman/listinfo/rtems-users