[chirp_devel] #553 Icom ID-51 support

[Tom Hayward]

On Tue, Feb 19, 2013 at 8:27 AM, Dean Gibson AE7Q <data at ae7q.net> wrote:
> On 2013-02-19 06:38, Dan Smith wrote:
>
> Okay, here is my ID-51 (id51.py) new driver.  Also included is an
> image file for same.
>
> Could you put it into the proper patch format?
>
> http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Submitting-a-patch
>
>
> OK, I'm confoozed.  I previously read that page, and I know that's the
> correct format for a change.  Once you/me have decided that the changes I
> have for the ID-31 are appropriate as well, those will obviously be in patch
> format.  However, for a new driver, the whole file is new, so I don't
> understand the procedure for that.  For the image file, your page says:

A new file is a change to Chirp. After adding the new file, Chirp is
not the same as it was before. But that's not the point here...

> So, that's what I did.  "hg status -mar" only shows the id31.py changes,
> which I'm not ready (per above) to submit yet.  I included the complete
> id51.py file in my previous eMail so you could see the differences (via the
> two diffs) before I formally submitted a patch.

"hg status -mar" does nothing to attribute the changes to you, or
label them with an appropriate commit message. Our goal here isn't
just to add new lines of code, but to document who added them and why,
so that future readers of the code can ask "what was the guy who wrote
this thinking??" and have both the explanation (commit message) and
name/email of the guy who wrote it. If we find that your change
introduces a regression, we are also easily able to search for commit
messages containing "id?1" and revert each as needed until the
regression disappears.

> hg diff:

For this all to work, you must use a different command, "hg qnew ..."
to create your patch. You will be prompted to enter a commit message,
and when you export it ("hg export tip") your name and email address
will be automatically be added to the header. The commands to
accomplish this are all listed here:

http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-committing-a-Change

When using "hg q.." commands, your changes are not permanent. You can
send a work-in-progress patch (see Sending a Change), ask some
questions, modify your code, then use "hg qref" to update the patch.

A little bit of record keeping is necessary for managing a large
codebase, and I think you'll find the learning curve for hg mq is
minimal and saves you effort in the long run.

Tom KD7LXL