[GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT

[GRASS GIS]

#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
-----------------------------+----------------------------------------------
 Reporter:  hamish           |       Owner:  grass-dev@…              
     Type:  defect           |      Status:  new                      
 Priority:  blocker          |   Milestone:  6.4.3                    
Component:  wxGUI            |     Version:  6.4.3 RCs                
 Keywords:  location wizard  |    Platform:  Unspecified              
      Cpu:  x86-64           |  
-----------------------------+----------------------------------------------

Comment(by cmbarton):

 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.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1889#comment:21>
GRASS GIS <http://grass.osgeo.org>