good point, more over there were open four blockers in one
day by one person just when we claimed to release RC3 and then
final. We should really change policy in this sense.
Ideally should come two RC in shorter period (two or three
weeks) and then final.
Currently we have RC1 in October, RC2 in December. RC3 who
knows. Sometimes I have impression that there are people who
don't care about releases (which is acceptable) and
people who are in the result blocking (or making releasing
process painful).
I hope you would agree that the goal is to ship the best bug-free
release we can, and that devs reporting bugs pre-release is a much
better situation than users being hit by the same bugs post-release. I don't like the delay or super-long time between releases any more than you do, and understand the frustration, but knowing about important breakage is only a good thing! -- it is a good thing they are found & fixed weeks before release and not in the weeks after!
Those bug reports all came together because it was the first time I'd tried a new install of WinGrass in months, and I was keeping careful notes of the experience of doing it on a new machine as part of the upcoming release testing. I would hope that more people could do this.
Certainly binary release is out of the question until the license violation in the wingrass packages is resolved. The situation is untenable as-is, but pretty easy to fix with an extra page + [yes/no] + wget as a near-last page the nsi installer I think.
Please let's just focus our energy on fixing bugs and so getting the release out..
Certainly binary release is out of the question until the license violation in the wingrass packages is resolved. The situation is untenable as-is, but pretty easy to fix with an extra page + [yes/no] + wget as a near-last page the nsi installer I think.
please feel free to work on it. If nobody will fix it, we can release
GRASS without binaries for Windows
This is a wrong place where to discuss GRASS project issues.
Still, as it's too late, I'll drop in my rant:
The problem is that we have too big changes in 6.4.x. Most of blockers are
in features that were not existing in 6.4.0, 6.4.1. As fixing bugs
sometimes involves introducing new code and new features, finding new bugs
is unstoppable. Want an example? Take look at "identify" problems of
vectors. In 6.4.0 it was plain v.what with printing in console. Pretty?
No, but worked well. Now try to count how many blockers/critical bugs were
filled against the new identify tool. As long as we will continue to
introduce new features/change existing behaviour (i.e. import and launch
into PERMANENT) just 5 min. before release, we will have blockers just 1
minute before release. I'm sorry, I don't have any free time for GRASS
testing. I'm (and probably others too) reporting issues when I find them
during ordinary work or when my labs fail because of "new and cool
feature".
"Unlike the Visual C++ 2005 and 2008 redistributable packages, there are
registry keys that can be used to detect the presence of the Visual C++ 2010
redistributable package."
any hints about needed versions, different runtime handling in different
windows versions (xp - yes still there, vista, 7, 8) are welcome...
Replying to [comment:20 marisn]:
> This is a wrong place where to discuss GRASS project issues.
>
> Still, as it's too late, I'll drop in my rant:
> The problem is that we have too big changes in 6.4.x. Most of blockers
are in features that were not existing in 6.4.0, 6.4.1. As fixing bugs
sometimes involves introducing new code and new features, finding new bugs
is unstoppable. Want an example? Take look at "identify" problems of
vectors. In 6.4.0 it was plain v.what with printing in console. Pretty?
No, but worked well. Now try to count how many blockers/critical bugs were
filled against the new identify tool. As long as we will continue to
introduce new features/change existing behaviour (i.e. import and launch
into PERMANENT) just 5 min. before release, we will have blockers just 1
minute before release. I'm sorry, I don't have any free time for GRASS
testing. I'm (and probably others too) reporting issues when I find them
during ordinary work or when my labs fail because of "new and cool
feature".
I also am VERY supportive of getting releases out more rapidly. But I know
where Maris is coming from. I try to test any any new features as soon as
I can on the Mac. But the frustrating thing is when I discover (in the
process of doing work or teaching) things that USED to work, now don't due
to some upstream change. Especially when working with release candidates,
it is essential to test any changes thoroughly when committing or
backporting. It's hard enough to test and fix existing bugs and new
features, but having previously working code broken makes vetting a really
tough task. More testers always help too.
On Sun, Mar 10, 2013 at 4:06 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
...
it seems not to be really obvious from the different reports which version
of the ms runtimes is needed?
...
in the last weeks there were reports about missing msvcp100.dll...
Just guessing around: what if we "wget" dump all these msvcpXYZ.dll
files into the lib/ directory? If it comes first in the DLL path, it may
not conflict with any system DLLs?
Just guessing around: what if we "wget" dump all these msvcpXYZ.dll
files into the lib/ directory? If it comes first in the DLL path, it may
not conflict with any system DLLs?
good point.
AFAIK the msvcrt runtimes are delivered as exe/msi by ms and should be
installed,
The above includes GRASS and all of its dependencies
except for WxWidgets. However, the latter also seems
to build OK with recent versions of MinGW-64:
Realistically speaking, it will take a few more
weeks for me to complete and test the build chain.
We plan to release the resulting binaries with
gvSIG CE 1.0 (which will ship with GRASS 6.4.3 as
a geoprocessing backend). From that point forward,
i.e. GRASS 6.4.4, it might be feasible to base GRASS
Windows releases on the gvSIG CE build chain:
no more pesky VC runtime DLLs!
Also, in case you are not using it yet:
"Dependency Walker" is really helpful for
locating DLL-related problems.