GCJ/minGW produced executables and linux/wine

Mark Wielaard mark@klomp.org
Tue Mar 4 21:33:00 GMT 2003


On Tue, 2003-03-04 at 19:02, Ranjit Mathew wrote:
> > Ah, you're still waiting on those.  Sorry.  One problem is that I
> > can't test them.  Is it true that although you have done the FSF
> > paperwork, you don't have write access?
> Yes, I have done the paperwork but I refused the write access when
> Tom offered this to me because I believe (as do others, including
> Linus) that write access to the CVS should only be with a small
> group of solid, trustworthy individuals. That way you can ensure
> the quality and security of the code being checked in. BTW, Tom
> did offer only write-on-approval access, but I believe the rigour
> is more when the maintainers approve and commit themselves.
>     http://gcc.gnu.org/ml/gcc/2002-12/msg00800.html
> Maybe I'm misguided here, but still, this is what I think.
> The flip side is that my patches get approved/rejected only when
> you/Tom get around to examining, approving, testing and committing
> them. But that's OK by me - I just hope that minor pings from
> my side don't turn to harrassments for you guys, that's all.

Just my oppinion as an ordinary write-after-approval guy.
IMHO I think you are misguided here. I think it would be much easier for
everyone if you could checkin your changes yourself. And there are
enough checks in the system to keep a good stable tree.

We ensure the quality and security of the code being checked in by the
following process.

1) You have to understand your patch yourself.
2) It is always a good idea to write a testcase if possible (we don't
require it, but it is highly appreciated if you do).
3) You have to do a clean build with only your patch in it (state on
what platform you did this when posting the patch).
4) You have to run the testsuite (and preferably the extended
Mauve+Jacks suits also). Also state that you have done this when posting
a patch.
5) Then someone else that can approve patches for the tree has to
understand and agree with it.
6) It is checked in (and if some time passed between 4 and 5 you have to
redo steps 3 and 4).
7) There are a couple of autobuilders and testers (and hunderds of
hackers) picking up any faults that still slip through.

If all this happens you can certainly control the quality and security
of the code. It does require that you trust people to do steps 1-4 and 6
honestly and correctly. And you have to trust the people that can
approve patches to review them critically and demand rewrites if
neccessary. But it prevents the maintainer from having to do steps 2, 3,
4 and 6 for every patch. (These steps take alot of extra time.)

There are very few people that may skip step 5 (and IMHO it would be
good if every patch was always approved by at least someone else). And
we have very capable people that do that approval step. Although I am
afraid that Tom gets a bit overloaded now that Bryce is out of the loop
for such a long time.

I think the point that Andrew makes is that if someone checks something
in he is responsible for doing all the actual steps. So if you don't
commit yourself then someone else has to (re)do the steps for you. I
did, the one time that I checked in a patch on your behalve. Just to
make sure that the patch as posted actually is the patch that was

Having CVS write(-after-approval) access is a big responsibility which
you don't have to accept. But I think you belong to the small group of
solid, trustworthy individuals that should have it. And most of all, I
trust Andrew and Tom to only approve your writes if your patches are
flawless :)



More information about the Java mailing list