Rob Clark writes: > Could we offer them a free copy of the source, maybe 90% of the profit ... :)
I don't think I understand, as the source itself is already public (so they have it for free if they want it). I don't think percentages of Sun's profits from Solaris are up for debate ... at least on this list. > > James Carlson wrote: > > On the plus side, there are nuggets of gold buried in the voluminous > > reports generated. The question is whether you want to invest your > > time and money into eyeballing those (and teaching all developers how > > to cope with slow run times and complicated output), or put more > > effort into traditional design and code reviews. > > We don't need to give "all" developers access. I think you do. If you don't, then the code tends to rot over time, and integrations become difficult if not impossible. For lint, the rule for ON is that you can't introduce new lint (or compiler) warnings. The gatekeepers run lint very frequently to avoid that bit rot. If you do introduce lint, that's something that has to be fixed quickly or -- if it can't be -- is good cause for a backout. In order for developers to get it right most of the time (introducing lint on every integration would be just untenable), we make the tools both easily available *and* easy to use. Developers must be _able_ to run the same lint checking tools the gatekeepers use on their own so that (assuming they're conscientious and not skipping steps) their contributions are error-free. Anything else can't reasonably be considered a gating item for integration, or a reason for backout. How can we hold developers to a standard that they've got no shot at all of meeting? Having a dedicated group that runs some source checking tool and files bugs on its results sounds possible in theory, but then we're no longer really talking about something like lint ... instead, it's more like a testing service. That's still possible, but it's a different class of solution, and the financial trade-offs are against other forms of testing. > Ask for volunteers and then a > few of the core Sun OpenSolaris developers can pick a half dozen people and > assign them to that group. I think you'd still have to find a way to fund this project. > As for the "run times" it does not run on _our_ computers is my understanding. True, but the run time is still important. A lint tool that adds an extra hour to the build is annoying but tolerable for last-build- before-integration. A tool that takes 24 hours or more to turn in full results is just not usable by most developers. It's not the sort of thing that I think is likely to turn up as a 'nightly' option, and thus not something that will be used often. And things that aren't used often end up rotting. > > put more effort into traditional design and code reviews. > Good plan. Pick a half dozen people (volunteers) and ask them to go through > the code. Have them send an email to the code's "owner" - "fix it or I will" > and > simply create "fix patches" that _we_ can apply (and the "owner" (origonator) > can look at) so that lint is clean. This sort of thing happens over at linux > and > gcc -- but they have a larger user base in the bugzilla. Knock yourself out. ;-} > > It's also worth mentioning that we're not yet getting the most that we > > can out of lint. In a nightly run with lint enabled, it runs with > > just the default 'level' flag. > Turn it up (on your runs, not in the distributed source). C.f.: bit-rot. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
