Re: [cdt-dev] Time for Voting?

["Douglas Schaefer" <dschaefe@xxxxxxxxxx>]

+1  :-)

I agree, we need to scrutinize patches more thoroughly.  But to do that, 
we need some time between when the patch is submitted and when the patch 
is applied to do that review, or pray that the reverse patch mechanism 
works.  I wouldn't mind a 24 hour delay.  Thoughts?

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



"Thomas Fletcher" <thomasf@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
07/08/2003 09:01 AM
Please respond to
cdt-dev@xxxxxxxxxxx


To
<cdt-dev@xxxxxxxxxxx>
cc

Subject
Re: [cdt-dev] Time for Voting?






----- Original Message -----
From: "John Camelon" <jcamelon@xxxxxxxxxx>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Monday, July 07, 2003 6:13 PM
Subject: Re: [cdt-dev] Time for Voting?


>
> I think this is a terrible idea for patches, but a good idea for
> features.
>
> The patch process can be slow enough for some people involved without
> having to paralyze a particular component with either a rubber stamp
> approval or nickel & diming implementation.
> Instead of increased process on the patch list, I would suggest better
> standards for documenting and explaining the features.  Perhaps patches
> cannot be applied before a spec is reviewed and approved.
>
> Personally, I have a huge amount of work (all implementation) that I
> need to get done over the next couple of months, and I cannot fathom
> changing how we work this late into 1.2 without breaking our schedule
> completely.

Personally, I just think that when patches are submitted there needs to be
a fairly comprehensive explanation of what it is that is changing.  For
example
when I submitted the patches to properly update and enhance the code
completion aspect in the editor I wrote a description of all of the pieces
which
had changed and why it was that they had changed.  Now I didn't receive
any feedback (though the patch was committed ... thank-you) which was odd
given the fact that Hoda and others are apparently working in this area.

On the whole, I think that I agree with John that we should be voting
features
and scrutinizing patches and rejecting them if we don't really understand
what
they are doing, in which case the submitter will have to do a better job 
of
explaining the "ramifications" of the work being done.

My thoughts,
  Thomas

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev