ac-archive-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sfnet microsteps


From: Guido Draheim
Subject: sfnet microsteps
Date: Thu, 27 Jan 2005 14:17:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906

Heya all,

hopefully the makeover of the gnu archive content is coming to a final
state - it seems that about all macros have been touched which I do
think is wrong in the first place: I am pretty sure that the ac macro
in the archive is now different of the ac macro a submitter uses in
his projects. If one would be really strict about this then one does
need to send out a mail to all "stake holders" about the modification.

I did not yet sync up the sfnet cvs content with any of those changes,
in fact, I did not touch any *.m4 file content. May be later - as a
prepration I was doing a `cvs log` on the old place of the savannah
m4 file creating a cousin ac_macro.log file for each ac_macro.m4, so
it keeps record of the history as a separate file.

In another microstep I did remove all the duplicate *.m4 files that
lived there for the "subdirectory is category" perspective. Since we
do have @category now this has become superfluous.

In another microstep, the gendocs part is parsing the *.log file
along its *.m4 master - extracting the category out of it. That wipes
out the directory component to have any significances after all. A
macro may now live anywhere and it gets registered correctly.

Actually, I think to expand on this technicality - the *.log file is
being used to contain any maintainer-only information pieces. That
allows a maintainer to modify the @category for visualization on the
web without touching the submitter's ac macro content. If the
submitter registers an explicit category in the ac macro content
then it will be used - this mode is best for new submissions where
a submitter is often unsure what target category serves best.

In essence: (a) the maintainer part is separated from the submission
(b) the downloaded m4 file will be the same as the submitter's
(c) the maintainer can add fields as needed for proper functionality
(d) syncing *.log files keeps an unbroken history, even with log
    entries made in a submitter's personal archive giving details.

These un-duplication un-importance of the directory place have been
made to prepare any sync in the light of the gnu archive shuffling
around things heavily lately.

have fun,
-- guido





reply via email to

[Prev in Thread] Current Thread [Next in Thread]