Alan Hargreaves - Product Technical Support (APAC) wrote:
Earlier today someone posted a note in response to a blog item from Jim
about how overly bureaucartic our current bug fixing process is.
I responded in my blog at
http://blogs.sun.com/roller/page/tpenta?entry=comment_on_opensolaris_bugfix_process
The original poster has responded, and in turn I've asked about exactly
what in the process he finds overly burdonsome.
If we can get a reasonable dialogue going here, it could get interesting
and useful.
Maybe we *do* need a simpler process for those who want to suggest fixes
but not get involved in the actual putback process.
This could be especially useful given how overburdoned the current
sponsor team is with this and their other responsibilities.
Hi Alan,
I'd like to add my 2 PPs (Pacific Pesos) to this discussion.
I see a number of sentences in sdestika's comment which I find
illustrative of several differences between various open-source-using
/developing communities.
Firstly:
"Quality.... [is the] end result of passion and enthusiasm"
I don't agree with that at all. If you just have passion and
enthusiasm, but no committment to writing code so that it is
demonstrably correct, then in my book you have nothing of
value to show for your efforts.
Secondly:
Quote: None of the "methodical" processes you mentioned are _necessary_
for quality. Do you think other OSS projects who maintain quality have
these kind of silly bureaucratic processes? EndQuote
The processes which Sun has evolved over the years might well not all
be totally necessary to ensure quality. One only has to look at the
number of bugs we've had in all our products over the years to see that.
However, I argue strongly that by having a methodology for supporting
the bugfixing and rfe-integrating process, we have made it possible for
our company to develop products where the number of people with source
code commit privileges is massive. I don't believe that there are nearly
as many people with commit privileges working on the Linux kernel, not
even when you count IBM and HP and....
For a company such as Sun (or IBM or HP or....) where the code-
committers can be and in fact are all over the planet, it is these
methodical processes which help us keep plans and code on track.
Those processes also help us to audit the code, and make it relatively
efficient and easy to get rid of breakage.
Calling those processes "silly [and] beauracratic" indicates to me that
the OP is not comfortable with observing a different way of doing things
or finding out _why_ those processes have evolved.
Thirdly:
"Now look at how LKML solved it - within a month of bitkeeper mishap 3
different SCMs were coded and people started using what they liked -
Git/Mercurial etc. And it all works well together."
For anybody who is participating in a large project such as an os
kernel, it is utterly essential that everybody uses the same set of
SCM tools. That way you can minimise the possibilities of lots of
little forks and merge problems. If everybody reads from the same
songbook, you can all move forward knowing where you've come from.
It's fantastic that those three different SCMs all work well together.
But that wasn't a guaranteed result, and by the way, which one should
I choose? Why should I choose that over any other? If I don't have
to worry about the choice of tool then I can get on with development.
I'm not a teamware bigot - I use RCS and CVS myself for a variety
of personal and smaller team-based efforts. And in the past I've
not been averse to just committing whatever I wanted to (in my
personal projects that is). But it's my experience of coding as
part of a team which has made me recognise the value in having
processes like those for ON.
The bigger the project (LOC and number of developers), the more
essential it is to have basic bedrock processes and tools which
every participant adhers to. That way you can keep to your targets
and milestones -- something which companies tend to find useful.
Oh, and government or university funding bodies.
Best regards,
James C. McPherson
--
Pacrim PTS Engineer 828 Pacific Highway
Gordon NSW
Sun Microsystems Australia 2072
_______________________________________________
opensolaris-discuss mailing list
[email protected]
