Thread: [Hamlib-developer] rig.h
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Dale E. E. <de...@w-...> - 2002-06-30 11:59:08
|
Stephane,
I added my rig.h to the CVS. I tried removing the stuff that depended
upon
having changes in rig.h but ended up with a rig that just gave
-RIG_EINVAL
for just about everything. Also, you said two things that stuck in my
mind:
1) make sure I'm confident of the changes
2) CVS will allow us to back out the changes if required.
The stuff I was doing to as work-arounds lowered my confidence in what
the changes would do. I have visited all of the backends and I'm almost
certain there will be little if any effects from my changes.
The kylix (and any file that duplicates rig.h) should be considered
broken.
I've only glanced at the kylix stuff. Some of it may actually be
unaffected
but I need to go line-by-line and make sure it gets updated (and stuff
like
tcl, etc...).
Everything compiles after checking it back out (had to run automake on
the kenwood directory and check the new Makefile.*'s in).
The only test I could think to perform was rpcrig. I tried that for
the first time
and it worked perfectly! I only used 'v', 'F', and'f' but for a quick
check it
was quite a thrill. My two computers are connected via ethernet and the
rig on the serial port worked well.
Let me know if something actually breaks that I didn't expect. I'll be
working
fast a furious to get the stuff I know about matching rig.h.
I'd appreciate it if you give me a chance to fix any problems that may
arise
and not just back out the new revisions. The download stats reported by
SourceForge are fairly low, you just a new release, and judging by
the CVS dates there is not a lot of activity at the moment.
There's not much more I can do to boost my confidence that things will
work except commit to CVS and start working on kylix as soon as I get
a little sleep.
Thank you in advance. Now that I have things working (from my point
of view) I can do more towards rewriting and bringing things in-line
with
the "standard" code.
73's
Dale
kd7eni
|
|
From: Stephane F. <f4...@fr...> - 2002-06-30 21:23:39
|
Dale, Please, please, please, calm down, you hear me Dale? calm down. We're going to need to enforce some rules that were implicit. * First one: NEVER commit the rig.h file before discussing the patch first on the mailing list. And sending a mail without waiting for a reply, and commiting the next day is not what I call discussing. You have to realize that rig.h IS the API definition. Care should be taken to prevent binary compatibility breakage. * you're free to commit ts2k, or a rig file, especially if you're the only one to use it. As soon as the file is shared, you must talk first with people in the team using it. * right now, every one in the list has cvs commit access. It works as long as everyone behaves. Some other projects have only one commiter, and the developers have to send patches first on mailing list, having them reviewed by peers, before the commiter validate. This tend to improve quality, since this obliges the contributor to think twice before submitting. * when sending contribution, please use unified patches (diff -u old.c new.c). It's a way lot easier to read than the whole file. * don't commit broken stuff. If you know it's broken, work on it. We're not on a hurry, fix it, and come back when it's okay. * If you can't help commiting, create your own branch. We'll merge when it's satifactory. Flooding me won't help the situation, as It will delay further reviews. And spending a sunday afternoon reading kilometers (if not miles) of mails does not enjoy me that much. Sorry to be a bit crude, but you're not alone. On Sun, Jun 30, 2002, Dale E. Edmons wrote: > I added my rig.h to the CVS. I tried removing the stuff that depended > upon > having changes in rig.h but ended up with a rig that just gave > -RIG_EINVAL > for just about everything. Also, you said two things that stuck in my So, if it's giving -RIG_EINVAL for about everything, don't commit!! I told you we have to discuss first. god damn it. Do I have to remove your commit priviledges? > mind: > 1) make sure I'm confident of the changes > 2) CVS will allow us to back out the changes if required. well, I wanted to be nice with you. I thought you understood that you should not commit like a cowboy in a movie. > The stuff I was doing to as work-arounds lowered my confidence in what > the changes would do. I have visited all of the backends and I'm almost > certain there will be little if any effects from my changes. You may be assuming too much. You should not modifying rig.h so easily. I haven't reviewed your patches already because of all this blahblah, and I should calm down myself because I want to stay polite with you, and I do respect your work. > Let me know if something actually breaks that I didn't expect. I'll be > working > fast a furious to get the stuff I know about matching rig.h. Can't your both computers even break ? or should I call your wife and ask her to confiscate them? Do you ever happen to spend some time on the air, or at least just listing the bands? > I'd appreciate it if you give me a chance to fix any problems that may > arise > and not just back out the new revisions. The download stats reported by Well, I won't back out the new revisions completely, but I'll have to cleanup a lot. geeeez, I hate to do that kind of work. And yes, *I* will do the cleanup myself, but asking you first before removing anything. > SourceForge are fairly low, you just a new release, and judging by > the CVS dates there is not a lot of activity at the moment. You're impossible. I don't care about statistics, I don't care about activity. Do you understand that? All I care is end users, and people developing other software using Hamlib. > There's not much more I can do to boost my confidence that things will > work except commit to CVS and start working on kylix as soon as I get > a little sleep. > > Thank you in advance. Now that I have things working (from my point > of view) I can do more towards rewriting and bringing things in-line > with > the "standard" code. > Dale, I value you work, really. But please, don't piss me off too much. Play it nice, play with the team. Stephane |