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
_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers