On Mon, 2009-05-25 at 15:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:50 PM, Zach Welch wrote:
>
> > On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> >> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
> >>
> >>>>> Further, you can argue with the following assertions -- only if
> >>>>> you
> >>>>> can
> >>>>> show me a patch that proves them wrong:
> >>>>>
> >>>
> >>> Show me your patch, or let me commit mine. This debate is silly.
> >>>
> >>> Cheers,
> >>>
> >>> Zach
> >>
> >>
> >> It's interesting that every time a discussion about preferences comes
> >> up, it typically ends with "Here's my patch. This is silly. My
> >> patch
> >> already works, let's just commit it." It's not like discussion is
> >> painful or this issue is causing problems for anyone. We're better
> >> off coming up with an answer that everyone is OK with rather than
> >> just
> >> defaulting to whatever patch shows up first.
> >
> > Actually, these kinds of issues are very frustrating to me personally,
> > because they always end up being counterproductive. This is why I am
> > maintaining the Style Guide. I desperately want to hereafter resolve
> > this debate by shouting "RTFM and STFU"; anything else is time wasted.
> > The burden of proof lies on the person that lacks a patch in-hand.
> >
> > Until these matters are fully resolved, the discussion does cause a
> > problem because it prevents us from moving forward with genuinely
> > productive work on the system.
> >
>
> It isn't counterproductive the first time the discussion happens.
> It's counterproductive when someone wants to go against the
> established convention. The burden is always on the person who is
> arguing for something different that the convention. In this case,
> it's both of us.
True. However, I have been thinking about the bigger context: 0.2.0.
> >> The opposing patch is attached. As I already mentioned, it is large,
> >> but the changes were done entirely with the following commands:
> >>
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
> >>
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
> >> g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
> >> g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
> >> g' {} \;
> >>
> >> The first set just do a bulk rename of the types, but it also changes
> >> function names. Since it looks odd to include the _t in a function
> >> name, the second set changes the pattern used for function names to
> >> not include the _t.
> >
> > I hate it. You seriously want to make all of the functions that
> > referred to u16 or u32 to now refer to uint16 and uint32??? This was
> > _exactly_ what I meant when I said a patch would be hard to create.
> >
>
> It wasn't hard to create at all. Eight find and replaces is all it
> took. Less than 10 minutes.
It was incomplete and would probably raise objections from others.
> > Also, you do realize that the scope of these changes is _much_ more
> > likely to be disruptive to anyone with out-of-tree changes in
> > progress?
> >
>
> Yup. It is. Sadly until we decide on all these various conventions,
> things are always going to be disruptive to those with out-of-tree
> changes. At least in this case, syncing with ToT is relatively
> simple. Using minimal change as an argument for is dangerous.
> Consider the local minimum effect. To get to a better solution, you
> might need to stir things up a bit in the short term. The question we
> need to be asking is "Do we do a big change now, or do we live with a
> non-standard type system?"
We are talking about 0.2.0. Would you like to perform the risk/reward
analysis of my patch versus yours, focusing on the impact they will each
have on fixes being developed for the release?
A local minimum would be better than no change and much better than your
proposed big change. It would better to have and stick to a convention
that we can change later, minimizing the cost to everyone today.
I cleaned up the code to the current convention because it is the right
thing to do _today_. Period. Tomorrow is a different story, and you
should definitely be aware that I am open to a patch like yours someday.
Just not for 0.2.0, okay?
> > Are you insane or merely sadistic? :)
> >
>
> Neither and the smiley doesn't really help your case either. You're
> taking this _way_ too personal for something that is a relatively
> mundane discussion.
The smiley meant to frame the rhetorical question as humorous. Clearly,
this was not the time or place for that, so I must wonder if I am not
alone in fitting your further assertion.
> The two sides have chimed in, patches have been
> provided, and a fair number of developers have commented. It's up to
> the majority to decide which way to go.
Okay, I waited to pull the consensus card, but the majority of others
have already expressed their opinion that the shorthand status quo would
be acceptable (if not preferred). I think even Duane is okay with it.
While you thus represent the minority, I have entertained this argument
because your earlier point was essentially correct: both of our proposed
standards are perfectly valid conventions in their own right.
If anything, my frustration derives from the fact that -- as a
maintainer yourself -- you should have been looking at the consensus
that was already being expressed by the community and let it drop sooner
than this (nevermind 0.2.0 considerations). As a project leader, I see
these kinds of debates as detrimental to being effective in a community,
as it appears the individuals are unable resolve their points in an
efficient and effective manner.
This is why I have come to prefer "benevolent dictators" in open source.
Right and wrong are too frequently subjective subjects, and it would
just be better for someone must step in end the argument with a
decision. Successive "wrong" decisions are met with forks, but those
that think them "right" will all be moving in harmony towards their next
project milestone. I think this project could use more of that.
Please correct me if I am wrong on these points.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
