Darren Reed writes: > James Carlson wrote: > > If the place you asked your question (the project team mailing list) > > really is the right place to get customer support, and you didn't get > > the expected level of support there, then that's a problem that needs > > to be fixed right away. Make sure you tell someone in charge of > > support about your problem, and get the support problem fixed so that > > customers don't stumble over it. If that wasn't the right place to > > ask for customer support (I suspect it may not have been), then I > > think you didn't follow the support process. Yelling at the toaster > > might not fix the coffee maker. > > > > Do you have any other suggestions as to where one would bring > up problems using crossbow in nevada?
I think we're talking about different things here. You jumped from a dissatisfying experience on Crossbow's project team mailing list to some rather unusual words about "support." I can't follow that leap. I don't think project team mailing lists are the same thing as customer support. Instead, I expect those lists would ordinarily have developer-to-developer communication. If support happens, it's on an ad-hoc basis. If you're going to say something about Sun's customer support, then I think you really need to go through one of the support channels first. They'll likely point out to you that you need to be using one of the supported products (snv_105 and pkg.opensolaris.org/dev are _not_), and then they'll work with you to get a solution. If that's what you'd like to do, then I'm sure that Jimmo or one of the other support managers can put you in touch with the right people. Otherwise, I think the discussion about customer support is well off target. I think that if you're playing with development bits and talking with the developers, then you're just another developer like the rest of us, and can be expected to go rummaging through the system to hack up what you want. That's quite a bit different from putting a supportable solution into a customer's hands. > > There just shouldn't be any cases where customers are out in the cold, > > trying to figure out why something deep in the bowels of the system is > > broken. That's why we test things before shipping them, and why we > > employ support people. > > > > Secondly, I think you're on a slippery slope here. Just how much > > should we twist system architecture to match undocumented use? Should > > we rule out the use of SMF and require plain text files for all > > service configuration instead? > > > > I think that's going to an extreme... > But if networking things start providing front ends to stuff in SMF, > the equivalent to "editting a text file" might be "running svccfg" to > directly manipulate the property rather than use a front end? If the property isn't documented to be used that way, then you're going to be in the same boat as the guy who hacks at *.conf files. You need to understand the internal constraints of the software itself to do that safely. If you don't, then the results aren't necessarily predictable or supportable. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
