during the testing period of 6.2.2-RC1 we got the following
issues fixed:
* DBF driver: fix semicolon problem (Glynn Clements)
* SQLite transactions to speed up execute (Antonio Galea)
* GUI startup: fixes browsing for EPSG file not updating path to it (Maris Nartiss)
* GUI startup: fixes browsing for new location path (Maris Nartiss)
* nviz compilation fix for MacOSX (Markus Neteler)
* r.in.gdalwarp: remove bashisms (Hamish Bowman)
* v.dissolve: fix for DBMI error if input map is specified with @mapset (Markus Neteler)
* v.lrs.* fixes backported + new documentation (Markus Neteler)
* Czech translation updated (Jachym Cepicky)
I would suggest to release 6.2.2 officially the next days if nobody
objects.
Markus
--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
FBK-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
Hello Markus
As I noted before (http://grass.itc.it/pipermail/grass-dev/2007-May/031699.html) Grass 6.2.2 seems to already be tagged (as grass_6_2_2) in CVS. I wonder how/when this happened, but it was definitely before 28th May as that was when I sent that e-mail. I still think it is a good idea to include the date of releases in the tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 - what do you think? Or is there any other way of telling from CVS on what date the tag was created?
Paul
On Sun, 1 Jul 2007, Markus Neteler wrote:
Hi,
during the testing period of 6.2.2-RC1 we got the following
issues fixed:
* DBF driver: fix semicolon problem (Glynn Clements)
* SQLite transactions to speed up execute (Antonio Galea)
* GUI startup: fixes browsing for EPSG file not updating path to it (Maris Nartiss)
* GUI startup: fixes browsing for new location path (Maris Nartiss)
* nviz compilation fix for MacOSX (Markus Neteler)
* r.in.gdalwarp: remove bashisms (Hamish Bowman)
* v.dissolve: fix for DBMI error if input map is specified with @mapset (Markus Neteler)
* v.lrs.* fixes backported + new documentation (Markus Neteler)
* Czech translation updated (Jachym Cepicky)
I would suggest to release 6.2.2 officially the next days if nobody
objects.
Markus
--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
FBK-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
I would suggest to release 6.2.2 officially the next days if nobody
objects.
Hi,
While at sea I found a glitch with v.in.gpsbabel on the Mac which I'd like to
fix before release. (unportable call to "stat -c%s" for file size during XML
parsing; replaced with "wc -c")
I've a huge pile of data, unpacking, and gear repairs stacked up in the middle
of my lab to deal with, but I'll try to get the fix into CVS later today or
tomorrow.
Hamish
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
On 7/1/07 12:05 PM, "Markus Neteler" <neteler@itc.it> wrote:
Hi,
during the testing period of 6.2.2-RC1 we got the following
issues fixed:
* DBF driver: fix semicolon problem (Glynn Clements)
* SQLite transactions to speed up execute (Antonio Galea)
* GUI startup: fixes browsing for EPSG file not updating path to it (Maris
Nartiss)
* GUI startup: fixes browsing for new location path (Maris Nartiss)
* nviz compilation fix for MacOSX (Markus Neteler)
* r.in.gdalwarp: remove bashisms (Hamish Bowman)
* v.dissolve: fix for DBMI error if input map is specified with @mapset
(Markus Neteler)
* v.lrs.* fixes backported + new documentation (Markus Neteler)
* Czech translation updated (Jachym Cepicky)
I would suggest to release 6.2.2 officially the next days if nobody
objects.
Markus
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Hello Markus
As I noted before
(http://grass.itc.it/pipermail/grass-dev/2007-May/031699.html) Grass
6.2.2 seems to already be tagged (as grass_6_2_2) in CVS. I wonder
how/when this happened, but it was definitely before 28th May as that
was when I sent that e-mail.
Mea culpa! I want to shift this tag now to remove the mess. The "enter"
key was too close,
I hit it before starting thinking. Sorry.
I still think it is a good idea to include the date of releases in the
tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
what do you think? Or is there any other way of telling from CVS on
what date the tag was created?
I don't know but I remember that someone (Glynn?) suggested to NOT
include the
date so that it wasn't done any more.
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
I still think it is a good idea to include the date of releases in the
tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
what do you think? Or is there any other way of telling from CVS on
what date the tag was created?
I don't know but I remember that someone (Glynn?) suggested to NOT
include the
date so that it wasn't done any more.
Well that's fine then if it has been discussed - I guess I just missed that when it happened but there were I'm sure good reasons for it then. FWIW my reasons for keeping with the old-style tags would be (a) less likely to create a tag by accident as you're putting a meaningful date into it and have to stop and think about that and (b) easy quick reference looking back through the web-based CVS browser as to the dates of the earlier releases.
But neither of those are particularly important. Good luck in shifting the tag!
I still think it is a good idea to include the date of releases in the
tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
what do you think? Or is there any other way of telling from CVS on
what date the tag was created?
I don't know but I remember that someone (Glynn?) suggested to NOT
include the
date so that it wasn't done any more.
Well that's fine then if it has been discussed - I guess I just missed
that when it happened but there were I'm sure good reasons for it
then. FWIW my reasons for keeping with the old-style tags would be (a)
less likely to create a tag by accident as you're putting a meaningful
date into it and have to stop and think about that and (b) easy quick
reference looking back through the web-based CVS browser as to the
dates of the earlier releases.
But neither of those are particularly important. Good luck in shifting
the tag!
> I still think it is a good idea to include the date of releases in the
> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
> what do you think? Or is there any other way of telling from CVS on
> what date the tag was created?
I don't know but I remember that someone (Glynn?) suggested to NOT
include the date so that it wasn't done any more.
>>> I still think it is a good idea to include the date of releases in the
>>> tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
>>> what do you think? Or is there any other way of telling from CVS on
>>> what date the tag was created?
>> I don't know but I remember that someone (Glynn?) suggested to NOT
>> include the
>> date so that it wasn't done any more.
>
> Well that's fine then if it has been discussed - I guess I just missed
> that when it happened but there were I'm sure good reasons for it
> then. FWIW my reasons for keeping with the old-style tags would be (a)
> less likely to create a tag by accident as you're putting a meaningful
> date into it and have to stop and think about that and (b) easy quick
> reference looking back through the web-based CVS browser as to the
> dates of the earlier releases.
>
> But neither of those are particularly important. Good luck in shifting
> the tag!
I would suggest to release 6.2.2 officially the next days if nobody
objects.
Hamish:
I found a glitch with v.in.gpsbabel on the Mac which I'd like to fix
before release.
done.
Paul:
As I noted before (..) Grass 6.2.2 seems to already be tagged (as
grass_6_2_2) in CVS.
..
I still think it is a good idea to include the date of releases in the
tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
I agree, it reduces confusion about a CVS tag being a conceptual alias
to a timestamp, as opposed to a separate working CVS branch line.
"grass_x_y_z" by itself is easily confused with a release branch line.
"release_YYYYMMDD_grass_x_y_z" (or "YYYYMMDD_grass_x_y_z", or some other
combination) sorts well.
nb. "release" and "grass" may be redundant noise in the tag name
I still think it is a good idea to include the date of releases in the
tag name, less confusion that way, e.g. release_20070702_grass_6_2_2 -
what do you think? Or is there any other way of telling from CVS on
what date the tag was created?
I don't know but I remember that someone (Glynn?) suggested to NOT
include the date so that it wasn't done any more.
I don't have any recollection of that.
Ok.
Since everybody is happy, we'll re-introduce the date into the tag.
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
during the testing period of 6.2.2-RC1 we got the following
issues fixed:
...
* Czech translation updated (Jachym Cepicky)
What about the other languages? Will they be included in the new release
and packages?
Carlos
Carlos,
would be great to merge back. But I tried once and actually *lost*
many messages. So, after a try one must check if this doesn't
reduce the translations in 6.2.x.
I can send you a script "po_merge.sh" which does it for all 3 files
automatically The script will ask you for the country code and then
it uses "msgmerge". The script is just a few lines.
during the testing period of 6.2.2-RC1 we got the following
issues fixed:
...
* Czech translation updated (Jachym Cepicky)
What about the other languages? Will they be included in the new release and packages?
Carlos
Carlos,
would be great to merge back. But I tried once and actually *lost*
many messages. So, after a try one must check if this doesn't
reduce the translations in 6.2.x.
I can send you a script "po_merge.sh" which does it for all 3 files
automatically The script will ask you for the country code and then
it uses "msgmerge". The script is just a few lines.
I already had the script. I've done a test with es.po files and this is the result:
libs: same total and more fuzzy, so discarded.
mods and tcl: total amount of messages raises from 3910 and 871 to 4775 and 1148 respectively. Are all these new messages useful in 6.2.2 or I shall look only to the variation in fuzzy and untranslated? Shall I make pot & make update-po after running the script?
As you can see, many doubts.
Regards
Carlos
during the testing period of 6.2.2-RC1 we got the following
issues fixed:
...
* Czech translation updated (Jachym Cepicky)
What about the other languages? Will they be included in the new
release and packages?
Carlos
Carlos,
would be great to merge back. But I tried once and actually *lost*
many messages. So, after a try one must check if this doesn't
reduce the translations in 6.2.x.
I can send you a script "po_merge.sh" which does it for all 3 files
automatically The script will ask you for the country code and then
it uses "msgmerge". The script is just a few lines.
I already had the script. I've done a test with es.po files and this
is the result:
libs: same total and more fuzzy, so discarded.
mods and tcl: total amount of messages raises from 3910 and 871 to
4775 and 1148 respectively. Are all these new messages useful in 6.2.2
or I shall look only to the variation in fuzzy and untranslated? Shall
I make pot & make update-po after running the script?
As you can see, many doubts.
I think that only "good" messages count (so, translated, non-fuzzy) and the
rest isn't important. If you observe a growing number of correctly
translated messages,
then I suggest to submit to 6.2.cvs.
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied
release it mostly unchanged as 6.2.2 final in the next 2 weeks.
aka
any more outstanding issues that are reasonably expected to be fixed?
I think it is late in the game to start thinking about backporting
translations; iff there is a chance of regressions (?).
(Markus, does your pull-in script only add in new untranslated messages,
vs wholesale replacement of the .po files based on some a>b test? I
worry a bit if the entire file is replaced based on a a>b basis)
proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied
release it mostly unchanged as 6.2.2 final in the next 2 weeks.
aka
any more outstanding issues that are reasonably expected to be fixed?
Tag, but please do NOT release 6.2.2 until I get a reply on the
directory permission/security issue I sent to the list over the weekend.
This is a show-stopper until explained or fixed, IMHO. I'm sure you'll
all agree when user X does 'rm -rf *' on your working dir.
proposal: tag 6.2.2rc2 circa now, and if no more major changes are applied
release it mostly unchanged as 6.2.2 final in the next 2 weeks.
aka
any more outstanding issues that are reasonably expected to be fixed?
The v.in.gns patch needs to be applied I think.
And my todays v.db.addtable bugfix needs a test
I think it is late in the game to start thinking about backporting
translations; iff there is a chance of regressions (?).
(Markus, does your pull-in script only add in new untranslated messages,
vs wholesale replacement of the .po files based on some a>b test? I
worry a bit if the entire file is replaced based on a a>b basis)
The script only runs msgmerge in a convenient way, so it is up to gettext.
AFAICT, we're ready to go.
Yes, almost.
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
I think it is late in the game to start thinking about backporting
translations; iff there is a chance of regressions (?).
(Markus, does your pull-in script only add in new untranslated messages,
vs wholesale replacement of the .po files based on some a>b test? I
worry a bit if the entire file is replaced based on a a>b basis)
Last Friday I applied Markus script to all languages po files and sent to cvs (releasebranch_6_2 grass6) all those with increased number of translated messages, so it's supposed current translations are backported. As it's the first time I work with this branch, could anyone check I sent them to the right place?
Regards
Carlos
