but there is also the development-line of Grass64-svn, on which all the last WinGrass-Installers for testing are based.
for a consistent way of a definition of the destination folder should there maybe the list be adapted to reflect all development-lines (and for the update-function of the installer)?
maybe following options for the destination folder?
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
but there is also the development-line of Grass64-svn, on
which all the last WinGrass-Installers for testing are
based.
for a consistent way of a definition of the destination
folder should there maybe the list be adapted to reflect all
development-lines (and for the update-function of the
installer)?
maybe following options for the destination folder?
but there is also the development-line of Grass64-svn, on which all
the last WinGrass-Installers for testing are based.
for a consistent way of a definition of the destination folder
should there maybe the list be adapted to reflect all
development-lines (and for the update-function of the installer)?
maybe following options for the destination folder?
We *need* this to work. If GRASS can't handle being
installed in %ProgramFiles%, that's a blocker, IMHO.
It could be that this is a 6.4.0-final blocker, but //please// let's
hold off on r40496 and release 6.4.0rc6 before beginning to validate
that $GISBASE is space-safe.
AFAIK there are no more major RC-blockers left & we are ready to go
for rc6 -right now-. If we start on the next thing it's going to be
another 3 weeks+ before we can even think about shipping rc6. !@$%!#
It resets the release confidence cycle.
Similarly if it can't handle spaces in GISDBASE.
AFAIK all of those that are known have been fixed (I suppose mainly
thanks to a longer exposure to Mac users).
> Grass64-Release => %ProgramFiles%\GRASS-64
> Grass64-Dev => %ProgramFiles%\GRASS-64-SVN
...
> We *need* this to work. If GRASS can't handle being
> installed in %ProgramFiles%, that's a blocker, IMHO.
It could be that this is a 6.4.0-final blocker, but //please// let's
hold off on r40496 and release 6.4.0rc6 before beginning to validate
that $GISBASE is space-safe.
If not now, then when? We need at least one RC which installs into
%ProgramFiles% by default. If that isn't RC6, then we will need an RC7
even if RC6 appears to work perfectly, and if it turns out that there
*are* problems with RC7, then we would need an RC8 to test the fixes.
AFAIK there are no more major RC-blockers left & we are ready to go
for rc6 -right now-.
Fine. Then release RC6 -right now-, with the default installation
directory as %ProgramFiles%\GRASS-64-RC6.
If we start on the next thing it's going to be
another 3 weeks+ before we can even think about shipping rc6. !@$%!#
It resets the release confidence cycle.
At the risk of stating the obvious, a "release candidate" (as opposed
to a "beta") is ... a candidate for release. If no bugs are found,
then the RC gets released as the "release", with the only change being
that it's called "6.4.0" rather than "6.4.0-RC<something>".
If you know for a fact that the "RC" won't actually become the
release, even if no (significant) bugs are found, then it *isn't* a
"release candidate".
[bzzt, the wingrass lat/lon location creation has come up]
As I see it we are in need of three things-
1) a current, usable wingrass download for those needing to
get work done/teach now.
2) something that gets as much testing as possible for the
6.4.0 code with its final goals, which means exposing as many
bugs as possible, sooner rather than later.
3) A formal 6.4.0.X pre-release to act as a delta to compare
against for reversions, and a bit of a needed "we are getting
somewhere" boost. it's been half a year since the last one and
I'm sure you can hear my frustration starting to leak out...
Glynn wrote:
Then release RC6 -right now-, with the default installation
directory as %ProgramFiles%\GRASS-64-RC6.
That would be ok as the default IF we reenable the "expect (and
please report!) problems if you put it somewhere with spaces"
warning message for the benefit of the folks falling into (1)
above. Users need to be given the choice if they want to be
front-line testers or not.
With that warning message we'd get all three of the above in a
single release, & without having to wait for it. It's probably
helpful to have it there if only to mentally prepare wingrass RC
users to expect a bit of turbulence.
> Then release RC6 -right now-, with the default installation
> directory as %ProgramFiles%\GRASS-64-RC6.
That would be ok as the default IF we reenable the "expect (and
please report!) problems if you put it somewhere with spaces"
warning message for the benefit of the folks falling into (1)
above.
That may lead people to assume that the risk is higher than it
actually is, meaning that it doesn't actually get tested.
Users need to be given the choice if they want to be front-line
testers or not.
Not for Windows.
Windows users are NIMBYs; they all want someone else to do the
testing.
I'd even go so far as to *require* that $GISBASE contains spaces, if
it wasn't for the fact that some languages don't have a space in
%ProgramFiles% and users may be unable to install anywhere else if
they don't have Administrator rights.
On the plus side, Windows users are accustomed to having to install
patches on a regular basis
With that warning message we'd get all three of the above in a
single release, & without having to wait for it. It's probably
helpful to have it there if only to mentally prepare wingrass RC
users to expect a bit of turbulence.
FWIW, I suspect that spaces-in-pathnames bugs will probably be the
least of the problems (has anyone tried to find an actual solution to
the UAC issue yet?).
[bzzt, the wingrass lat/lon location creation has come up]
As I see it we are in need of three things-
1) a current, usable wingrass download for those needing to
get work done/teach now.
we just started last week with 17 students in regular class and 11 in
distance education, most of them installed winGRASS last week.
The first homework is due tomorrow so the basic functionality, including
nviz will get tested right away. I will report on how it goes.
We don't do much vector attribute DB operations and no
image processing so if somebody can get those tested on broader
scale that would be great.
Helena
2) something that gets as much testing as possible for the
6.4.0 code with its final goals, which means exposing as many
bugs as possible, sooner rather than later.
3) A formal 6.4.0.X pre-release to act as a delta to compare
against for reversions, and a bit of a needed "we are getting
somewhere" boost. it's been half a year since the last one and
I'm sure you can hear my frustration starting to leak out...
Glynn wrote:
Then release RC6 -right now-, with the default installation
directory as %ProgramFiles%\GRASS-64-RC6.
That would be ok as the default IF we reenable the "expect (and
please report!) problems if you put it somewhere with spaces"
warning message for the benefit of the folks falling into (1)
above. Users need to be given the choice if they want to be
front-line testers or not.
With that warning message we'd get all three of the above in a
single release, & without having to wait for it. It's probably
helpful to have it there if only to mentally prepare wingrass RC
users to expect a bit of turbulence.
A combination of those factors means that Windows users need to
regard a degree of beta-testing as part of the "entry fee".
what I'm saying is that we should prepare them for that and have
work-arounds handy, instead of selling it as fully ported and
then having them write off the whole thing as buggy crap 10
minutes into trying it for the first time. I'd rather they be
surprised by how well it worked in spite of a warning that says
some things might not work and they should report them to us to
get it fixed.
It's all in how that warning is worded and where it is placed.
Simply due to the sheer numbers of them, some percentage will be
interested in filing reports, and some of those might even have
the MS Win experience which we currently lack..
I will report more tomorrow, but so far the winGRASS users here had a pretty smooth experience -
(except for some quirks related to t the winpython 2.5 issues (212 is needed) if they are running GRASS and ArcGIS with python 2.5).
This relates to the stand alone installer, versions before the latest one from January 15 so far.
The osgeo4w version appeared to be more problematic and we don't use it.
So the experience with winGRASS so far (we are just starting 4th semester)
has been smoother than with Mac and linux
binaries which generally require much more work and expertise to get them running.
And I don't help winGRASS users because I don't run MSWindows at all so they are
on their own.
Anyway - a notice that this is the first native Windows version of GRASS would be
certainly useful but it does not need to be too scary - rather we should make sure
that the help pages are up to date and some getting started material is on-hand.
Helena
P.S. I hope I won't get half the class tomorrow complaining that they could not get winGRASS running
in case something is broken in the latest installer.
On Jan 18, 2010, at 11:13 PM, Hamish wrote:
Glynn wrote:
A combination of those factors means that Windows users need to
regard a degree of beta-testing as part of the "entry fee".
what I'm saying is that we should prepare them for that and have
work-arounds handy, instead of selling it as fully ported and
then having them write off the whole thing as buggy crap 10
minutes into trying it for the first time. I'd rather they be
surprised by how well it worked in spite of a warning that says
some things might not work and they should report them to us to
get it fixed.
It's all in how that warning is worded and where it is placed.
Simply due to the sheer numbers of them, some percentage will be
interested in filing reports, and some of those might even have
the MS Win experience which we currently lack..
Just a feedback on the installer for WinGRASS - I was lucky that everybody in the class
managed to install GRASS from the working version - so no problems so far and the first
steps with wxGUI were MUCH smoother than last semester, so all those little tweaks with
icons and other GUI issues helped.
There were 2 or 3 distance students who had to get the newer svn version,
so it looks like now I am the only one confused about the different WinGRASS installers -
- is r40456 broken ? If yes, should it be removed from the web site
and the previous one put there while the fixed svn version is tested?
Or am I misunderstanding the situation?
The link to the daily binaries (thanks a lot for that, especially for the GRASS65) here
would help as well http://grass.osgeo.org/grass64/binary/mswindows/native/
thanks a lot to everybody for a smooth start,
Helena
P.S. one more thing - having WinGRASS and MacGRASS start with different default
GUI is really awkward and people have trouble figuring out how to switch even after given
instructions. Linux users (I always have 1-2 in class ) are used to tweaking things
so it is not an issue there although it would be much simpler to have all binaries start the same way
out of the box.
On Jan 18, 2010, at 11:54 PM, Hamish wrote:
Helena wrote:
The osgeo4w version appeared to be more problematic and we
don't use it.
(the latest osgeo4w GRASS build was back in October)
in case something is broken in the latest installer.
umm, sorry about that.
"$\r$\n" in r40456 launch scripts now fixed in svn.
Just a feedback on the installer for WinGRASS - I was lucky that
everybody in the class managed to install GRASS from the working
version - so no problems so far and the first steps with wxGUI were
MUCH smoother than last semester, so all those little tweaks with
icons and other GUI issues helped.
great, and with time it will only get better..
There were 2 or 3 distance students who had to get the
newer svn version,
so it looks like now I am the only one confused about the
different WinGRASS installers -
P.S. one more thing - having WinGRASS and MacGRASS start with different
default GUI is really awkward and people have trouble figuring out
how to switch even after given instructions.
fwiw Config -> GRASS working environment -> Change default GUI should
now work everywhere. (but on wingrass the "Start wxGUI" and "Start tcl
GUI" menu items/icons will still override that)
Just a feedback on the installer for WinGRASS - I was lucky that
everybody in the class managed to install GRASS from the working
version - so no problems so far and the first steps with wxGUI were
MUCH smoother than last semester, so all those little tweaks with
icons and other GUI issues helped.
great, and with time it will only get better..
There were 2 or 3 distance students who had to get the
newer svn version,
so it looks like now I am the only one confused about the
different WinGRASS installers -
I see - that perfectly explains it, because that is what we are using.
Talking about MSys - I really like the wxGUI + MSys option as it
provides a nice way how to introduce people to linux,
Helena
P.S. one more thing - having WinGRASS and MacGRASS start with different
default GUI is really awkward and people have trouble figuring out
how to switch even after given instructions.
fwiw Config -> GRASS working environment -> Change default GUI should
now work everywhere. (but on wingrass the "Start wxGUI" and "Start tcl
GUI" menu items/icons will still override that)
