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