Re: Macro Archive Relaunch

[Guido Draheim]

Peter Simons schrieb:
> 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.

hmmm, just to get that straight - the index item has only a default
for the filename stem and the user may replace it with its own
one-liner. That might impose problems to readability if that does
not follow a certain scheme but I am quite confident that it does
work out somehow. Just needs someone to look over it ;-)

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

Ahmm, it's all about the converting the classic ones, if the user
knows about having a href to get into the webpage layout, that is
all perfectly well.

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

aaaah! now that's a very good one - alternative synpsis. I am not
sure however if it is best to use <br> instead of a proper list that
gets visuallized with as a the list combined with <br> between
them.

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

well, one can usually have a try, and it is quite big someplace ;-)

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

good.

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

just so there is a versioning for the sfnet webpage and packaging,
it is not some original intent to have one, and can be dump as
well if that is feasible.

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

I would well do so, but you threw me out of cvs access, and having
a dozen macros send by mail is a tedious task, especially if that
is not rewarded by immediate response.

>  > 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), 

... to help in the matter...


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

It must have been unintentional, and since the sfnet website did use the
very same formatter, it would have broken the webpage on sfnet as well.
No need to spawn conspiracy theories here, there are none about.

I am well astonished by the means of communication you choose, you did
not tell me about this exact problem you had with submissions, I would
surely have fixed that right away if you've told me. Neither did you
say it was a reason to kill write-access and not let me help you to
keep the gnu macro archive in the most uptodate form as possible.

It was quite obvious that there might have gone something wrong, so
I did ask you three times to have a chat, I gave you my telephone number
and asked for talk to clear up anything that might have become
misunderstood. You did just ignored these attempts. And to say it
loud, I do _not_ like it that problems in personal interrelations are
going to a public mailing list.

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

I did never say anything else.

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

you do grab other people's macros, and sell them to world.

There we have conspiracies coming up again - look back in history,
I did have a completely different backgrond: I did work up a
packaging system for my own series of autoconf macros so that
I could carry them between the different workplaces (home, univesity,
employer) and have them properly installed and versioned. When
the ac-archive came up as a topic, I was happy to see that there
was a wider approach of autoconf extensions. So I came on you
asking whether it would be fair to merge packaging into the
ac-archive infrastructure. You said yes and gave me the key.

When the work was done, I asked you if that was okay for you.
You said no, and threw it out - I was trying to ask you _what_
was wrong and to help me to fix it so that it does suit your
taste. No response. That was the moment the sfnet branch
sprang up, so I could continue with a combined approach of
the ac-archive and the packaging idea that I was in need so
desperatly in real life.

Of course, it does pick up the ac-archive macros. And at that
time I was thinking that it is just a temporary means as to
keep on the work and merge the branches a few weeks later.
That's the only reason it calls itself `ac-archive` too,
otherwise it would have been called `ac-packaging` or
some such - and perhaps that would not have given you the
idea of any intents to diminish your work. There was no
such original intent, please acknowledge that to my honour.


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

sarcasm? ;-)

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

aahm, would you please be fair - the announcment itself says that it is
derived from the `aclocal` tool. Later on, some more lines were added,
there are now a bit more differences that those marked as "THE ONLY"
(I probably should clean that). Yes, it would have been nice to merge
some functionality back, but `aclocal` has evolved ever since and it
is now using the infrastructure of later automake with their own
perl packages and config log scanning (is that the right term?).
Actually, I did not want to have a dependency on later automake
infrastructure so that the acinclude tool does still follow the
implementation of the one from 1.4.

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

yes, you did explode. The comments in the prior mail were on facts,
and it would have been okay to just comment on the facts in public
and make an extra private mail to me to communicate the personal
problems. I do not like to see it dragged into a public list, and
be in the need to respond to it in public.

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

Well, so far my incredible self-righteous tone would only say that
this was just the `last paragraph`. I've been always willing to help,
and the prior mail was an attempt to give _useful_ comments, both
for improvements and telling of experiences that I have made in
my own attempts with developing the project. The only personalizing
part is with the speed that you usually respond to e-mails and
the interactions with contributors about possible problems - and
that made you explode or so it seems. I maintain there was no
bullshit intended, and if you need more credit markers on the sfnet
webpages, that's no problem with me.

I would please ask you to kill any signs of conpiracy theories from
your mind - as that the sfnet branch had been an attempt to snatch
away your work, close to theft or something. It's been about to
extend your work and have it ready to get merged back as soon as
possible - even today, the `make rpm` will create a number of files
including ac-archive-doc-gnuorg-*.rpm, as an attempt to show that
the makesystem is still capable of making the gnu.org webpages, so
it can be picked up as is. It seems it got unnoticed by you. Since
it was always the intent to have the makesystem ready to get back to
gnu servers anytime soon, I did not chose to copy the gnu ac-archive
macros from  remote but to keep a local copy of them `as if` the
makesystem would run locally on the gnu repository.

Only later it came to be that the macros were updated independently,
as it turned out to seem them being sometimes more uptodate and the
gnu ac-archive to follow weeks and weeks later. That time skew and
depending workstyle put a stress on to me to think over what the
project will come to be in the forseeable future, and if it was still
okay to wait for you. It is good that now, years later, the topic
gets finally put-into-words by you as well, I was waiting for that
so long.

Let's put it straight and in a few words: I do not see a benefit in
trying to maintain projects uneccesarily if there is a volunteer
around who is doing it, also to _my_ benefit, and where I do only
need to _add_ some effort to help. The existance of the sfnet
branch is over the day that the gnu org ac-archive is capable of
doing what I need. It doesn't. So stop complaining that I am
doing something seperately.

looking forward to your response,
and surely it does _not_ need to be public, it is fairly okay with
me to explode on side channels - or on the phone. The lines are
still open, and to make it easier, I'll (re)send you my phone
number off-mailinglist the next minute. Let's get this done once
and for all, pleeeaassse.
-- cheers, guido