Apologies for the possibly off-topic policy comment here, but...
As a Sun Gold Support holder, I really hope that this example
of the exact wrong thing being done awakens someone at Sun to the
notion that bugfixes in OpenSolaris need to be proactively monitored
and considered for backport into supported systems.
I was about a month away from commencing a project to deploy
this specific use case and now know that I can't until there's a fix
in the recommended and security cluster for Solaris 10. So to state
my take on this in a positive light, thank goodness for this forum.
But in a negative light, my faith in the New Collaborative Nature of
Sun in general has just been decremented. Also, I was at risk of
experiencing major troubles with a bug in a system that I'm being
extremely risk-averse with and paying a ton of money to keep bug free
and stable.
I don't mind filing this as a support issue and probably will,
but it's not my job to keep the flagship *commercial* product bug-free
-- it's Sun's.
jake
On Feb 8, 2008 10:41 AM, Jim Dunham <[EMAIL PROTECTED]> wrote:
> Nigel,
>
> > Can I just check that I understand this correctly.
> >
>
> I really can't respond to this posting, as any attempt to answer it
> would likely link OpenSolaris policy and process, with Solaris policy
> and process, and they span different and separate business models.
>
> What is discussed in an @opensolaris.org discussion group can, and
> often does influence OpenSolaris, and the various Nevada builds.
>
> If one wants to influence Solaris 10 and the update releases, the
> means to do so is through a Solaris 10 support contract.
>
> Jim
>
>
> > So unless a customer, with a Solaris 10 support contract,
> > complains about about a bug, then it will not be
> > automatically fixed in the next release of Solaris 10.
> >
> > Does this mean it will NEVER be fixed in Solaris 10
> > UNLESS a customer with a support contract complains?
> >
> > (Are we talking just about iscsi target bugs here,
> > or is this a general policy applied to all bugs?)
> >
> > In the case of this bug, it is clearly a genuine bug,
> > with a straight forward fix.
> >
> > So it seems to me that after a period of testing in Nevada,
> > say 6 months, it would be very strange behaviour for
> > it not to be automatically fixed in the next release of Solaris 10.
> >
> > Surely with a policy like this, you are just going to frustrate
> > customers, like Eric Hill & Jim Barker, as they try & identify bugs
> > that are already know, and where a proven fix already exits.
> >
> > I would guess that most people going for Solaris 10
> > are looking for a solution where the best is being done by Sun
> > to avoid them having to go through the pain & wasted time
> > that bugs like this will cause to them.
> >
> > In this case I would expect those customer to feel
> > that Sun has has not given them the level of service
> > that they expected.
> >
> > We have the bugs database for OpenSolaris Nevada, which
> > tells us their status, and when they are fixed.
> >
> > But is there any any listing that shows which
> > bug fixes have been applied to a given release
> > of Solaris 10?
> > And a listing of which know fixes are potentially
> > available if they ask?
> > Thanks
> > Nigel Smith
> >
> >
> > This message posted from opensolaris.org
> > _______________________________________________
> > storage-discuss mailing list
> > [email protected]
> > http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
