[Savannah-hackers-public] Re: log_accum at Savannah

[Derek R. Price]

Sylvain Beucler wrote:
> On Mon, May 15, 2006 at 10:59:20AM -0400, Derek R. Price wrote:
>   
>> Hey Sylvain,
>>
>> Okay, it took a little longer than I thought it would, but I've
>> committed something that should be close to usable on Savannah.  It
>> should support nested config files, file and directory names with
>> spaces, and all the features the log_accum.pl on Savannah had, except
>> for the gnats-interface option (which looked like it wasn't set up for
>> Savannah anyhow) and the old `cvs status' output, which I wasn't sure
>> you were using.
>>     
>
> That's a start :) Diffs should be sent to a different e-mail, and
> apparently multiple diffs are not cumulated in the separate mail. I'll
> investigate tomorrow unless you beat me into doing it.
>   

Actually, I thought they were supposed to be split.  I had them all in
one place and split them on purpose.  I don't use that functionality and
it wasn't in the CVS version of the script before, though, so go ahead
and make it look like whatever you like.

> I don't remember of using GNATS at Savannah, that's not an immediate
> issue.
>
> All the loginfo I configured use the '-s' option to suppress the 'cvs
> status' output, so that's no problem either.
>   

I thought that might be the case.

> However, the hook cannot be 3-lines long, because there's a boring
> issue: identifying users. We do not want anybody to be able to close a
> bug in another project, or a non-privileged project member to edit the
> tracker.
>   

log_accum.pl only runs at commit time.  You don't think it would be a
reasonable assumption that anyone with commit access to the repository
should have access to the tracker?  Also, I wouldn't want the
log_accum.pl script to try and close any issues.  I only imagined that
it would annotate issues with information on related commits.  Since it
seems to me that some issues might require multiple commits, it seems to
me that closing the issues automatically on any commit would be bad, but
I have thought that having that log message and list of URLs to diffs
right in an issue would be handy in the past, and would almost certainly
not be bad.

> I'd be interested in any thought about properly identifying users on
> the remote side. Imagine that in most cases the tracker and the CVS
> services are located on different machines, and users can add custom
> hooks (aka "shell access").
>
> I have something in mind where the tracker service trusts the CVS
> _machine_; then loginfo calls a setuid program that identify the user
> using its system uid, and calls the tracker using credentials stored
> in a private file.
>   

This is about what I had in mind.  The users running log_accum.pl will
have already authenticated to the CVS machine, so assuming that this
authentication can be relayed to the tracker service securely, then this
should be okay.

> Meanwhile, using logging and mail notifications could ensure enough
> after-the-fact security to start a quick hack, that we would hopefully
> improve later on.
>   

Yay!  :)

Do you know enough to write the SQL command (e.g. insert into
bug-tracker values ($body) where id = $artifact_id)?  I can put it in
the right place and fill in the variable contents in a few seconds.

> Yes, this merge should fix a couple bugs (including the one about
> irrelevant diffs during branch creation -
> https://savannah.gnu.org/support/?func=detailitem&item_id=104373) :)
>   

Ooh, cool.  That bug had been getting to me.  I kept leap-frogging the
GPG code to new branches to test it with the CVS trunk until I thought
it was stable enough to merge.  That was generating VERY BIG diffs.  I
guess I never got around to filing my own report (unless someone already
spotted the duplicate and closed it - that rings a bell  :).

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 248.835.1260
f: +1 248.835.1263
<mailto:address@hidden>