This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gui] Implement RescaleOp


Hi,

On Thu, 2004-09-30 at 11:52, Andrew Haley wrote:
> Mark Wielaard writes:
>  > And most importantly the patches mailinglist is to announce the
>  > intention of what will be changed and the cvs commit mailinglist is
>  > what has actually been checked in.  These are two different things,
>  > you use one to check that what was intended was actually what was
>  > changed.
> 
> Exactly so: this is a strong reason not to use the patches mailing
> list to do merges, but the CVS checkins themselves.

What I meant was that we use this as a backup check that everything went
right and that the thing that was send to the mailinglist was actually
what was going into CVS. So I (and Michael) review the patches, merge
them to/from GNU Classpath/libgcj and then watch the automatic tools to
catch any errors made by us or the original committer.

This also helps when trying to make sure our repositories aren't
compromised (as could have happened during the savannah compromise).

>  > As long as we are not completely merged and gcj doesn't just use GNU
>  > Classpath glibj out of the box we really need people to post the actual
>  > patches so they can be checked and merged with upstream easily.
>  > 
>  > That, or we will have to ask libgcj hackers to explicitly propose and
>  > post patches on classpath-patches if they want them to be integrated.
> 
> The patches mailing list is for people to read.  We try to make sure
> that patches are in a form that can be merged, but its primary purpose
> is for patch discussion.  

Fair. But a little note when what/if you commit without posting the
precise patch would be appreciated.

> As far as I am awre, it has always been customary to accept patches
> with a caveat of "please fix the indentation before check-in" and such
> patches are not re-posted.  You are proposing a change of policy.

Maybe. I always understood a "OK, but with these changes" to mean "OK,
if you post the cleaned up patch, with these changes, you can commit it
without waiting for approval".

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]