[GRASS5] GRASS release policy needed

Hi developers and power users,

in June I made a try to release GRASS 6.0.1:
http://grass.itc.it/pipermail/grass5/2005-June/018798.html

It turned out to be more complicated:
http://grass.itc.it/pipermail/grass5/2005-July/thread.html#18820

Some observations

1. the bugtracker is full of (old) bugs
2. some of the bugs are known for years, but nobody is interested/able
   to fix them
3. some of the well know bugs have hold the intended release, but see 2.
4. While the release procedure is well documented in doc/howto_release.txt
   it is rather unclear when and under which conditions to release.

Opinion

We should implement a better release management.
I think that a long standing bug (see 2. above) should not hold a release
if noone offers to fix it in *reasonable* time (e.g., range of days).
Currently a couple of important fixes are still officially unpublished
such as (nearly randomly selected):

...
2005-05-10 11:58 radim
  * db/drivers/dbf/dbfexe.c: set columns to null before insert

2005-05-10 10:23 hamish
  * include/gisdefs.h: G_is_little_endian() was missing [merge from
    HEAD]

2005-04-29 11:37 radim
  * lib/db/: dbmi_client/start.c, dbmi_driver/driver.c: set correctly
    GISRC mode

2005-04-29 10:12 radim
  * db/drivers/dbf/dbfexe.c: free statement <- the famous LIDAR fix

2005-04-20 18:04 radim
  * lib/vector/Vlib/map.c: use original key also for index

2005-04-20 17:56 radim
  * lib/vector/Vlib/map.c: use original key

2005-03-31 18:48 radim
  * lib/vector/Vlib/intersect.c: segment and line intersection fix

2005-03-30 15:24 markus
  * lib/proj/... fix ETRS89 datum problems

2005-03-30 10:03 markus
  * raster/r.proj/: bilinear.c, bordwalk.c, cubic.c, main.c,
    nearest.c: Morten Hulden...

2005-03-18 11:49 markus
  * lib/gis/make_loc.c: meter -> meters

2005-03-16 17:47 radim
  * lib/vector/Vlib/bridges.c: endless loop fix on zero length
    boundaries

2005-03-14 09:05 radim
  * vector/v.db.connect/main.c: field info fix
...

Currently we have 132 unreleased fixes in 6.0-CVS. IMHO a pity to not
make them available officially to the user community.

Just my 0.02 Eurocent

Markus

From: "Markus Neteler" <neteler@itc.it>

Hi developers and power users,

in June I made a try to release GRASS 6.0.1:
http://grass.itc.it/pipermail/grass5/2005-June/018798.html

It turned out to be more complicated:
http://grass.itc.it/pipermail/grass5/2005-July/thread.html#18820

Some observations

1. the bugtracker is full of (old) bugs

As I promised this I will try to take care of regarding 6.x bugs. Maybe 5.4+
as well. Sooner or later.

2. some of the bugs are known for years, but nobody is interested/able
  to fix them
3. some of the well know bugs have hold the intended release, but see 2.

For a regular user the indicator of Grass stability and progress is not the
changelog, CVS content, all the Grass lists discussions and plans etc. The
regular user, beginner or Grass wannabie is mainly concerned with:

1. What functionality has been added when compared to previous release.
2. Have the bugs and doc insufficiencies/errors present in previous release
been fixed.

According to point 1 Grass is doing very good. User can see and feel that
Grass improves.

According to point 2 not really so good. As we all know, in spite of the
amount of fixes in the changelog, bugtracker is full of old bugs, sometimes
also bugs which actually got fixed, but where not closed by those who fixed.
Lack of comitment and coordination here.

Propably silly question, but what do I care - how do you think Grass could
obtain a developer dedicated only to fixing things? Not improving a lot, not
developing new wonders but "simply" cleaning up the code whenever a bug is reported, keeping in touch with reporters so they won't feel ignored, keeping docs actual, extending them whenever explanation is not sufficient, adding links to selected best, actual external sources of information on the topic? If not capable of doing the work alone, he would be in charge of gathering support, actively looking for relevant information and encouraging appropriate people to take care of/help with the issue, instead of waiting until somebody volunteers. Or at least he could recognize what are the chances that people capable of fixing the bug would do it and when. PR manager/developer?

