Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] What is our policy on patches? 
+1 from my side.

Note that we tried to do that last fall (Tom Tromey 
sent some CVS commit scripts based on what the GNU 
projects do -- I've attached that email), and these were sent to the 
Eclipse infrastructure folks. However, this did not go
further (I believe there are various rules that are due
to the fact IBM hosts the Eclipse servers).

Now, you may have more luck in moving this forward, seeing as
you're an IBM employee and the Eclipse infra folks are here in Ottawa :-)

Sebastien

> 
> Hey all,
> 
> One way to resolve this would be to take a look at CVS log 
> mail support 
> again.  Now that I'm a SourceForge project admin, I've 
> learned how to set 
> this up for a CVS repository.  We could get the commit logs 
> for selected 
> projects to be sent to a mailing list, e.g. cdt-cvs.  We would then 
> reserve the cdt-patch list for non-committers to request 
> patches or to 
> invoke voting on certain patches.
> 
> If we get a consensus, I'll volunteer to try and get this 
> going (assuming 
> the eclipse.org folks let us).
> 
> Thoughts?
> 
> Doug Schaefer, Senior Software Developer
> IBM Rational Software, Ottawa, Ontario, Canada
> 
> 
> 
> John Camelon/Ottawa/IBM@IBMCA 
> Sent by: cdt-dev-admin@xxxxxxxxxxx
> 09/15/2003 08:55 AM
> Please respond to
> cdt-dev@xxxxxxxxxxx
> 
> 
> To
> cdt-dev@xxxxxxxxxxx
> cc
> 
> Subject
> Re: [cdt-dev] What is our policy on patches?
> 
> 
> 
> 
> 
> 
> > Many now, consider the mailing list patch as "spam".
> +1
>  
> I guess my main point is that if we were voting on patches or 
> debating 
> the content of these patches prior to them being committed, then the 
> content on the list is useful.  If we are not doing that, then it 
> merely serves as a reminder to do a CVS update. 
> 
> JohnC
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
--- Begin Message --- 
>>>>> "Sebastien" == Sebastien Marineau <sebastien@xxxxxxx> writes:

Sebastien> Tom, can you first email the scripts so we can figure out
Sebastien> how to hook it into the cvs server? I don't want to create
Sebastien> the mailing list until we're sure we can hook into the
Sebastien> current eclipse infrastructure.

No problem.

I've attached two files, commit_prep and log_accum.  Both are perl
scripts.

In CVSROOT you would run commit_prep from commitinfo, for instance:

DEFAULT		/usr/sourceware/bin/commit_prep -T cdt -r

Then from loginfo you would run log_accum:

DEFAULT (/usr/sourceware/bin/log_accum -D eclipse.org -T cdt -m
cdt-patch@xxxxxxxxxxx -s %{sVv})


The above examples put the scripts in /usr/sourceware/bin; this comes
from sources.redhat.com.  However, another common approach would be to
put these files directly into CVSROOT and add them to the
`checkoutlist' file (and adjust the invocation path accordingly).
That makes it easy to fix problems in the scripts; we run a
configuration like this on an internal CVS server here.

You could also tweak the log_accum invocation to generate cvsweb URLs
in the commit message.  You just need the appropriate -C and -U
options.

For sources, we also use the script's feature of appending a commit
message to a Gnats PR.  If the commit message matches certain text, we
interpret that as the PR number, and automatically forward the commit
message there.  This makes a nice linkage between bug reports and cvs
commits (including a pointer in the bug report directly to the
patches, via cvsweb).  Probably this could be modified to work with
bugzilla, but I don't know how.

There are other commit message generation scripts out there.  The
appended ones are hacked versions of scripts that come with cvs.

If you want I could send you a CVSROOT patch to implement everything.
Of course, you'd have to do the testing.

Tom

Attachment: log_accum
Description: Binary data

Attachment: commit_prep
Description: Binary data


--- End Message ---

Back to the top