Re: The Policy(tm)

[Guido Draheim]

Braden McDaniel schrieb:
> Quoting Guido Draheim <address@hidden>:
>
> [...]
> The archive maintainers are the arbiters, ultimately.
> [..]
>
> 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?
we are speaking of opensource, done for free, in spare time.
so, hmmm, three months minimum until it can be ruled that
the original author has `fallen off the internet`, right?

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

not better - different, with its own value not present in the other one
but perhaps the old one has another approach not present in the new, so
there is no `better` but `overlap` to some (minor or larger) degree.

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

oops, let me quote that bonmot `if the maintainers aren't willing to understand
the different macros`. Actually, the maintainers _can_ _not_ have all the
wisdom in place to understand the quirks, specifically not the functionality
area that there is supposed to be targetted. They can just ask back as to
`what's different` and `why it can't be just merged into the original`, and
they have to trust the answer. If the question is answered as `oops, well it
can be merged` then fine, but what if not. Just clean the new functionality
for the new guy has not time to get too deeply into it? No no.

In fact the primary task of the archive maintainer should be to look for
formalities and replying with hints that will make the macro to exist more
easily next to all the other macros in the autoconf world. That's for
naming of macros, shellvars, config-defines, for picking AS-helpers and
default values, and for setting up proper documentation which might need to
point to `prior art` including macros with overlapping functionality.

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

a category `suspended`?

well, I'd see that as second best ;-) ... -- cheers, guido