[GRASS-dev] GRASS at GForge first steps

GRASS GIS GRASS GIS developer
1

Hi,

Thanks to Sascha Wilde the problem I had with rights assignement at
GForge is gone. It seems it was a user (my) error.

Before new GRASS tracker is announced for users, I'm kindly asking
developers to have a look at what I have done and let me know if there
is something that needs a change or fix.

Under GRASS GForge project [4] I have set up two trackers for GRASS:
issues [1] and patches [2].

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information. I
can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

Patches tracker is for storing and managing the patches candidates
(both code and docs). Currently, they are often sent to dev list. If
they are not reacted upon quickly, or too intrusive to be applied right
away but valuable for future developmement, they happen to be
forgotten. The tracker might help us to manage them in a convenient
way. Jachym volunteered to maintain the code patches submitted. Thanks
Jachym! Is there somebody willing to take care of docs submitted?

Trackers are available for public view, but in order to be able to
post (including creating a new report), you must setup your account at
GForge first [3]. This is to avoid http spam. All the trackers' posts
are automatically forwarded to grass-dev list currently.

If you want to be able to modify the contents of Trackers, you should
request to join the GRASS project at GForge as developer [5].

GForge provides many functionalities. AFAIK, it was aggreed that we are
currently going to use only the Trackers, as all the other
functionalities are implemented in the current GRASS infrastructure
(besides surveys, which I discuss later in this mail). Thus, although
there are various project member Roles possible to define, IMHO we
should only use 3: admin, user and developer:

1. Admin is in charge of accepting requests to join the project and
configuring the GRASS project at GForge. Currently I'm the only admin.
We need 2 (3?), in case I'm not available. Candidates?

2. Developer can do most of the things that admin can. Only that he
doesn't have his duties and he can't remove the whole project,
add/modify/delete trackers. He also can't delete a ticket permanently -
only the admin can. I think such restrictions are sane - getting
familiar with GForge options takes some time, and we don't want
accdental corruptions. Eg. I happened to remove a tracker by accident
when learning GForge. And I'm definitely not an expert yet.

3. User. He can open new tickets in the trackers and participate it
surveys (Admin and developer can too, of course).

Talking of surveys - Jachym suggested using this nice GForge feature.
Any GRASS project member at GForge can vote on the survey. Admin can
access the survey results, and create new ones. I was wondering if
GRASS folks find it usefull. Thus, I have created a survey for that :slight_smile:
[7]. Opinions? The possible problem I see is that only admin can access
the survey results :(, and there is no way to change this (CCing
Bernhard if he has an idea). You can see an example results in the
picture attached (I accidently voted twice - as admin and as a testing
user).

GForge manuals are here: [6].

[1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse
[2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse
[3]http://wald.intevation.org/account/register.php
[4]http://wald.intevation.org/projects/grass/
[5]http://wald.intevation.org/project/request.php?group_id=21
[6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1

Maciek

(attachments)

survey.png

2

Hi Maciek,

2006/11/4, Maciej Sieczka <tutey@o2.pl>:

[snip]

Patches tracker is for storing and managing the patches candidates
(both code and docs). Currently, they are often sent to dev list. If
they are not reacted upon quickly, or too intrusive to be applied right
away but valuable for future developmement, they happen to be
forgotten. The tracker might help us to manage them in a convenient
way. Jachym volunteered to maintain the code patches submitted. Thanks
Jachym! Is there somebody willing to take care of docs submitted?

I can do it (not sure whether I am the right person for managing docs...)

[snip]

GForge provides many functionalities. AFAIK, it was aggreed that we are
currently going to use only the Trackers, as all the other
functionalities are implemented in the current GRASS infrastructure
(besides surveys, which I discuss later in this mail). Thus, although
there are various project member Roles possible to define, IMHO we
should only use 3: admin, user and developer:

1. Admin is in charge of accepting requests to join the project and
configuring the GRASS project at GForge. Currently I'm the only admin.
We need 2 (3?), in case I'm not available. Candidates?

+1 (if needed, BUT no experience with GForge)

2. Developer can do most of the things that admin can. Only that he
doesn't have his duties and he can't remove the whole project,
add/modify/delete trackers. He also can't delete a ticket permanently -
only the admin can. I think such restrictions are sane - getting
familiar with GForge options takes some time, and we don't want
accdental corruptions. Eg. I happened to remove a tracker by accident
when learning GForge. And I'm definitely not an expert yet.

3. User. He can open new tickets in the trackers and participate it
surveys (Admin and developer can too, of course).

Talking of surveys - Jachym suggested using this nice GForge feature.
Any GRASS project member at GForge can vote on the survey. Admin can
access the survey results, and create new ones. I was wondering if
GRASS folks find it usefull. Thus, I have created a survey for that :slight_smile:
[7]. Opinions? The possible problem I see is that only admin can access
the survey results :(, and there is no way to change this (CCing
Bernhard if he has an idea). You can see an example results in the
picture attached (I accidently voted twice - as admin and as a testing
user).

GForge manuals are here: [6].

[1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse
[2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse
[3]http://wald.intevation.org/account/register.php
[4]http://wald.intevation.org/projects/grass/
[5]http://wald.intevation.org/project/request.php?group_id=21
[6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1

Best regards, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

Maciej Sieczka wrote:

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information.
I can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

why not a separate tracker for bugs, wishes, docs, website, install
probs... then people who want to work on fixing docs but not C code can
quickly see that there are 3 open doc bugs they can work on, instead of
spending a lot of time going through 56 open bugs of all types to find
any doc ones.

?? if separate, can issues be moved between trackers (wish filed as a
bug)

how is a defect different than a bug?

While we commision the new tracker(s), I would like to see the old bug
tracker kept alive for some time, even if less used.

Talking of surveys

I think this is a nice feature, perhaps more interesting than useful,
but still good.

Hamish

4

Hamish wrote:

Maciej Sieczka wrote:

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information.
I can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

why not a separate tracker for bugs, wishes, docs, website, install
probs... then people who want to work on fixing docs but not C code can
quickly see that there are 3 open doc bugs they can work on, instead of
spending a lot of time going through 56 open bugs of all types to find
any doc ones.

Good point. I'll separate them. Maybe today. If not - next days.

?? if separate, can issues be moved between trackers (wish filed as a
bug)

Yes, they can.

how is a defect different than a bug?

Call it "bad feature". I sometimes was told that I was reporting
something as a bug while actually it was a feature. Although that
feature was not good - eg. the current memory overhaed in GRASS vectors
and dbf driver. Do you want a separate tracker for defects and bugs
(I'd prefer them kept in one tracker, so that defects are as attended
as bugs are).

While we commision the new tracker(s), I would like to see the old bug
tracker kept alive for some time, even if less used.

This was already agreed on the dev list IIRC. Old GRASS RT is going to
be used for the old bugs, since nobody seems to be able to transfer
them to GForge. New bugs will be reported at GForge - not yet though,
GRASS' GForge is still at development stage :slight_smile: - give some more time.

Talking of surveys

I think this is a nice feature, perhaps more interesting than useful,
but still good.

Maciek

5

Maciej Sieczka wrote:

Hamish wrote:

Maciej Sieczka wrote:

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information.
I can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

why not a separate tracker for bugs, wishes, docs, website, install
probs... then people who want to work on fixing docs but not C code can
quickly see that there are 3 open doc bugs they can work on, instead of
spending a lot of time going through 56 open bugs of all types to find
any doc ones.

Good point. I'll separate them. Maybe today. If not - next days.

Hamish,

I forgot there is a "Build query" feature for each tracker. Every
project member can create any number of queries suiting his needs. You
can create a query for open bugs, docs, etc. Wouldn't that be good
enough, instead of separate trackers?

You can create a few testing tickets and see how it works for you (I
have disabled forwarding GRASS project GForge traffic to the dev list
until we have it working properly, so don't hesitate). Same for patches
tracker.

Maciek

6

On Saturday 04 November 2006 16:17, Maciej Sieczka wrote:

Trackers are available for public view, but in order to be able to
post (including creating a new report), you must setup your account at
GForge first [3]. This is to avoid http spam. All the trackers' posts
are automatically forwarded to grass-dev list currently.

If you want to be able to modify the contents of Trackers, you should
request to join the GRASS project at GForge as developer [5].

I think it might be useful to keep the ability for people that
are not registered with the wald GRASS project to submit bugs
and also manupliate their owns. (I currently do not know how
to model this on wald, but this is stating the goal.)

1. Admin is in charge of accepting requests to join the project and
configuring the GRASS project at GForge. Currently I'm the only admin.
We need 2 (3?), in case I'm not available. Candidates?

I am willing to help out as backup.
Our system administrators at Intevation of course also have
higher powers over wald, for emergencies.

Talking of surveys

The possible problem I see is that only admin can access
the survey results :(, and there is no way to change this (CCing
Bernhard if he has an idea).

Not directly out of the top of my head.
You can file this as a wish with wald.

Bernhard

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

7

On Sunday 05 November 2006 10:57, Maciej Sieczka wrote:

> how is a defect different than a bug?

Call it "bad feature". I sometimes was told that I was reporting
something as a bug while actually it was a feature. Although that
feature was not good - eg. the current memory overhaed in GRASS vectors
and dbf driver. Do you want a separate tracker for defects and bugs
(I'd prefer them kept in one tracker, so that defects are as attended
as bugs are).

I think a bug is also too general as a term. Zeller 2006 explains
this and uses "defect".
See http://www.whyprogramsfail.com/

> While we commision the new tracker(s), I would like to see the old bug
> tracker kept alive for some time, even if less used.

This was already agreed on the dev list IIRC. Old GRASS RT is going to
be used for the old bugs, since nobody seems to be able to transfer
them to GForge.

It is a matter of effort and time, but not technically impossible. :slight_smile:

New bugs will be reported at GForge - not yet though,
GRASS' GForge is still at development stage :slight_smile: - give some more time.

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

8

Hallo,

great work, Maciek. One question from my side:

On Sat, Nov 04, 2006 at 04:17:03PM +0100, Maciej Sieczka wrote:

Patches tracker is for storing and managing the patches candidates
(both code and docs). Currently, they are often sent to dev list. If
they are not reacted upon quickly, or too intrusive to be applied right
away but valuable for future developmement, they happen to be
forgotten. The tracker might help us to manage them in a convenient
way. Jachym volunteered to maintain the code patches submitted. Thanks
Jachym! Is there somebody willing to take care of docs submitted?

I will do it (try to do it). What exactly am I supposed to do? My
imaginatio is following:
    
    - Someone will submit some patch to wald
    - I (or someone else) will examine the patch, look if it does what
      it is supposed to do and paste my comment about this patch to
      grass-dev list
    - If it will be only small correction, I'll apply the patch to CVS
      immediately
    - If it will be bigger change and nobody will complain in grass-dev
        within a week or so, I'll commit the change too.

Anything else? Or do I understand this task completely wrong?

Thanks

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

9

Hamish:

> > how is a defect different than a bug?

Maciej:

> Call it "bad feature". I sometimes was told that I was reporting
> something as a bug while actually it was a feature. Although that
> feature was not good - eg. the current memory overhaed in GRASS
> vectors and dbf driver. Do you want a separate tracker for defects
> and bugs (I'd prefer them kept in one tracker, so that defects are
> as attended as bugs are).

Bernhard:

I think a bug is also too general as a term. Zeller 2006 explains
this and uses "defect".
See http://www.whyprogramsfail.com/

FWIW, Debian has a "wontfix" tag for bugs.

I think to say all features which do something other than what a user
might expect at first are "misfeatures" or a "defect" is wrong. Some are
real defects/shortcomings, but others are counter-intuitive yet correct
design choices.

(shrug)

Hamish

10

Jachym Cepicky wrote:

I will do it (try to do it). What exactly am I supposed to do? My
imaginatio is following:
    
    - Someone will submit some patch to wald
    - I (or someone else) will examine the patch, look if it does what
      it is supposed to do and paste my comment about this patch to
      grass-dev list
    - If it will be only small correction, I'll apply the patch to CVS
      immediately
    - If it will be bigger change and nobody will complain in
    grass-dev
        within a week or so, I'll commit the change too.

Anything else? Or do I understand this task completely wrong?

I prefer to be more conservative, adding code to CVS should be opt-in
not opt-out. A patch needs a developer-supporter to give it the ok,
versus falling into CVS by default. (see PSC code accountability
requirements) I don't think it is bad that many patches could collect
there, or at least that is better than bad patches falling into CVS by
default because devels were busy that week.

10c, (NZ just abolished the 5c coin, and abolished the 1,2c coins in the
early 90s; but after the exchange rate the 10c is a lot less than it
sounds :wink:

Hamish

11

On Tue, Nov 07, 2006 at 06:11:08PM +1300, Hamish wrote:

Jachym Cepicky wrote:
>
> I will do it (try to do it). What exactly am I supposed to do? My
> imaginatio is following:
>
> - Someone will submit some patch to wald
> - I (or someone else) will examine the patch, look if it does what
> it is supposed to do and paste my comment about this patch to
> grass-dev list
> - If it will be only small correction, I'll apply the patch to CVS
> immediately
> - If it will be bigger change and nobody will complain in
> grass-dev
> within a week or so, I'll commit the change too.
>
> Anything else? Or do I understand this task completely wrong?

I prefer to be more conservative, adding code to CVS should be opt-in
not opt-out. A patch needs a developer-supporter to give it the ok,
versus falling into CVS by default.

So if I understand it right, the last point in my decision tree will
sound:
    - If it will be bigger change and there will be no consensus
      agreement, I'll leave the patch uncommited.

Is it right?

Jachym

(see PSC code accountability
requirements) I don't think it is bad that many patches could collect
there, or at least that is better than bad patches falling into CVS by
default because devels were busy that week.

10c, (NZ just abolished the 5c coin, and abolished the 1,2c coins in the
early 90s; but after the exchange rate the 10c is a lot less than it
sounds :wink:

Hamish

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

12

On Tuesday 07 November 2006 05:57, Hamish wrote:

Hamish:
> > > how is a defect different than a bug?

Maciej:
> > Call it "bad feature". I sometimes was told that I was reporting
> > something as a bug while actually it was a feature. Although that
> > feature was not good - eg. the current memory overhaed in GRASS
> > vectors and dbf driver. Do you want a separate tracker for defects
> > and bugs (I'd prefer them kept in one tracker, so that defects are
> > as attended as bugs are).

Bernhard:
> I think a bug is also too general as a term. Zeller 2006 explains
> this and uses "defect".
> See http://www.whyprogramsfail.com/

FWIW, Debian has a "wontfix" tag for bugs.

Often I have seen this used to turn down people.

I think to say all features which do something other than what a user
might expect at first are "misfeatures" or a "defect" is wrong. Some are
real defects/shortcomings, but others are counter-intuitive yet correct
design choices.

I follow Zeller pretty much here, but his writing goes into a lot more detail
of course. He just says that "bug" is quite general.
To me something that is "counter-intuitive" can be an issue
and a usuability problem.
Speaking of an "issue report" or "problem report" is a good general term,
because this does not judge to early what kind of problem the user or
developer has.

Bernhard

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

13

Jachym Cepicky wrote:

On Tue, Nov 07, 2006 at 06:11:08PM +1300, Hamish wrote:

Jachym Cepicky wrote:

I will do it (try to do it). What exactly am I supposed to do? My
imaginatio is following:
    
    - Someone will submit some patch to wald
    - I (or someone else) will examine the patch, look if it does what
      it is supposed to do and paste my comment about this patch to
      grass-dev list
    - If it will be only small correction, I'll apply the patch to CVS
      immediately
    - If it will be bigger change and nobody will complain in
    grass-dev
        within a week or so, I'll commit the change too.

Anything else? Or do I understand this task completely wrong?

I prefer to be more conservative, adding code to CVS should be opt-in
not opt-out. A patch needs a developer-supporter to give it the ok,
versus falling into CVS by default.

So if I understand it right, the last point in my decision tree will
sound:
    - If it will be bigger change and there will be no consensus
      agreement, I'll leave the patch uncommited.

Is it right?

Jachym,

I think that's OK and I agree with Hamish. We'll adapt as the situation
developes. In general I think the patches maintainer should a kind of
an interface between the patch submitter and the GRASS developers.
Coordinating the way the patch is dealt with, IOW. Not the ultimate
patch master ;).

Maciek

14

Bernhard Reiter wrote:

On Saturday 04 November 2006 16:17, Maciej Sieczka wrote:

Trackers are available for public view, but in order to be able to
post (including creating a new report), you must setup your account at
GForge first [3]. This is to avoid http spam. All the trackers' posts
are automatically forwarded to grass-dev list currently.

If you want to be able to modify the contents of Trackers, you should
request to join the GRASS project at GForge as developer [5].

I think it might be useful to keep the ability for people that
are not registered with the wald GRASS project to submit bugs
and also manupliate their owns.

That would be very usefull.

(I currently do not know how
to model this on wald, but this is stating the goal.)

Please keep us informed.

1. Admin is in charge of accepting requests to join the project and
configuring the GRASS project at GForge. Currently I'm the only admin.
We need 2 (3?), in case I'm not available. Candidates?

I am willing to help out as backup.

That's great! Will you join the GRASS project are you going to pull the
strings incognito :)?

Our system administrators at Intevation of course also have
higher powers over wald, for emergencies.

Talking of surveys
The possible problem I see is that only admin can access
the survey results :(, and there is no way to change this (CCing
Bernhard if he has an idea).

Not directly out of the top of my head.
You can file this as a wish with wald.

Done:
http://wald.intevation.org/tracker/index.php?func=detail&aid=228&group_id=1&atid=162

Thanks,
Maciek

15

On Tuesday 07 November 2006 18:51, Maciej Sieczka wrote:

>> 1. Admin is in charge of accepting requests to join the project and
>> configuring the GRASS project at GForge. Currently I'm the only admin.
>> We need 2 (3?), in case I'm not available. Candidates?
>
> I am willing to help out as backup.

That's great! Will you join the GRASS project are you going to pull the
strings incognito :)?

Feel free to join me as administrator,
my user id is "bernhard".

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

16

Maciej Sieczka wrote:

Maciej Sieczka wrote:

Hamish wrote:

Maciej Sieczka wrote:

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information.
I can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

why not a separate tracker for bugs, wishes, docs, website, install
probs... then people who want to work on fixing docs but not C code can
quickly see that there are 3 open doc bugs they can work on, instead of
spending a lot of time going through 56 open bugs of all types to find
any doc ones.

Good point. I'll separate them. Maybe today. If not - next days.

Hamish,

I forgot there is a "Build query" feature for each tracker.

In a discussion offlist I have agreed with Hamish that having separate
trackers for code, doc and web issues is a good thing - improving the
chance that a volunteer will easily find an issue to work on that suits
his skills and attitude. Moreover, keeping them separate will make it
easier to assign a dedicated maintainer to each tracker.

Note that tickets can be moved between the trackers using the "Data
Type" field, but only by the tracker admins; this forced me to enable
admin access to trackers for all "developers". This is necessary eg. if
a code bug turns out to be a doc wish :).

Please everybody take a look at trackers at the GRASS GForge and let me
know what you think, http://wald.intevation.org.

Berhard,

Should I fill in a wish to enable Techs to move the tickets between the
trackers? Or maybe you can fix it? Currently there is some risk that
somebody can accidently screw things.

Maciek

17

On Sunday 12 November 2006 19:27, Maciej Sieczka wrote:

Should I fill in a wish to enable Techs to move the tickets between the
trackers?

Yes, please.

Or maybe you can fix it?

No, not directly.

Currently there is some risk that
somebody can accidently screw things.

18

Hamish wrote:

Maciej wrote:

Hamish wrote:

- GRASS component: need something that says "system wide".
   current options apply only to modules, not to libs, build system,

Sounds OK, only I have not enough expertise. What tags do you exactly
propose?

probably better to ask others on the grass-dev list. I'm not sure.

Dear Developers,

What "GRASS components" tags would you propose to be added in the "code
issues tracker
http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse ?
(click "Submit New" and see the tags in the "GRASS component:" field)

What libraries? Other stuff? I don't know GRASS good enough and I'm not
a programmer.

Thanks!

Maciek

19

Maciej Sieczka wrote:

Dear Developers,

What "GRASS components" tags would you propose to be added in the "code
issues tracker
http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse ?
(click "Submit New" and see the tags in the "GRASS component:" field)

What libraries? Other stuff? I don't know GRASS good enough and I'm not
a programmer.

How about adding a "module/library" select box tag, which would have 2
choices: "module" and "library". Such tag, in conjuction with "GRASS
component", would indicate whether the nature of a given issue lies in
a module, or in some underlying library.

Eg.:

"GRASS component"=raster and "module/library"=module
means the issue is in some raster library

"GRASS component"=vector and "module/library"=library
means a bug in some vector library

This should let us have the module and library issues somewhat
separated in the tracker, while not overloading the tracker with many
specific library names to choose from, when reporting an issue/managing it.

?

Maciek

20

Maciej Sieczka wrote:

"GRASS component"=raster and "module/library"=module
means the issue is in some raster library

I should have written:

"means the issue is in some raster *module*"

"GRASS component"=vector and "module/library"=library
means a bug in some vector library

This one's OK.

Sorry for the confussion. Too much resting on weekend ;).

Maciek