Re: [Hamlib-developer] rig.h

[Stephane F. <f4...@fr...>]

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