[GRASS-dev] planning grass 7.0.0beta4

[Pietro]

Hi Vaclav,

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>
> 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