If Grass would have someone like this, it's image would really improve in
the eyes of regular (naive?) users. "Look, any bug I report gets fixed
within a month. Kill me, them Grass coders are reliable. There is one
pending for ages but at least they never ignored my input." instead of
"Darn, I reported that bug half a year ago and nothing. They haven't even
replied.".

I guess that's how Grass users without insight into the Grass developement
more/less think. That's what I soemtimes thought until I started to read
Grass, Gdal, Proj, Freegis etc lists, building Grass and friends from
source, trying to help others with their problems with Grass. All that made
me realise all is not that simple and that I can't expect and demand (hard
to resist...), that I need to contribute somehow also, that developers are
giving their time with little or no direct financial reward, that it's hard
for them mantain somebody else's code. But regular Grass users, and, more
important, most future Grass users, are folks who install an rpm and join
the list when they have a problem. Or they fill in a bugtracker entry and
expect the bug to fixed - just because they report it.

I guess first reaction of most Grass developers would be "MOST of bugs are
getting fixed". Yes, most. But no matter how fast could you BMW be, how
shiny, modern, cool, how little gas it needs and how cheap (OK, not BMW) if
one tyre is flat. And even if the bug considered is not that serious as a
flat tyre, it cannot be neglected - becauase of the psychological aspect and
the publicity. Grass is not only as good as it is. It is rather as good as
it is appears/is known to be. When more people talk about Grass in bad
words, Grass is bad. And more people are more likely to talk bad about
Grass - because the majority of those who try Grass in future will be
complete ignorants, since Grass and friends are being shipped in debs and
rpms on a regular basis by all major distros. Plus Windows installers
comming soon (?), alert red. What's more, such people who install Grass
once, have their first problem (bugs will be always, even I know this) and
quit after a month of waiting for a remedy are the worse ones for Grass's
publicity, because it will be impossible to change their mind, since they
had quit. I can see there is a recognition for a need of support for
newbies - same and same questions are answered patiently by developers on
the list often, admire. Yet there is no such recognition in terms of bugs I
think. Bugs are neglected to often.

What's more, even if the bug gets fixed, the average bug reporter can't
benefit from that when he is not informed, which happens. And he has to at
least know it is fixed, becaue he won't be able to check for himself from
CVS. He will wait for next rpm/deb/exe instead. So release often,
absolutely. And inform always.

Reassuming, from my ex-naive, regular user point of view, any bugs reported
should be high on priority list. I'm going to help with that to the extent
I'm capable of - cleanup the bugtracker, help to manage it in future as time
allows. Yet a committed and really knowledgable general "fixing coordinator"
is highly required IMHO. But, who am I fooling - that would be a full time
job...

I hope my naiveness will be forgiven to me - anyway I compared Grass to BMW!

My 0,01 PLN.

Maciek

P.S.
I'm not writing this all to hold off 6.0.1 release, I hope it's clear. I
never meant it if that's your impression. Please release as you recon it's
best. I just find this an ocassion to rise the issue of bugs in Grass.

I'm not real savvy on this. But, judging from a few other open source
programs, it seems that perhaps a more efficient way to do this is:

Announce a new release (you did that, of course).

Specify a limited bug fix PERIOD (1 month?)

Fix all the remaining bugs possible in that period AND try to get the bug
tracker up to date for that period.

Freeze the code (Inkscape has a brief chill period prior to hard freeze
where people can finish bug fixes but not start new ones, or something along
that line).

Release.

In other words, do it by time period rather than by getting a set of bugs
fixed. At the moment, it seems we are doing some of both and enforcing
either is difficult.

My 1 cent worth

Michael

On 7/21/05 12:44 PM, "Maciek Sieczka" <werchowyna@epf.pl> wrote:

From: "Markus Neteler" <neteler@itc.it>

Hi developers and power users,

in June I made a try to release GRASS 6.0.1:
http://grass.itc.it/pipermail/grass5/2005-June/018798.html

