> Re: [osol-discuss] Can Solaris be discussed here? > From: Shawn Walker ([EMAIL PROTECTED]) > Sent: Sat 8/02/08 5:31 AM > To: [EMAIL PROTECTED] > Cc: opensolaris-discuss@opensolaris.org > > These lists are for OpenSolaris, not Solaris. I'm not > certain what gave you the idea that Sun has abandoned > Solaris 10 maintenance. However, I can assure you > that is not the case. Read more about the Solaris > Life Cycle model > here:http://www.sun.com/software/solaris/lifecycle.xml > You may want to visit the bigadmin pages for further > discussion of Solaris 10 topics: > http://www.sun.com/bigadmin/home/index.html Cheers,-- > Shawn Walker > ------------------------------------------------------ > ------------------ > > Sun can write all the PR things they want to claim > that they are not abandoning Solaris. But let's look > at the real stuff. For example, I would refer you to > a thread "How to report bugs ?" in Sun's "General > Solaris 10 Discussion" forum > (http://forums.sun.com/thread.jspa?threadID=5309841&ts > tart=0). And one can judge how much attention Sun is > giving to Solaris nowadays. Someone wanted to report > a Solaris bug and so far nobody answered such a > simple question. You sounded like you are a Sun > employee. I am glad that there are Sun employees > reading posts in this forum, but how come there does > not appear to be any Sun employees reading that > Solaris 10 forum? And there are many unanswered > posts there. I personally posted quite a number > there lately and quite a number, if not most, of them > were not answered. The facts speak for themselves.
You sound like you're looking for something resembling support for a commercial product, without having to pay for a support contract. That's not likely to be sustainable (support people have to eat, companies have to keep a minimum stock price, bills have to be paid, etc). Having said that, perhaps it would be good to have a way for anyone to _report_ bugs, but with no assurance of any acknowledgement. A very structured form or even an automated dialog might help pre-screen enough to keep the volume and quality of the bug reports manageable, and there's nothing that says that bug reports from someone without a support contract couldn't be at a lower priority. For instance, the input should _not_ ask how severe the bug is; rather, it should ask if it results in data corruption, application crash, limited denial of service, total denial of service (system freeze), system crash, etc, or other (fill in the blank). Those describe hopefully factual characteristics rather than the perceived consequences to the submitter. To the extent that a good range of predefined choices could be provided, and some data standardization of fill-in-the-blank fields were done, that ought to also be more amenable to automated consolidation, filtering, etc. Indeed, if the submitter chose to supply an email address, good PR might even argue in favor of automatic tracking status updates to submitters (after consolidation) by email, from a return address that didn't accept replies, and with a disclaimer that no obligation existed to non-paying bug reporters. Quite possibly the only difference would be that for an authenticated paying customer, there would be away to indicate the impact on the customer of the bug being reported. I don't by any means agree that the lack of such a thing constitutes "abandoning" a product for which considerable support _is_ available to paying customers. However, if designed correctly (relatively high initial cost) to have a low ongoing cost while providing reasonably good quality data, such a reporting mechanism might be worthwhile in terms of recognizing and fixing bugs (that might affect paying customers too) more proactively. And anything learned about producing high quality bug reports from low quality sources (untrusted (in the sense that you can't assume that they are not wilfully submitting bogus data) persons that you're not going to spend man-hours having a person communicate with) should also be applicable to more effectively interacting with paying customers. What some people may of course not like is that the best case for such a bug report would be if it could be submitted from the system in question, and something could be downloaded that would collect diagnostic information and (after showing it to the submitter for approval) submitting that as part of the bug report. Other problems: not much could be done with identifying (let alone expecting that they were properly built) unpackaged (self-compiled or downloaded from some random place) applications. (I'm thinking it really helps to know the exact version, source, etc of an app that's having trouble allegedly due to a system bug.) Starting points for the pieces of this already exist. I know that there are tools to collect system configuration info, for instance. But I tend to doubt that all the pieces have been put together and the availability publicized, or such questions as this might not crop up as often. Would it be worth doing? That's the call of those that would pay for doing it. But I think it would be interesting to hear why it isn't being done already. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
