Migration 5.0 -> 5.1 - was Re: [GRASS5] current release branch

[Bernhard Reiter]

On Fri, Oct 11, 2002 at 02:23:35PM +0200, Markus Neteler wrote:
> [I have separated below from the original branch thread]
> 
> On Fri, Oct 11, 2002 at 12:19:32PM +0200, Bernhard Reiter wrote:
> > On Thu, Oct 10, 2002 at 07:50:16PM +0100, Glynn Clements wrote:
> > > One issue which should be settled first is to choose a common coding
> > > convention. That way, we can populate the 5.1 tree with files which
> > > have already been formatted, so that everyone doesn't end up
> > > downloading the same files twice (reformatting tends to change every
> > > line, so "cvs update" will retrieve the entire file).
> > 
> > The file structure should come first and library normalisation second.
> > This goes along with a proper makefile system.
> > Coding convention is third.
> 
> Let us start to develop a "road-map" for the 5.0 to 5.1 migration.
> 
> Bernhard's proposal is (slightly modified):

Not really mime, but something that I've had in mind. :)

> 1. select important modules (perhaps 5-10 per function class r.*, d.* etc.)
> 
> 2. run code reformatting software (below is from Apache):
>     indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 <files>

Does that help much?  The complete file has to be reread and controlled 
by a human than. I'd rather not use such a tool.
The formatting might be bad, but on the other important information
can get lost with the new formatting.


> 3. add them reformatted to grass51/ in CVS, using new directory structure
> 
> 4. apply new Makefile system
> 
> 5. start library clean up, clone elimination etc. on these modules/libs

> 6. release

You mean release GRASS 5.2 
or a development version?

> 7. add more modules etc.

An important improvement has to be to distinquish between GRASS modules
(core and for tasts) and add-on modules and thus the ability to split 
GRASS development up further.

> Suggestion for (1.): could we modify "front_end" to generate statistics
> how often which module was used? Then it will be pretty easy to identify
> the most wanted modules without digging in .bash_history etc.

I hope that we cen get rid of front_end soon anyway. :)
Just counting would not help much. There is also the matter of importance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20021011/f797738a/attachment.bin