Re: Macro Archive Relaunch

[Peter Simons]

Guido Draheim writes:

 >> - A short description of the macro (summary) is visible on the
 >> index page.

 > I did try that lately too - but dumped it as it did clutter the
 > index page with information not really helpful.

There is no need to force the summary onto the index page. It is
absolutely feasible to let the user chose one with short descriptions
or one without them. Nor is it necessary to provide a short
description for macros where the name itself is descriptive enough.
The current index page of the archive shows it for the macros that
provide one and it does not look too bad to me. But again, any number
of presentations can be generated without significant effort.


 >> - Authors can be formatted into a real <a href="mailto:...";>name</a>
 >> element on the web page.

 > [...] Personally, I do have some politic problems whether it is
 > actually a wish of the original author be scanned by bots [...].

If the author does not wish to have his e-mail address made public, he
doesn't need to provide one. The <email> tag is optional.


 >> - The synopsis may include <br/> tags to allow for multi-line
 >> formatting.

 > [...] if the synopsis happens to be too long than something may be
 > wrong anyway.

For complex macros, the number of variations may be big enough that it
is easier to list the major "branches" of syntax separately rather
than fitting all of them into one line with tons of brackets thrown
in. Also, packages of macros, which list several macros in one page,
might need this feature. Besides, anyone who doesn't need it should
simply not use it.


 > In parts it stems from the fact that the gnu ac-archive uses h2
 > tags - using some smaller layout tags improves the situation [...]

There is no way to predict the size of an <h2> tag -- or _any_
character on the page, for that matter -- unless you hard-code the
font sizes, what is the last thing I want to do.


 >> The <name> tag [...]

 > [...] I think you mean `macro bundles` as to have multiple macros
 > in one submission file, right?

Sort of. Some submitters have complained that their macros depend so
much on each other that it is hard to break them up into separate
submissions. And even if they did, the user had to download pretty
much all of them anyway. Thus, I wanted to add a concept of
"packages", where macros can be presented (and downloaded) in one
batch, but are nonetheless described individually. The <name> tag is a
first attempt at providing this capability.


 > Do you start a new cvs with it?

No. I re-used the repository original repository. That's what version
control is about, right? :-) I did replace the infrastructure itself,
though.


 > I don't see a problem to blend the new parts into the sfnet branch
 > (as long as the sfnet branch is needed, perhaps (hopefully?) it's
 > obsolete some day)

I never saw the point of the "sfnet branch" having its own macro
repository anyway, to be perfectly honest. I don't mind it the least
that you want to provide another presentation, different release
archive philosophy, etc., but having separate repositories of the
actual macros is, IMHO, counter-productive.


 > [...] some macros might be valid to live in two or more categories.

That is correct, indeed. In the old format, where the location of the
macro in the directory tree determined its category, having a macro in
more than one category was problematic, but in the new format we can
classify them into as many categories as we see fit.


 > Yes, I had to make up a kill list so that my automatic sync-scripts
 > do not try to back-update macros where I have already the newer
 > version in the archive.

What is obviously much less of an effort than helping me to UPDATE the
original repository ...


 > As to critize here: quick and nice response to users and their
 > submission are much higher needed than great new software to format
 > the submissions.

Since you've taken the liberty to criticize my work (throughout this
e-mail), let me say that perhaps me not being really responsive to
YOUR requests has something to do with you committing macros like this
classic example:

 | dnl @synopsis AC_NEED_TARGET_H [(PREFIX, [HEADER-FILE])]           -*- sh -*-
 | dnl
 | dnl  ---------------> superseded by AC_CREATE_TARGET_H <---------------------
 | dnl http://ac-archive.sf.net/guidod/ac_create_target_h.html          USE IT!!
 | [...]

>From CVS log:

    revision 1.3
    date: 2001/08/25 20:12:18;  author: guidod;  state: Exp;  lines: +65 -58

I guess the fact that you deliberately commit an obsolete version into
the archive (at the time you still _had_ CVS commit rights), which
clearly says that it is obsolete and directs users to your "version"
of the archive does understandably annoy me just a bit. I furthermore
assume that the fact that you formatted the macro in a way that breaks
my parser and produces incorrect output on the web page was complete
and utterly unintentional, right?

Let me remind you that the vast majority of content in your archive is
there BECAUSE of the fact that I DO respond to submissions.

>From where I am standing, it looks as if you mostly grab other
people's work, modify it a tiny bit, and then sell it to the world as
your achievement. The infrastructure I wrote is one example, the macro
repository I maintain is another. I am particularly fond of the mighty
"acinclude" tool, about which you say on your web site:

 | To overcome this problem area, Guido Draheim did develop the
 | "acinclude" tool recently - which is actually a copy of "aclocal"
 | modified for the needs of the "ac-archive"

Now, looking at the source code of your powerful tool we read:

 | ## HERE IS THE ONLY DIFFERENCE of $aclocal instead of original aclocal,
 | ## we scan the subdirectories for m4 files instead of the directory itself.

That is certainly an immense development effort and certainly you
should release your "recently developed tool" to the world under a new
name rather than ... uh, sending the fucking 20 line "diff" to the
authors of "aclocal" so that they can incorporate the feature,
shouldn't you?

I swore to myself that I would not get into this issue in this public
forum, but the incredible self-righteous tone in which you go ahead
and have the nerve to criticize me for the work that YOU COPY just
blew my fuse. Just because you legally have the right to re-use my
work doesn't mean that actually doing so (without giving proper
credit) will earn you a class A degree in style.

To summarize: If you have _useful_ comments, ideas for improvements,
or spare time to donate to this project, I'll be the first to welcome
you aboard and to work with you. But I am not willing to take this
kind of bullshit. Alright?

Peter