[GRASS-dev] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.

Isaac Ullah isaac.ullah at asu.edu
Thu Apr 29 13:22:33 EDT 2010


Yes, I agree that "stable" releases should be a bit more conservative than
the devel branch, but I also would like to see that the "stable" releases
contain the best tools available at the time of release. In that regard, I
am also happy to hear that the MFD capabilities of r.watershed will be
backported to either the 6.4.0 or 6.4.1 releases.
   For future reference, what is the protocol the devel team uses for
determining such backports? ie., how does one feature become slated for a
backport, while another may not? Is it by popular demand? Or by some
quantitative "proof of stability"? Or something else? I'm mainly curious, as
I'd like to know if there is a way for "occasional" developers like me to
contribute to these decisions, either by intensive module testing, or by
clamoring for a change, or by some other means. :)

Cheers,

Isaac Ullah

On Wed, Apr 28, 2010 at 11:01 PM, Hamish <hamish_b at yahoo.com> wrote:

> Isaac wrote:
> > Why put out the next stable version of GRASS with clearly inferior
> > capabilities? This IMO is simple guaranteeing the quick obsolescence
> > of the stable GRASS version for anyone actually interested in doing
> > state-of-the-art, cutting-edge, robust research with it.
>
> you can have cutting-edge*, or you can have stable and robust (aka
> well-tested). you can't have both. For "stable" releases it is best
> to be intentionally conservative.
>
> (* the old dumb joke is to call it bleeding-edge because the closer you
> get to it the more you get sliced by it)
>
> e.g. the nasty bug which happened when scripts used uppercase character
> flags had its damage limited to development svn builds only and was
> flushed out by some months of testing-time.
>
>
> As long as it is planned well in advance and well defined, there is no
> big problem to backport the new -f MDF flag to 6.4.x AFAIAC, just don't
> do that in the last few days before release, wait a few weeks for the
> next minor point version. There are a couple of other features on a
> similar path for 6.4.1. (For releases after x.y.1, I would tend to be a
> lot more strict about breaking the "bug fixes only" rule.)
>
>
> regards,
> Hamish
>
>
>
>
>


-- 
Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project
***************************************************
isaac.ullah at asu.edu
ullah at archaeologist.com

http://www.public.asu.edu/~iullah
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20100429/74602830/attachment.html


More information about the grass-dev mailing list