avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] savannah audit


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] savannah audit
Date: Fri, 26 Dec 2003 10:14:43 -0800 (PST)


On Fri, 26 Dec 2003, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > There would probably need to be some ground rules for posting the patches.
> > I'd personally like to see the following:
> >
> >   * Subject should obviously state the basics of what the patch does.
> >   * The ChangeLog entry should be in the body of the message.
> >   * The diff should be either a plain text or gzipped file posted as an
> >     attachment to the message. If this is done, then archiver on savannah
> >     will make the attachment downloadable as a link. This is really nice
> >     since it allows for downloading of the patch without loosing the
> >     original formating. Posting diffs in the body of the message is prone to
> >     the formatting whims of the individual's email client.
> >   * Attach a pgp signature or an md5sum for the patch. This should enable us
> >     to be certain that the patch has not been modified since being posted.
> >     Having a pgp signature is probably preferrable.
>
> I'd seriously vote for adapting the FreeBSD automatism instead.  It
> just generates an email out of each cvs commit log message, and sends
> it to the list.  Since the email also contains the diff line numbers
> (+15 -10 and such), it offers a quick estimation about whether the
> volume of the actual change matches the description. ;-)

The point of having all diffs posted to a mailing list is to be able to
reconstruct the current cvs from the archived patches without having to
use cvs. It also makes it easier for those who don't want to deal with
cvs to look over the patches.

Then there's the fact that it's a pain to dig through cvs and find all
the files that were committed as a unit. Without the ChangeLog entry,
this is even more work. For example, you didn't post the diffs for the
vsprintf changes you made. When I merged those into the 1.0 branch, it
would have saved me time to just grab the diff and patch the branch.

>
> Since savannah is going to require GnuPG for commits, I don't see any
> need to roll our own for that.

If you have to have the diff to sign it, it's not that hard to also send
it off via email. (Although this might not be necessary, see end of
message)

>
> The FreeBSD automatism additionally collects all these commitlogs in a
> file.  This would obviate the need to maintain a separate ChangeLog (which
> I constantly seem to forget anyway ;-), and which I believe is way too
> terse for a meaningful description).

So put more info into the ChangeLog file. I've never said that it needed
to be terse. Since you have to write a commitlog entry anyways, why not
just write it into the ChangeLog in the first place? I'd much rather
see the same info in the ChangeLog file as the commit log. Also, keep
in mind that a person that downloads the tarball isn't probably going to
want to go out of their way to use cvs to find the changes made. Thus
the requirement for the ChangeLog file.

One thing I've found very useful with having the commit log be the
ChangeLog entry is having the list of files for the commit unit. It
makes it much easier to find the related diffs in the other files. If
I'm digging through a patch and the commit log doesn't have the file
list, it make takes more time to find the other files.

Yeah, it's a pain and takes extra time to write a ChangeLog entry, but
it safes time in the long run.

>
> What bothers me about this mailing list is to have an additional item
> which needs manual attention.

Have you run a mailman list? I admin four lists and spend not more the
30 minutes a week doing maintenance. It's really not that big of a deal
for me to add another list. I'm going to do it for uisp and simulavr
anyways, so it's not significantly more work to run one more list.

>
> As for the requirements, I think the current FreeBSD scripts only need
> Perl and an MTA (maybe a few Perl packages).  They all live under
> $CVSROOT/CVSROOT, so they are supposed to be directly maintainable via
> `cvs commit' (i. e. no manual interaction by the savannah admins is
> needed).

You are assuming that cvs on the server will be able to execute scripts.
A lot of sites don't allow that.

I just saw this:

  http://savannah.nongnu.org/forum/forum.php?forum_id=2483

This sounds like an automation that we can both agree on (post the diffs
to a mailing list with no user interaction other than doing a cvs
commit).

Ted Roth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]