[GRASS5] GRASS release policy needed

Michael Barton michael.barton at asu.edu
Fri Jul 22 02:22:35 EDT 2005


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 at epf.pl> wrote:

> From: "Markus Neteler" <neteler at 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>




More information about the grass-dev mailing list