cvs commit: src/share/examples/etc make.conf

[Tom Rhodes]

On Wed, 15 Dec 2004 17:47:33 +0200
Ruslan Ermilov <ru at FreeBSD.org> wrote:

> Hi Tom,
> 
> On Wed, Dec 15, 2004 at 09:58:48AM -0500, Tom Rhodes wrote:
> > So, your saying that in revision 1.238 it was "ok" for you to
> > "break existing style" without documenting it in the commit
> > log:
> > 
> > "For variables that are only checked with defined(), don't provide
> > any fake value."
> > 
> > But not ok for me to "break existing sytle" in revision 1.241
> > which returned the style back to what we had for at least 2-3
> > years?  (Note, my time of 2-3 years may be off, it's just a
> > guess from since I've had my commit bit).
> > 
> My bad that I didn't put it into the commit log.  I even
> remember thinking about splitting the style/change thing
> between two commits, but then given up on the idea and
> just went ahead and committed it in a single revision.
> My excuse for that being: this commit covered a zillion
> of other files (see commitlogs/share.20041201.gz).

Ok, that is a good excuse.  :)

> 
> > > see any controversy between these two revisions (rev. 1.211 and
> > > the upcoming revision when you commit my patch ;), both use the
> > > rule "don't break an existing style".
> > 
> > There is no real "controversy" over revisions.  I just don't
> > particularly fancy being told to do something on one commit
> > and then get told I did almost the same thing wrong in another
> > commit.
> > 
> Sorry about that, but some facts just don't hold forever.  ;)

True, but I am of the opinion that this one should stay around. :)

> 
> > I agree with you that variables for ppp(8) should be placed in
> > their own specific area;
> > 
> Also because that "NO" area is for documenting knobs that affect
> *not* building some parts of the world.  In case of ppp(8), the
> knobs only tell how to *not* build parts of ppp(8).  If there
> were NO_PPP, it would belong to this section indeed.

Is this a prod to commit my old (very old?) NO_PPP build knob? :)

> 
> > however, the style thing I'm a bit
> > leary on.  Also, please take note that if I'm coming off as an
> > asshole, I don't mean to be.  I'm just concerned about how this
> > may play out.
> > 
> OK, how about just committing my patch, now that you have all
> explanations in hands.  Feel free to attribute your confusion
> to me.

I broke style, this is readily apparent; however so did you.
I liked the old style, it looked nicer and was easier to
work with.

There is this burning feeling in my gut that keeps telling me
you are taking a style baton and hitting me with it unjustly.

Who are you, and by the same token who am I, to say what style
this file should have?  You changed the historical, I put it
back.  This is a stalemate argument, you like your style
change and I like the historical.  And other people probably
don't care one way or the other.

I'm half tempted to just submit and apply your patch for a few
reasons:

1: It will kill this worthless discussion;
2: It shows that I am not all "my way or no way";
3: Worthless as a commit it would be, it will increase my commit count;
4: We suck because both are valid points and we need a third vote to
   break it.

-- 
Tom Rhodes