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:
>       http://in.sun.com/communities/univ/codeforfreedom/
> 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 
rightly so.

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 ;-)


Reply via email to