[GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
GRASS GIS
trac at osgeo.org
Sun Mar 10 11:58:24 PDT 2013
#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>
More information about the grass-dev
mailing list