On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 3:37 PM, Zach Welch wrote:
>
> >>>> 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.
> >
>
> How was it incomplete? It still compiled and I saw no obvious
> errors. The only contentious portion is the changing of a the
> function names that included uX.
1) Does not update the style guide.
2) Does not include inttypes.h or stdint.h unconditionally.
3) Does not remove those headers from other files
Basically, the rest of the work that I did in the patch that I posted.
Sure, that's all trivial, but they validate the point.
> >>> 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?
> >
>
> As we already know, the bulk of the work for 0.2.0 is in the tree
> already. In terms of risk/reward, both patches provide low reward for
> low-medium risk. I wouldn't really consider either for 0.2.0 just
> because they don't really impact the users at all. It's just a
> consistency cleanup in the code.
I would not bet on all changes being in the tree. Too presumptuous.
> > 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.
> >
>
> Any change increases the cost to anyone developing patches out of
> tree. In the grand scheme of things, neither patch is necessary today
> and neither really reduces the impact on outstanding patches. In
> either case, some set of patch authors will need to do some work to
> update.
>
> > 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?
> >
>
> I'm much more a fan of "think first, then do". In this case, rushing
> to enforce consistency doesn't magically make the situation better.
> For 0.2.0, neither patch should be accepted since neither introduces
> any bug fix or user visible benefit. As for tomorrow, we should
> actually figure out what we want to do and then make a patch to do it.
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that fact.
> >>> 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.
> >
>
> Yup and having a discussion on the merits of each is good and healthy.
Not always. This thread has turned into a case in point. Seriously.
> > 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.
> >
>
> There is _no_ harm is having a discussion on alternatives. It doesn't
> make us any less efficient or effective. It _does_ allow for both
> side to show their cards and for the points to be clarified. I didn't
> feel to need to "just drop it" because the arguments presented for the
> short types were based on preference alone. So far we've had a few
> early opinions followed by a few long opinions. Only you and I seem
> to really be debating anything. The majority in this case spoke early
> and haven't really participated in any discussion. There isn't a
> consensus (implies everyone agrees) nor does there need to be one at
> this stage. Not every issue can be resolved solely on technical
> merits and settled in a quick survey.
There will never be consensus if you define it as "everyone agrees".
That will never happen on these kinds of issues.
> > 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.
> >
>
> Benevolent dictators certainly keep things moving along, but they also
> kill off lots of potentially great ideas along the way. This is an
> open-source project. We don't have any real deadlines. We don't have
> management telling us what to do. We don't have marketing telling us
> when we must release or what features we need. Open discussion of
> issues big and small is good and healthy. Given enough time, most of
> the issues will ultimately settled by some form of compromise. The
> benevolent dictator model just circumvents a consensus by declaring it
> so. That isn't necessarily bad but isn't necessarily good either. Do
> you really think Linus is able to pick the best option 100% of the
> time? You might be surprised at how these types of discussions
> frequently result in even better results than the original "sides"
> that were offered.
>
> > Please correct me if I am wrong on these points.
> >
>
> For some things, there is no right or wrong. This is one of them.
Everything can be classified on a scale of right and wrong to you or me,
we just may not agree to share mutual scales of measurement.
1) I think it is wrong for a release manager to say "we don't have any
real deadlines". That severely undermines the position's authority.
2) I think it is wrong to say that we don't have "management". The
project has started to provide singular guides for being a "responsible"
developer within the OpenOCD project. Such responsibilities are
codified into policies like the Style Guide. Those must be enforced by
someone granted the authority to do so. No matter what you call those
people, they are performing management roles in the community.
3) It is wrong to believe no one needs to say when we must release or
what features we need. That process will not reach "consensus" without
someone leading the way, setting deadlines, and enforcing them.
4) It is wrong to assume that Linus has a lot of say in most Linux
development anymore. He has delegated most of the system to major
subsystem maintainers that make the decisions that he used to make;
however, each of those maintainers gets to function independently,
making their own choices. They do not always make the right choices,
which is why there are so many forks from which one can choose.
It is better to make a "wrong" decision that is "right" today and fix it
when it becomes a problem. The alternative (true consensus building)
will result in a product that I will not want to use. It will be slow
to produce because of its design-by-committee nature: a total nightmare.
Further, a truly benevolent dictator would recognize consequences to
temporary solutions and realize a plan for correcting them (as necessary
and when resources permit). But really, we're talking about managers,
not dictators; it _is_ open source, and a bad manager should be
summarily dismissed or exiled. Still, they are required by projects
that want to get things done without endless debates (like this one).
If anything, the people doing such work in this community need to be
granted the authority to carry out their responsibilities efficiently
and effectively. That means making independent decisions after taking
input from the community. However, this thread is not already covered
by any existing cases, as the community does not recognize a singular
individual as the System Architect. Perhaps this shows we need one.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
