Re. the current state of GEM:
The RCs did not trigger as much feedback and bug reports as
I hoped. From what I got and my own testing I would think
that GEM is stable enough to go into CVS now. In the next
days I will smooth out some minor annoyances. Functionality
is basically where I wanted it to be. For now, I plan no
major additions.
The documentation should be sufficient to allow people to
use the software and design their own extensions.
For integration into the main CVS, I suggest the following things:
1. GEM itself is just plain ANSI C. The executable should be
installed in /usr/local/bin or whatever the user chooses as
exec path.
2. The GEM manual in HTML format should be linked to from the main
index.html page.
3. A specially formatted comment line needs to go into index.html
to specify the position at which extensions will install links
to their own documentation pages (see my last email to this list)
4. A directory containing a "skeleton" extension should go somewhere
(maybe in etc? where the user can easily find it)
I have only used CVS for downloading source code so far. I can
learn it
but I don't know when I will be able to, as sessions have started at
my university. Maybe someone would volunteer to put GEM into CVS?
Best,
Benjamin
----- Originalnachricht -----
Von: Markus Neteler <neteler@itc.it>
Datum: Mittwoch, 29. März 2006 11:15 pm
Betreff: Re: [GRASS5] features needed for 6.2> On Wed, Mar 29, 2006 at 07:49:32PM +1200, Hamish wrote:
> > Ok, trying to combine everyone's comments into a draft
plan/roadmap:> >
> > We release 6.0.3 whenever it feels right, independent of 6.1+.
>
> Yes, we can even do this soon as I have backported two
> relevant changes (NVIZ tcltk8.4 support and fftw3)
>
> ...
> > Consensus is to include GEM and gis.m in 6.2.0. It would be
nice
> to have
> > them both in raw form in the 6.1.0 development snapshot
release, but
> > they don't have to be perfect for that.
>
> Benjamin, what's the state?
>
> ...
> > SQLite as default db: I think SQLite support is still too
young and
> > lightly tested, and it is too important that it doesn't have
> problems.> Also I don't like the extra dependency.
>
> SQLite is getting fairly standard these days. Also QGIS needs it.
> We can just invite people to use GRASS-SQLite to find out if it
> works or not. I do so since I find DBF pretty limited.
>
> > If consensus is that this should
> > happen at some point, I suggest it does in CVS in the *days
> after* 6.2.0
> > is released. But this is a catch-22 situation.. to get tested
it
> needs> to be default, so if consensus is that it should be
default
> for 6.2.0, I
> > think we need to make it the default ASAP.
> >
> > New startup GUI: if it is ready by 8 weeks after 6.1.0 it can
be in
> > 6.2.0. Otherwise add it after.
> >
> > GUIs for r.digit*, i.points: If ready in the 4 weeks after
6.1.0 is
> > released put it in for 6.2.0. If after that then wait until
> after 6.2.0.
> > i.e. We shouldn't wait for it to mature before we can release 6.2.
> > Same for a GUI frontend to g.gisenv and gis.m preferences.
> > [*] I take it you meant r.digit and not v.digit Michael?
>
> Not related to GUI, but related to a new i.points (as long time
> promised):
>
> http://mpa.itc.it/markus/tmp/i.points.auto_30_mar_2006.tar.gz
>
> This should be the merge of i.points + i.vpoints along with
> homography support (geocoding by lines instead of points which is
> much easier/faster) and auto-GPC search (based on Fourier
> correlation).There is a file HANDBOOK inside which explains it a
> bit. Today
> I found some raster-map negative row bug, maybe someone wants to
> give it
> a try? Would be fun to have that in GRASS soon.
>
> ...
> > If he is happy to do so, I hope Markus will remain as release
> manager> and generally as the arbitrator in charge of final
decisions.>
> Yes, I can give a hand of course.
>
> > I feel really good about where 6.1-cvs is right now; 64bit &
> large file
> > bugs are still trickling in (as expected), but otherwise
things are
> > pretty strong.
>
> Well, 64bit is doing pretty well AFAIK (only 64bit machines in
the
> officenow). Large file is causing problems, Glynn had commented
on
> this but
> then the issue disappeared. Maybe his grass-header-fix script
> could also
> do the config.h trick which he suggested?
>
> Markus
>
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>