Hi Vaclav, On Tue, Oct 28, 2014 at 4:09 AM, Vaclav Petras <[email protected]> wrote: > On Sun, Oct 26, 2014 at 7:22 AM, Martin Landa <[email protected]> > wrote: >> it's long time ago when GRASS 7.0.0beta3 has been published (more then >> two months ago). I would suggest to publish beta4, what do you think? >> Is there any blocker or something which should be finished (e.g. >> g.list/g.remove backports)? > > I was working on #2326 a little bit last week but I'm far from finishing. I > have a first implementation of raise in run/write/read command functions and > some changes make GUI start again. Nothing done on the rest of the code.
Thanks for that! > A branch would be helpful for this, by the way. yes, I also think that a branch would be useful... Do all the changes that we need to do in one big commit it seems unfeasible, and without a branch it is quite difficult to share and work as a team... So have some branches with a very precise scope like: #2326 or make GRASS compatible with python3 that can be reach in a short time (2 weeks/ 1 month), should allow us to broke GRASS without the fear of bothering other users/developers until we reach a pretty stable code that can be included to trunk. IMO these branches should be automatically synchronized with trunk and have a responsible to manage/handle the conflict that could raise from the merging process. [OT] I think git/github could make these things easier... > We've been also discussing removing things from __init__.py files. I'm not > sure if we should apply this but we probably should replace the practice > > import grass.script as grass +1 It has always looked weird to me. > by something more reasonable, explicit imports of things or > > import grass.script as gscript > > or > > import grass.script.core as gcore > import grass.script.core as gscore +1 Pietro _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
