[GRASS-user] Grass 6.3 Mac - r.patch parse error; mailing list migration search troubles

[Frank Warmerdam]

Hamish wrote:
> mailing list woes:
> 
> I first searched for the thread, and found one on grass-dev from 2007-09-18
> titled
>  "[GRASS-dev] g.mlist problem - followup"
> but the Gmane archive is producing an error "weft didn't produce an output."

Hamish,

I can't comment on gmane issues.

> and the ht://Dig -dev mailing list search can't even find any matches on a
> search for "grass". (in the past Markus explained this might happen when it was
> doing a rescan)
 >
> The other day a ht://Dig seach gave results, but the links were misaligned and
> you ended up with another random post or not-found error when you clicked on a
> promising summary.

I can't comment on ht://Dig.  Hopefully fairly soon the new mailing list
archives on lists.osgeo.org will be picked up by the various search engines
and searchable that way.  I wouldn't be adverse to implementing some sort of
"on server" search for lists archived by lists.osgeo.org if that is really
helpful (instead of waiting for them to be indexed by the search engines), but
I would need some guidance on good approaches.

> I also notice that old commits wait to be copied to the new osgeo server:  (?)
>   http://lists.osgeo.org/pipermail/grass-commit/

As Markus noted, I was hesitant to ingest the 250MB or so of old commit
messages.  It seems like a very low value archive considering that the history
is all available in subversion anyways.  I did of course preserve all the
original content lists (like grass-dev, etc).

If folks felt really really strongly about carrying over the commits archive
I could do so but it seems like a poor use of administrator and system
resources.

> I also notice someone posted with a bad clock, any chance to fix that with an
> low-level edit with info taken from elsewhere in the email's header info?
>   http://lists.osgeo.org/pipermail/grass-dev/1971-June/021316.html

Speaking of a poor use of administrator resources...

I'm keen to make lists.osgeo.org (and other osgeo system services) useful to
the GRASS and other project communities, but I'm also keen to use admin time
efficiently (ie. lightly) and to aim for maximum leverage.  So, implementing
lists.osgeo.org search services might be a hassle, but I can see it would give
more immediate search results than search engines, and would be leveragable
over all the lists on the system.

Manually editing .mbox files to fix up corrupt dates ... not so keen.

I'd add that I have to do all my osgeo.org administration over an ssh link
with an approximately 1.5s latency due to my sat link.  The pain of this
makes me grumpy quickly.  :-) There is definitely room on the OSGeo system
administration committee for additional volunteers with smome experience
and a willingness to make a significant commitment.  Wolf has already
accepted substantial Drupal related responsibilities but has sensibly
avoided getting lots of other stuff dumped on him.  But of course, part
of the objective is to provide useful services to the projects in a
more efficient manner than would be the case if we were each doing our
own thing.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org