On Tue, Oct 27, 2009 at 10:52 PM, Alan Coopersmith
<Alan.Coopersmith at sun.com> wrote:
> This sounds like a topic for on-discuss (cc'ed) more than the ARC - since
> it's really up to the ON gate staff & c-team if they want to change their
> traditional policy of removing code that Sun no longer supports to allow
> it to remain in the gate for the benefit of other community members who
> still want to use it.
>
> ? ? ? ?-Alan Coopersmith- ? ? ? ? ? alan.coopersmith at sun.com
> ? ? ? ? Sun Microsystems, Inc. - X Window System Engineering
>
> James Carlson wrote:
>> Garrett D'Amore wrote:
>>> James Carlson wrote:
>>>> 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.
>>
>> Indeed. ?And that's a fairly important issue about a consolidation.
>> There has to be consensus (or at least a set of known rules) governing
>> what it contains.
>>
>>>> (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.
>>
>> This doesn't quite sound right to me.
>>
>> The way I look at it, there are contributors to ON, and those
>> contributors are all held to the same standards: you have to test what
>> you deliver and allow others to test with it. ?There isn't a requirement
>> that you hold a Sun badge, just that you comply with the rules. ?It
>> isn't or shouldn't be ON-versus-community, but rather ON-in-community.
>>
>> Before a "new" platform is delivered, the team doing that work carries a
>> pretty heavy load, and has to keep up with ON's changes privately. ?Then
>> they deliver, with the C-team's blessing, and it becomes everyone's
>> problem to deal with it.
>>
>> Is that what we're really discussing here? ?That ON's content, at least
>> in terms of platforms supported, is at Sun's discretion, and we need (or
>> you'd like to have) a separate ON in order to meet non-Sun developer's
>> needs?
>>
>> If so, then that's a sad result. ?Nobody's stopping you (or anyone else)
>> from doing it, but it's the sort of fork that just gets expensive and
>> divisive over time. ?Forking is technically as simple as setting up a
>> public source repository.
>>
>>>> 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.)
>>
>> The rules aren't there to stop people who want to hurt themselves. ?:-/
>>
>> Instead, they document what is known to work -- and what's known not to
>> work.
>>
Hi Alan, Garrett, James: This is an important topic.
I?m glad to see you guys caring about it)))
I think branching off is only the last thing one should consider.
But if those legacy (primarily SPARC) drivers really do get removed
from ON, then it is good to know that somebody is free to go that
route. Whoever decides to do so. Thanks from me in the name of
die-hard SPARC owners/users (forgive me my x64 Laptops, but I won?t
give away my reliable Sun SPARC-gear).
p.s. I finally came to it and set up a new local copy of the x11-gate
on one of my Blade 2000?s. During the recent months I had too many
other things to work on.
More later. The legacy community supported SPARC gfx drivers are not dead.
regards
%martin
