Re: The Policy(tm)

[Guido Draheim]

Peter Simons schrieb:
> Braden McDaniel writes:
>
>  > Having macros with duplicate or overlapping functionality is a good
>  > way to confuse users and bloat the archive with redundancy.
>
> I agree with Braden on this point. If two macros do _basically_ the
> same thing, and each of them can do something the other one cannot,
> then _both_ are wrong. :-) I realize that this will be a borderline
> decision sometimes, but let's aim high ... and compromise when
> necessary.

he he :-) I stand firmly against both of you - it has real reasons
of practical matter, let's see if I can put it in straight words.

suppose we have a macro in the archive that provides some
functionality (say, "mdl_have_opengl"), and a new macro is
sumitted that clearly overlaps in functionality (say,
"ax_check_gl"), and it is not clear to the ac-archive maintainers
whether one is superior in all respects (as for inclusion
relation). How to proceed?

Let's furthermore assume that we see it as a clash and we want
to have it resolved. The question stands just how and when.
For one part, the best would be to contact both authors and
try to get them to sit together and straighten the efforts
possibly leading to a combined effort. If that works out then
it is just fine. But what if not?

There are numerous things that can go wrong, and it has a
simple reason - the sit-together act simply means time and
effort and not everyone has that time, or wants to put this
energy up, specifically not in a short time-frame as the
usual two-weeks peer review phase. Yes, if you have to get
three or more people together over the network to do some
real work, then two weeks is a real short timespan. Just
looking at a macro to be reviewed and say `objection, please
check this or that`, well that's easy, especially if it is
just formalities like naming scheme of macros or defines.

Furthermore, the later submitter happens to be in an inferior
position, since his macro is put on hold in the pain area
while the old macro already is in the main trunk. And through
wicked ways of real life, the maintainer of the old macro
might just be on vacation or consumed with much of other
pay-check work to get up and into a good-will discussion
with a new guy.

And additionally, it is also extra work on the head of
archive maintainers since they would have to watch over
it and try to resolve the clash, which might mean even
more work, and just making a decision to say `okay, the
old maintainer is not reachable in the last two weeks or
seems to be not willing` well that may turn out to be
just the wrong track and counterproductive to the
well-respected recognition of the ac-archive.

The best way which I propose - accept overlapping macros
into the ac-archive but clearly mark the two of them
putting crosslinks between them. I think it is furthermore
quite likely that later a third guy comes along that
shows yet another way to target the problem area which
is better than both of the old ones making the two of
them obsolete - this new-try will be pushed if there are
markers on both of the older and overlapping macros.

In other words: putting up overlap-markers on macros
simply makes them marked as `please review`. It is
a simply means to extend the review process even at
times that both are in the main area, and it puts the
two macros in equal rank firsthand. Through usual
style of living in the opensource world, the things
will be sorted out sooner or later (well, perhaps later).
And there are enough ways to name macros slightly
different - after all they `overlap` in functionality
and therefore each has a disticnt `difference` that can
be picked as a modifier for the name.

comments? objections? acceptance? ;-)
-- cheers, guido