[GRASS5] Code Freeze schedule

[Markus Neteler]

Hi all,

here a slightly updated schedule proposal:

> > after receiving another request for code freeze to finalize
> > the GRASS 5 stable I want to propose a schedule (with your
> > assistance):

Things which should go into GRASS 5.0 stable
  - new "init" mechanism (Justin Hickey):
     Init means: graphical startup of GRASS instead of script based 
                 startup (old method still working)
      -> in my opinion important for wide acceptance of GRASS

  - new env variable management (Justin Hickey)
      -> nothing critical I think (Justin?)

  - new autoconf (Eric Mitchell)
      -> probably critical (Eric?)
      -> this is required for platform independence and later
         split of GRASS into packages

  - Datum support for projections (Andreas Lange)
      -> due to personal communication with Andreas nearly finished
         nothing critical

  - sockets Xdriver (Carl Anderson)
      -> no idea about status, but required for Windows port finalization

  - extent the test-suite testgrass.sh (all)
      -> nothing critical, but important
 
  - fix all license problems (Bernhard Reiter)
      -> very important
      -> John Huddleston/David Gray are currently implementing a replacement
         for "Numerical recipe" stuff
      -> Helena/Bill B./Jaro Hofierka et al. have released their software
         under GPL

Please correct me, if the proposal is wrong/incomplete.


Frank Warnerdam wrote:
> Markus,
> 
> I haven't been following things too closely, but how critical do you think
> the new init stuff, env variable stuff and autoconf are to the success of
> GRASS 5?  These seem like significant items, and I am not sure what critically
> important role they play.  
.. see new comments above. 

> I think October 1st is pretty close unless these development items are really
> close to ready.  I also think you should avoid splitting into a stable and
> development tree till essentially all known bugs are fixed that you intend
> to fix for the release.  After a split you will start having management
> problems getting bug fixes into both versions.
Yes. Probably we say:

  1. Code freeze, full concentration on bugfixes.
  2. Then split off a development tree
 
> Also, is there a list of bugs classified by severity?  I skimmed through 
> BUGS looking for stuff I would be interested in fixing. I noted a bug in 
> r.in.tiff, r.out.tiff and would be interested in looking into it, but I 
> don't know what supporting information there is about the bug. 
This could be added. Volunteers?
 
> I think it would be quite useful to setup a bug management system (such
> as Bugzilla) for GRASS.  Something where more detail and history could be
> maintained for bugs compared to the BUGS file.  Perhaps Bernhard would be
> interested in setting this up on the intevation server. Alternatively we 
> could easily add a GRASS package to the BugZilla running off remotesensing.org
> or even setup a GRASS project at SourceForge primarily for use of the bug
> system. 
Well, we have discussed this some time ago. The general opinion was not
to use such bug manager. I am not shure - we might discuss again.

Currently I am collecting every information/bugreport I receive in the
BUGS/TODO files. In fact this is extra work for me.

Thanks for your comments, Frank!

Yours

 Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'