It turned out to be more complicated:
http://grass.itc.it/pipermail/grass5/2005-July/thread.html#18820

Some observations

1. the bugtracker is full of (old) bugs

As I promised this I will try to take care of regarding 6.x bugs. Maybe 5.4+
as well. Sooner or later.

2. some of the bugs are known for years, but nobody is interested/able
  to fix them
3. some of the well know bugs have hold the intended release, but see 2.

For a regular user the indicator of Grass stability and progress is not the
changelog, CVS content, all the Grass lists discussions and plans etc. The
regular user, beginner or Grass wannabie is mainly concerned with:

1. What functionality has been added when compared to previous release.
2. Have the bugs and doc insufficiencies/errors present in previous release
been fixed.

According to point 1 Grass is doing very good. User can see and feel that
Grass improves.

According to point 2 not really so good. As we all know, in spite of the
amount of fixes in the changelog, bugtracker is full of old bugs, sometimes
also bugs which actually got fixed, but where not closed by those who fixed.
Lack of comitment and coordination here.

Propably silly question, but what do I care - how do you think Grass could
obtain a developer dedicated only to fixing things? Not improving a lot, not
developing new wonders but "simply" cleaning up the code whenever a bug is
reported, keeping in touch with reporters so they won't feel ignored,
keeping docs actual, extending them whenever explanation is not sufficient,
adding links to selected best, actual external sources of information on the
topic? If not capable of doing the work alone, he would be in charge of
gathering support, actively looking for relevant information and encouraging
appropriate people to take care of/help with the issue, instead of waiting
until somebody volunteers. Or at least he could recognize what are the
chances that people capable of fixing the bug would do it and when. PR
manager/developer?

If Grass would have someone like this, it's image would really improve in
the eyes of regular (naive?) users. "Look, any bug I report gets fixed
within a month. Kill me, them Grass coders are reliable. There is one
pending for ages but at least they never ignored my input." instead of
"Darn, I reported that bug half a year ago and nothing. They haven't even
replied.".

I guess that's how Grass users without insight into the Grass developement
more/less think. That's what I soemtimes thought until I started to read
Grass, Gdal, Proj, Freegis etc lists, building Grass and friends from
source, trying to help others with their problems with Grass. All that made
me realise all is not that simple and that I can't expect and demand (hard
to resist...), that I need to contribute somehow also, that developers are
giving their time with little or no direct financial reward, that it's hard
for them mantain somebody else's code. But regular Grass users, and, more
important, most future Grass users, are folks who install an rpm and join
the list when they have a problem. Or they fill in a bugtracker entry and
expect the bug to fixed - just because they report it.

I guess first reaction of most Grass developers would be "MOST of bugs are
getting fixed". Yes, most. But no matter how fast could you BMW be, how
shiny, modern, cool, how little gas it needs and how cheap (OK, not BMW) if
one tyre is flat. And even if the bug considered is not that serious as a
flat tyre, it cannot be neglected - becauase of the psychological aspect and
the publicity. Grass is not only as good as it is. It is rather as good as
it is appears/is known to be. When more people talk about Grass in bad
words, Grass is bad. And more people are more likely to talk bad about
Grass - because the majority of those who try Grass in future will be
complete ignorants, since Grass and friends are being shipped in debs and
rpms on a regular basis by all major distros. Plus Windows installers
comming soon (?), alert red. What's more, such people who install Grass
once, have their first problem (bugs will be always, even I know this) and
quit after a month of waiting for a remedy are the worse ones for Grass's
publicity, because it will be impossible to change their mind, since they
had quit. I can see there is a recognition for a need of support for
newbies - same and same questions are answered patiently by developers on
the list often, admire. Yet there is no such recognition in terms of bugs I
think. Bugs are neglected to often.

What's more, even if the bug gets fixed, the average bug reporter can't
benefit from that when he is not informed, which happens. And he has to at
least know it is fixed, becaue he won't be able to check for himself from
CVS. He will wait for next rpm/deb/exe instead. So release often,
absolutely. And inform always.

