[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [stp-dev] STP Committer/Developer commit process page
- From: Michael Norman <Michael.Norman@xxxxxxxxxxxxx>
- Date: Wed, 01 Feb 2006 13:02:23 +0000
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
I would very much recommend against specifying any additional
expectations over and above the core Eclipse development process.
The culture we need to foster from day one is that committers as
individuals have responsibility for the quality of their code. How they
achieve that quality is up to them.
We could equally-well mandate DSDM - that is our internal process at
Scapa. How would that go down? Who has even heard of it?
David Bosschaert wrote:
Thanks Alex for the feedback. Ahead of today's IRC, few comments inline.
Alex Boisvert wrote:
Good job on the draft; it already reads better than most of my 5th
Here's a few comments to stir discussion for tomorrow...
1) I'd like to see something said about code comments (javadoc). In my
book, public APIs should be properly documented. Every class should
have at least Javadoc on the class declaration. And I'd like to see
package.html for every package so new developers can navigate the
codebase and have a few signposts along the way.
Good point. I will put this in the next version.
2) The wording "Before code is committed in to CVS," is a little
confusing since the code needs to be committed before it is taken into
account for automated build, automated tests, etc.
Well..., you could run the automated build on your own checkout before
you commit. Your checkout should contain all the source, tests and
scripts needed to do this.
In practise, this generally means that running 'ant test' on your
whole checkout passes fine before you commit.
3) The review process is good but I would like to create a provision for
developers creating their own branch of code in CVS, such that code may
be shared, inspected, debugged, tested, etc, in a collaborative
fashion. Some developers will have local reviewers (and that's good)
but others might find it difficult to get large pieces of code reviewed
by remote parties. Allowing the use of CVS in temporary unofficial
branches would help those 'lonely' developers. Also, this way
collaboration can also happen at a larger scale prior to the official
merge into the stable codebase.
Let's discuss this today at the IRC, I'd be interested how many people
have experience with using temporary development branches with CVS.
stp-dev mailing list