I'd just like to throw in a comment "from the gallery" here.
Solaris (and if I'm honest, Linux) is a great example of where
the whole is greater than the sum of the parts. If we removed
every binary that we couldn't identify a paying customer for,
there wouldn't be a lot left (do we need all those window
managers? Isn't one shell enough? Do we need both 'cat'
and 'more'?).
The strength of Solaris is that people use it for one thing,
but discover that it has other features, and that can lead
on to other development. Granted, if something is obsolete and
has been replaced by something newer we should track that, but
removing something just because we can't say who uses it and
it seems to save a few pennies for one team is, in my view, an
error.
In my 18-odd years at Sun I've seen all too many projects EOLed
because the owning team didn't see sufficient gain, and the
result has been financial impact to other projects where the
feature has been a small but useful component.
We need to look at this sort of thing from a whole-company
perspective, not just for each BU's individual bottom line.
That is, surely, the remit of PSARC/LSARC.
Happy Easter :)
Steve
Lukas Rovensky wrote:
On 4/2/10 4:21 PM, James Carlson wrote:
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.
Well, to me there is always mixture of business and architectural views
in cases like this. Keeping something in Solaris cost money becasue the
something has to be supported an it is not for free. Besides, bringing
SER to Solaris was based on business reasons and not on architectural
needs (LSARC 2004/324).
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?
Why to remove it -- as per the architectural rules EOF like this are
possible typically between minor versions (Solaris 10 -> Solaris Next).
If we leave it in Solaris Next then SER will be there for another 10+
years and by this time it will be really old / dead / rotten. Leaving
a supported FOSS product like SER in Solaris is not for free. For
example, if there is a vulnerability issue in it then "someone" will
have to fix it. For dead products it means that Oracle will be the
"someone". So, no -- from long term point of view it is cheaper to
remove dead stuff from Solaris.
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?
I am not proposing to remove it from S10 but from Solaris Next. So,
existing users of S10 can still have it. Would it sound OK to you if
SER is moved to /contrib?
Lukas
ARC members: is this precedent the ARC should set? I'd expect that new
precedent doesn't (normally) come from a fast-track.
_______________________________________________
opensolaris-arc mailing list
[email protected]
