James Carlson wrote:
> Alan Coopersmith wrote:
>
>> James Carlson wrote:
>>
>>> Peter Dennis - Sustaining Engineer wrote:
>>>
>>>> Garrett D'Amore wrote:
>>>>
>>>>> I've been contemplating setting up a community repo that could
>>>>> reintegrate some of the platform support that is being removed from ON
>>>>> proper, into a separate "legacy" consolidation, that would not be
>>>>> supported by Sun.
>>>>>
>>>> I think that this would be an interesting and valuable thing to be done.
>>>> A place to put legacy code that can be maintained (and supported...)
>>>> by the folks interested.
>>>>
>>> Interesting and valuable if it can be done.
>>>
>>> This isn't the first time such a thing has been discussed, and in the
>>> previous runs at the problem, the real issue is not the mechanics of
>>> setting up and maintaining a separate gate, but rather that 99 and
>>> 44/100ths of the effort is actually a legal review to determine what --
>>> if anything at all -- can be released, and under what terms.
>>>
>> Is that really an issue though for code that's already in the open ON gate,
>> but which Sun no longer wants to support? Presumably all that legal review
>> happened for the ON gate publication. (For the graphics drivers, sure,
>> you're not going to see us release the source to the drivers that aren't
>> already open, which means pretty much just cg6. But there's a lot of other
>> devices on the old Ultra workstations besides just graphics.)
>>
>>
>
> I'm puzzled. Why would you need it at all for code in the ON gate?
> Anything you want is right there in the hg history. If someone has got
> the time to commit to maintaining it, then bringing it back should be
> relatively easy -- easier than forking off to a separate gate.
>
Some one might want to *modify* those sources. Keep them updated so
they work with current versions of ON, etc. The hg history is there,
but it isn't "alive" in the sense that you don't make changes to it
unless you're planning on integrating those changes into a delivering
product.
> (Does the ON C-team care who is maintaining the code, as long as it's
> being maintained? I'd expect that they don't require someone to hold a
> Sun badge in order to claim that something is supported. Right?)
>
Yes, they do care. Stuff in the gate has to be built, if you're not
delivering it it requires exception lists, etc. There are implications
for packaging, as well. The point here is that Sun has abandoned these
things (and more will come) -- and with good reason in most cases.
However, if the community wishes to separately keep the stuff alive, it
should be possible to do so.
Continuing to carry legacy/unsupported baggage in ON forever is not
really a good solution.
> Yes, it's all the other drivers that I'd be more concerned about.
> Without those, you've more or less got a fancy boat anchor.
>
>
Maybe. Tadpole SPARCLE support is one that could be revived pretty
easily. I expect some of the other hardware drivers I'm looking at
EOF'ing, and eventually platmod support (e.g. platmod stuff for
SUNW,Ultra-2, the stp4020 driver, the bpp driver, later the audiocs
driver, even SPARC delivery of the sdcard modules) all are things that
are useful today, and will be useful going forward to *some* people who
still want to run on older SPARC equipment that is no longer supported
by Sun.
The way I envision this is as a separate repo that you check out,
*along* with a parallel copy of ON, and build. The build could look
into ON for sources or headers which are still there (such as for
"Consolidation Private" interfaces or to pick up common sources so that
SPARC versions of them can be recompiled.)
Yes, this would violate the PSARC rules for Consolidation Private, but
I'm thinking of a project that operates well outside of ARC and Sun
rules, as a community effort. (And you'd have to match "build numbers",
so the community effort would have to keep the project in sync with ON.)
-- Garrett