Reassuming, from my ex-naive, regular user point of view, any bugs reported
should be high on priority list. I'm going to help with that to the extent
I'm capable of - cleanup the bugtracker, help to manage it in future as time
allows. Yet a committed and really knowledgable general "fixing coordinator"
is highly required IMHO. But, who am I fooling - that would be a full time
job...

I hope my naiveness will be forgiven to me - anyway I compared Grass to BMW!

My 0,01 PLN.

Maciek

P.S.
I'm not writing this all to hold off 6.0.1 release, I hope it's clear. I
never meant it if that's your impression. Please release as you recon it's
best. I just find this an ocassion to rise the issue of bugs in Grass.

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

Hello Markus,

On Thu, 21 Jul 2005 14:05:27 +0200 Markus Neteler <neteler@itc.it>
wrote:

Hi developers and power users,

in June I made a try to release GRASS 6.0.1:
http://grass.itc.it/pipermail/grass5/2005-June/018798.html

It turned out to be more complicated:
http://grass.itc.it/pipermail/grass5/2005-July/thread.html#18820

Some observations

1. the bugtracker is full of (old) bugs
2. some of the bugs are known for years, but nobody is interested/able
   to fix them
3. some of the well know bugs have hold the intended release, but see
2. 4. While the release procedure is well documented in
doc/howto_release.txt it is rather unclear when and under which
conditions to release.

Opinion

We should implement a better release management.
I think that a long standing bug (see 2. above) should not hold a
release if noone offers to fix it in *reasonable* time (e.g., range
of days). Currently a couple of important fixes are still officially
unpublished such as (nearly randomly selected):

[...]

Currently we have 132 unreleased fixes in 6.0-CVS. IMHO a pity to not
make them available officially to the user community.

As a non-developers I also strongly vote for smaller release-cycles. As
Markus pointed out there are some pending bugs, but the 132 of resolved
fixes should be published ASAP.
This indicates also activity to other occasualy grass-users imho.

just my 0.02¢

Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

On Thu, Jul 21, 2005 at 11:22:35PM -0700, Michael Barton wrote:

I'm not real savvy on this. But, judging from a few other open source
programs, it seems that perhaps a more efficient way to do this is:

Announce a new release (you did that, of course).

Specify a limited bug fix PERIOD (1 month?)

Did that as well.

Fix all the remaining bugs possible in that period AND try to get the bug
tracker up to date for that period.

More or less impossible (see my other mail from a few minutes ago).

Freeze the code (Inkscape has a brief chill period prior to hard freeze
where people can finish bug fixes but not start new ones, or something along
that line).

Release.

In other words, do it by time period rather than by getting a set of bugs
fixed. At the moment, it seems we are doing some of both and enforcing
either is difficult.

I tried by time period [1], some other developers/power users insisted on
getting a set of bugs fixed. Finally the intended release stalled and
time out error (for me).

Markus

[1] http://grass.itc.it/pipermail/grass5/2005-June/018798.html

My 1 cent worth

Michael

On 7/21/05 12:44 PM, "Maciek Sieczka" <werchowyna@epf.pl> wrote:

> From: "Markus Neteler" <neteler@itc.it>
>
>> Hi developers and power users,
>>
>> in June I made a try to release GRASS 6.0.1:
>> http://grass.itc.it/pipermail/grass5/2005-June/018798.html
>>
>> It turned out to be more complicated:
>> http://grass.itc.it/pipermail/grass5/2005-July/thread.html#18820
>>
>>
>> Some observations
>>
>> 1. the bugtracker is full of (old) bugs
>
> As I promised this I will try to take care of regarding 6.x bugs. Maybe 5.4+
> as well. Sooner or later.
>
>> 2. some of the bugs are known for years, but nobody is interested/able
>> to fix them
>> 3. some of the well know bugs have hold the intended release, but see 2.
>
> For a regular user the indicator of Grass stability and progress is not the
> changelog, CVS content, all the Grass lists discussions and plans etc. The
> regular user, beginner or Grass wannabie is mainly concerned with:
>
> 1. What functionality has been added when compared to previous release.
> 2. Have the bugs and doc insufficiencies/errors present in previous release
> been fixed.
>
> According to point 1 Grass is doing very good. User can see and feel that
> Grass improves.
>
> According to point 2 not really so good. As we all know, in spite of the
> amount of fixes in the changelog, bugtracker is full of old bugs, sometimes
> also bugs which actually got fixed, but where not closed by those who fixed.
> Lack of comitment and coordination here.
>
> Propably silly question, but what do I care - how do you think Grass could
> obtain a developer dedicated only to fixing things? Not improving a lot, not
> developing new wonders but "simply" cleaning up the code whenever a bug is
> reported, keeping in touch with reporters so they won't feel ignored,
> keeping docs actual, extending them whenever explanation is not sufficient,
> adding links to selected best, actual external sources of information on the
> topic? If not capable of doing the work alone, he would be in charge of
> gathering support, actively looking for relevant information and encouraging
> appropriate people to take care of/help with the issue, instead of waiting
> until somebody volunteers. Or at least he could recognize what are the
> chances that people capable of fixing the bug would do it and when. PR
> manager/developer?
>
> If Grass would have someone like this, it's image would really improve in
> the eyes of regular (naive?) users. "Look, any bug I report gets fixed
> within a month. Kill me, them Grass coders are reliable. There is one
> pending for ages but at least they never ignored my input." instead of
> "Darn, I reported that bug half a year ago and nothing. They haven't even
> replied.".
>
> I guess that's how Grass users without insight into the Grass developement
> more/less think. That's what I soemtimes thought until I started to read
> Grass, Gdal, Proj, Freegis etc lists, building Grass and friends from
> source, trying to help others with their problems with Grass. All that made
> me realise all is not that simple and that I can't expect and demand (hard
> to resist...), that I need to contribute somehow also, that developers are
> giving their time with little or no direct financial reward, that it's hard
> for them mantain somebody else's code. But regular Grass users, and, more
> important, most future Grass users, are folks who install an rpm and join
> the list when they have a problem. Or they fill in a bugtracker entry and
> expect the bug to fixed - just because they report it.
>
> I guess first reaction of most Grass developers would be "MOST of bugs are
> getting fixed". Yes, most. But no matter how fast could you BMW be, how
> shiny, modern, cool, how little gas it needs and how cheap (OK, not BMW) if
> one tyre is flat. And even if the bug considered is not that serious as a
> flat tyre, it cannot be neglected - becauase of the psychological aspect and
> the publicity. Grass is not only as good as it is. It is rather as good as
> it is appears/is known to be. When more people talk about Grass in bad
> words, Grass is bad. And more people are more likely to talk bad about
> Grass - because the majority of those who try Grass in future will be
> complete ignorants, since Grass and friends are being shipped in debs and
> rpms on a regular basis by all major distros. Plus Windows installers
> comming soon (?), alert red. What's more, such people who install Grass
> once, have their first problem (bugs will be always, even I know this) and
> quit after a month of waiting for a remedy are the worse ones for Grass's
> publicity, because it will be impossible to change their mind, since they
> had quit. I can see there is a recognition for a need of support for
> newbies - same and same questions are answered patiently by developers on
> the list often, admire. Yet there is no such recognition in terms of bugs I
> think. Bugs are neglected to often.
>
> What's more, even if the bug gets fixed, the average bug reporter can't
> benefit from that when he is not informed, which happens. And he has to at
> least know it is fixed, becaue he won't be able to check for himself from
> CVS. He will wait for next rpm/deb/exe instead. So release often,
> absolutely. And inform always.
>
> Reassuming, from my ex-naive, regular user point of view, any bugs reported
> should be high on priority list. I'm going to help with that to the extent
> I'm capable of - cleanup the bugtracker, help to manage it in future as time
> allows. Yet a committed and really knowledgable general "fixing coordinator"
> is highly required IMHO. But, who am I fooling - that would be a full time
> job...
>
> I hope my naiveness will be forgiven to me - anyway I compared Grass to BMW!
>
> My 0,01 PLN.
>
> Maciek
>
> P.S.
> I'm not writing this all to hold off 6.0.1 release, I hope it's clear. I
> never meant it if that's your impression. Please release as you recon it's
> best. I just find this an ocassion to rise the issue of bugs in Grass.
>

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy