Making It Easier To Start Working On Bugzilla

[Gregary Hendricks]

When starting out, I agree that taking on blockers is a bad idea. For
one, 
putting critical code development into the hands of newcomers is not
the best 
idea generally, both for the sake of the code and for the sake of the 
developer. Since it is a tall order to fill it has the potential to
create 
major problems if something goes wrong. This would be a massive blow to
the 
self esteem of a new developer. 

Here are a few notes on my experiences so far.
<rant>

I have been working on a number of patches simultaneously for the past
year 
now, most of which are pretty minor with the exception of one very
large one. 
In the case of some of my patches I have had a reviewer/mentor such as
myk to 
hold my hand through the process. In these cases the reviewers have not
only 
been supportive, but have actually pushed some of the proposed changes

through some barriers and opposition. 

One of the challenges that has been particularly accute is that, though
we use 
Bugzilla day to day, we use it in very different ways from those of
Mozilla. 
Having to learn the bugzilla way of using bugzilla is something of an
issue. 
It is easy to sound as though you are chastising in a review for not
doing 
things the "right" way when in actuality it is just a different way of

approaching things.  One of the things I love most about Perl is its
mantra 
"There's more than one way to do it". I have had multiple reviews get
r- 
because it does not meet the coding style of the particular reviewer
when in 
reality there is no good argument for changing it. If it is more
efficient or 
reduces clock cycles, that is one thing, but otherwise if it works, why
make 
a developer change something over and over again to satisfy nits? 

Just yesterday I spent litterally half my day helping rework a patch
that 
worked but wasn't "cool enough" to get accepted because it didn't use a

particular implimentation of an algorithm.

Another thing that I have seen is reviewers that either do not read the

comments of other reviews or forget their own comments. On at least two

occasions I have had one reviewer tell me to do something one way and
then 
get an r- on the next review (once a different reviewer and once the
same 
reviewer) because I did it that way. This seems backwards. 

</rant>

I appreciate the reviewers that have taken the time to actually provide

proposals to solutions. It is true that sometimes the obvious solution
is not 
so obvious and on multiple occasions I have been corrected in such a
way as 
to help me learn more about the language and the thinking behind an 
implementation. I also appreciate reviewers like LpSolit who is willing
to 
dive into an area that he may not be familiar with in order to give a 
thorough review, taking the time to learn what is going on in the
process. 

Part of the beauty of open source in my mind is that we all have the 
opportunity to share our understanding and we can all help each other
learn 
new things.

-- 
Greg Hendricks 
Novell IS&T Engineer 
GHendricks at novell.com 
www.novell.com