gotcha.

1. do you work on openstack development at all?
2. have you looked at moving chirp to github?
I was thinking they have some nice features like code review, and maybe some intrinsics like system multi-site/backup redundancy.
Was curious as to what kind of redundancy you have for chirp hg repo?



From: Dan Smith <dsmith@danplanet.com>
To: chirp_devel@intrepid.danplanet.com
Sent: Wednesday, January 8, 2014 7:23 PM
Subject: Re: [chirp_devel] [PATCH] [bj-uv55] fix fm setting #1335

> Lols Dan. Do you want <80 chars or multiple lines ;)

Multiple lines! Who ever said they had to be a single line? :)

I'll pick on Tom here a bit, who I think started the current trend of
single-line micro logs :)

> I'll start working on the latter.
>
> What about: "fix wrong fm preset offset and size in radio image" ?

I meant to say, I applied this one already, but I'd like to have the
7800 one with the details.

I was looking at our commit history the other day trying to find
something and came to the realization that we've been pretty bad lately
with being descriptive in the log. I'd just like us to be a little
better about that.

Generally, the first line of a commit message should stand alone,
followed by a blank line, then as much text as makes sense to describe
the issue/change/fix. I've been really lax about this recently, and we
don't have to be insane about it, but lately we've had a lot of "fix bug
#123" commit messages.

Project-specific details aside, the following two pages have some good
guidelines and examples, which I think are pretty common for open-source
projects:

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

https://wiki.openstack.org/wiki/GitCommitMessages


--Dan