Re: The Policy(tm)

[Braden McDaniel]

Quoting Guido Draheim <address@hidden>:

> 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?

 1. Find out what's not clear.
 2. Make it clear.

There is a certain level of responsibility on the part of a macro author to
illuminate the issues, and to act as an advocate for the approach represented in
his submission. If the author of a macro does not do that, and no one else does
either, it is indicative of the level of interest in the macro.

> 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?

The archive maintainers are the arbiters, ultimately.

> 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.

Do you think the review period should be longer? What's a reasonable time frame
for someone to be able to answer reasonable questions about a macro they wrote?

> 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.

Let us not forget that the nature of the software license means that the author
need not acknowledge every little change. Of course it is desirable that he be
informed. But it would be a shame if the archive maintainers did not make a
change that improves the archive just because some author has fallen off the
face of the earth.

> 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.

If someone is submitting a completely new macro that duplicates existing
functionality rather than submitting a fix to the existing one, it is only
natural and appropriate that his submission should have to pass a high standard.
If the submitter is not able to demonstrate clearly that his approach is 
better, 
then it is appropriate that the macro be rejected.

> 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.

Yes, this policy does mean more work for the maintainers than one that would
permit redundancy in the archive. No doubt about it. If the maintainers aren't
willing to understand the different macros and act to resolve an impasse when
needed, then a policy which requires that the archive provide a single solution
to a given problem probaby isn't implementable.

> 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.

As a macro author, I wouldn't particularly care to have my macro grouped with
one I think is inferior just because no mechanism is in place for expunging the
old macro from the archive.

> 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? ;-)

I think a better solution would be simply to allow extension and/or suspension
of the review of a macro pending the availability of persons deemed essential to
its consideration. I don't like the idea of postponing a decision indefinitely.

-- 
Braden McDaniel                           e-mail: <address@hidden>
<http://endoframe.com>                    Jabber: <address@hidden>