Date: Wed, 15 Dec 2004 12:14:53 -0500 From: Tom Rhodes <trhodes@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/examples/etc make.conf Message-ID: <20041215121453.78849773@localhost> In-Reply-To: <20041215154733.GB85290@ip.net.ua> References: <200412150210.iBF2AodY094280@repoman.freebsd.org> <20041215084901.GC25967@ip.net.ua> <20041215083548.5455ea2c@localhost> <20041215135230.GA2319@ip.net.ua> <20041215090139.53a90960@localhost> <20041215142114.GA24846@ip.net.ua> <20041215095848.658d4cc6@localhost> <20041215154733.GB85290@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Dec 2004 17:47:33 +0200 Ruslan Ermilov <ru@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041215121453.78849773>