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

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

Re: [avr-libc-dev] Fixed various minor bugs


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] Fixed various minor bugs
Date: Sun, 15 Feb 2004 14:57:25 -0800 (PST)


On Sun, 15 Feb 2004, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > Please post all patches committed to the 1.0 branch to the list.
>
> Does really anyone read that?

I do. Also, it gives anyone on the list a chance to review any changes
made to the stable branch. All changes on the stable branch should be
reviewed by at least the other developers. If now one takes the time to
review the patches, they can't complain if it broke something when we
make the release and they'll just have to wait for the next release.

>
> Alas, subversion.gnu.org's CVS server command doesn't handle date
> specifications together with branch specifications (-jbranch:date) in
> cvs diff or cvs update operations.  This makes it really cumbersome to
> reconstruct a diff like this one. :-(  Remote rsync is no longer
> supported either, so I can't do this locally anymore.  Performing a
> bunch of cvs log/cvs diff operations remotely over ssh is quite
> annoying.

If you do a 'cvs diff -u > foo.diff' just before doing the commit, you
don't have to jump through hoops to pull out the diffs. It also gives
you a chance to review the patch yourself before the commit. I've caught
many stupid mistakes (like docu typos, etc) by doing this. Once you've
done this, it only takes a few seconds to post it to the list after
you've made the commit.

>From there, it's also a trivial step to wrap the cvs diff command to
automate generating a patch with a ChangeLog entry stub ready to be
filled in. I've posted my wrapper script a few times already.

Posting the patch also gives those who don't want to deal with cvs a
chance to review the patch without having to dig through cvs to figure
out what was changed.

>
> They once mentioned to me that supporting cvsup (CVS mirroring) might
> be an option, but I haven't heard of it again, and can't seem to find
> that email either.
>
> Btw., the 1.0.2 tag is inconstently named:
>
> symbolic names:
>         avr-lib-1_0_2-release: 1.293.2.32
>         avr-libc-1_0_1-release: 1.293.2.20
>         avr-libc-1_0: 1.293.2.13
>         avr-libc-1_0-branch: 1.293.0.2
>         avr-libc-1_0-branchpoint: 1.293
>
> Do we want to correct this?  (Should not be too difficult.)

Oops. I screwed that one up. It should be fixed, but I don't know a
trivial way to fix it. Do you know an easy way to do it?

>
> > > Maybe time to roll a new 1.0.x release?
>
> > Not yet. Let's shoot for end of the month. There's some boot API doc
> > fixes that I need to do ...
>
> Ah yes, I forgot about that one.

OK.

Ted Roth




reply via email to

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