Lukas Rovensky wrote:
> On 4/2/10 2:44 PM, Andrew Gabriel wrote:
>> James Carlson wrote:
>>> Why does removal from OpenSolaris necessarily follow an announcement
>>> like that?
>>
>> As a user of SER, I would agree with that.
>
> By "as a user of SER" -- do you mean a paying customer?
>
>> EOF of VoIP routing in Solaris is not an appropriate thing to do.
>
> Can you elaborate on why it is not appropriate? I am very interested in
> understanding the facts concerning how having SER in Solaris is
> important from architectural point of view and/or how it helps to earn
> money (e.g., do we have and evidence on how many paying customers use
> it? Marketing did not provide me with such data).
All interesting stuff, to be sure, but I believe it's off-topic in this
discussion. This is about architectural review, not business issues.
The software is currently included as part of the system, and it has
known users. The question of whether they pay is not architectural in
nature.
The question is why this needs to be removed. Why not just leave it
there? As long as we're talking about money, why should Sun spend the
money necessary to do the work of removing this? Isn't it far simpler
and cheaper to leave it alone?
Normally, an architectural case for removal will supply some sort of
clear justification for the change. The justification is usually one of:
- feature has been supplanted; new one is available.
- feature has serious unfixable security flaws and presents a high
risk.
- feature is dependent on EOSL'd hardware or EOF'd software.
- feature has low value and is known not to have any users.
This one seems to be quite different. It's EOF because the upstream
isn't as active as the project team has decided they should be. But how
does that stop the bits from working for the existing users?
ARC members: is this precedent the ARC should set? I'd expect that new
precedent doesn't (normally) come from a fast-track.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
opensolaris-arc mailing list
[email protected]
