[GRASS-dev] planning grass 7.0.0beta4
peter.zamb at gmail.com
Tue Oct 28 00:11:16 PDT 2014
On Tue, Oct 28, 2014 at 4:09 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> On Sun, Oct 26, 2014 at 7:22 AM, Martin Landa <landa.martin at gmail.com>
>> 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
It has always looked weird to me.
> by something more reasonable, explicit imports of things or
> import grass.script as gscript
> import grass.script.core as gcore
> import grass.script.core as gscore
More information about the grass-dev