On Sat, 5 Jan 2008, Alan Coopersmith wrote:
> Pete Bentley wrote:
>> Judging from the number of similar postings, I'm guessing that some
>> professor at the Amrita School of Engineering has set "Find and fix a
>> Solaris bug" as a piece of coursework for an undergraduate course.
> Actually it's Sun's fault - marketing decided to run a contest giving
> away iPods, laptops, and desktop computers to students in India who
> submit bug fixes to OpenSolaris or one of Sun's other open source projects:
> Though since there's also a bonus prize to the school with the most
> student submissions, some professor may have done that as well to
> win his school that prize.
Nothing wrong with that. The only qualm I have is people thinking that
just sending a line of codechange is all that's necessary. But then:
- have we _proven_ that it builds, debug/non-debug/lint ?
- have we _proven_ that it installs and runs, both debug and
non-debug builds ?
- has it passed the standard testsuites for the subsystem ?
- has it been unit tested against the bug testcase, if any ?
- has the bug testcase been integrated into the testsuite ?
- who else has looked over the fix to check whether it has
side effects, is complete, is reasonable, ... ?
- where are the records of all this ?
Quality software engineering is a lot more work than just sending a line
of codechange in. It's just too easy, even for a seniour, very experienced
engineer, to make a typo that prevents the change from building, no matter
how obvious. Re-spinning a solaris build just for such things, that's a
huge waste of time and, quite frankly, p*sses quite a few people off, and
I'm the first person to complain vividly about all those overboarding
review-reviewagain-checkagain-buildagain-followtheprocess rules if
they're handled extremely inflexibly.
But a minimum of due diligence, like build it yourself, run some tests
with it (and the test community has done a really good work to make the
automated tests available via opensolaris.org), that's only for good.
"We" as in "we the sponsors" hide a lot of the stuff above from beginners
who want to contribute. The disadvantage is that sometimes it can take a
few weeks for us what took two days for you. And I don't ask whether
you've build it just to annoy you and cause you delays. I do because
before integration, some minimum of the above will have to be done anyway.
If the sponsor does this for you, they do it mostly in their spare time.
Please have mercy, and show patience - or the other way round :)
Much of the work with getting a fix into a big programming project is
"bureaucracy". You might need to talk to ARC. You might need to talk to
other engineers, testers, doc writers. You've got to run a variety of
builds, tests, maybe benchmarks. You've got to get it reviewed, and maybe
changed if problems are found with the fix. That's all part of software
Don't let yourself be scared by that, please. Try to fight your way
through, it'll make you a better engineer in the end ;-)