[GRASS-dev] Re: please review: draft announcement for future 6.3.0 release

[Maris Nartiss]

Hi, just a small flamme.

2007/2/20, Hamish <hamish_nospam at yahoo.com>:
>  [warning to reader: rambling opinion follows]
>
> A new user can't be expected to hit a moving target.
> They will want to run through tutorials and other documentation which
> depend on static versions to work. (hence 6.x line compatibility rules)
That's true. gis.m has changed since 6.2 and my lab work with
screenshots from 6.2 now differs form 6.3 screens.

>
> More beta testers would be great, but they must have the confidence to
> know that the mistake is a bug in the software and not their own, and
> how to debug or work around the problem. Otherwise it is very
> frustrating if they put a lot of time into a problem only to learn
> it is a bug.
We need more testers, as some problems, that I fixed in gis.m, where
there for loong time and no one noticed (reported) them.

>
> And I don't want to push half finished possibly buggy code on new users.
> They will run into a problem, and even if the problem may be fixed in a
> day then they're turned off and think the whole thing is a buggy mess.
I have exactly problem You describe - students running lab works from
my homemade LiveCD with GRASS (6.3.CVS). They found a lot of UI bugs,
I submitted patches for all of them, but it's not so easy now to
upgrade, as I have to remaster whole LiveCD image to get fixes in.
Users of nazi-upgrade policy distros (read: Debian) are in similar
situation.

>
> Especially right now when 6.2.1 is not so far from 6.3-cvs in features.
> (complication- in future I will tell a Debian/Etch user to install 6.2.1
> from DebianGIS backports, not 6.0.2 from default Etch/stable.)
There are really a lot of different bugfixes in 6.3 in different
areas. Developer activity in fixing old bugs has been really amaizing
if compare with some time a go. Thanks to all of You! Maybee 6.3 will
not have lots of new features, but it will have lots of bugfixes, and
that's really important for endusers.

>
> e.g. In the past I've told colleagues so-and-so is a simple task in
> GRASS and been slightly embarrassed when the CVS version I'm using was
> broken that day for that feature with them looking on. It's usually a
> simple fix, but it makes a bad impression. I've also noticed that when
> I've installed a CVS version for someone they will keep that version
> installed for literally years. Bug support for that is a nightmare-
> they can't upgrade because their version of OSX is pre-10.4, etc.
> and it is just one day's CVS from a year ago-- who can remember what
> state the code was in that day? [this happened yesterday actually;
> ended up just doing the job on my computer. :-/ ]
That's why I have stable version in paralel - I allways can compare -
is this a new bug or old one :)

>
>
> This parallels the Debian stable/unstable debate. They are intended for
> two entirely different audiences. I have no doubt that new users should
> use a well tested stable release, and no doubt that power-users will
> prefer the new the CVS development version. Power users don't need our
> advice, so our generic advice should be targeted to the new user, and
> that advice be to start with the stable branch.
I like better Gentoo approach. Or look at R how they manage
stable/unstable problem. I don't say that we have to follow, but
Debians approach (use as old software as possible) isn't only one and
right way.

>
>
> regards,
> Hamish
>

Just my 0.02 of flamme,
Maris.


P.S. Markus, why -dev list reply-to has not set to -dev? It's a
feature or a bug?