[GRASS5] Source Headers and Bug System

Frank Warmerdam warmerda at home.com
Mon Nov 13 09:16:40 EST 2000


Andreas Lange wrote:
> I personally tend to the first system (checking in the exsisting code
> into a new, completley reorganized repository), mainly because i am not
> familiar with the CVS branching/merging operations (and i fear that the
> reorganization of the directories will be too complicated to be done
> with a cvs branch). The reorganization should be used to review every
> module/part. If we have a stable GRASS version, the new deveopment trunk
> needn't be useful/stable while working on it.

Andreas, 

The CVS repository is really a fairly straight forward directory tree
of "RCS" style files, one per source file.  When the tree is reorganized, 
I would suggest we move the old CVS repository files into a new tree with
the new organization.  This will allow us to retain per-file history.

Nevertheless, one of the reasons I like having the log messages in the
file is to ensure that the history is visible when people don't have 
access to CVS, or if we do have a major "step" in source control were
we lose the history.

>i looked at the bugzilla bug tracker recently and i think that a fully
>fledged bug-tracking system for grass is too much work.
>
>Such a system would require:
>- setting up and maintaining the backend/server sofware (at
>intevation.de?)
>- checking in all known bugs into the system
>- every developer maintaining the entries in the bug database etc.
>- just more work for the bugfixing people that gets subtracted from the
>available time. 

I would be happy to host GRASS within the bugzilla at remotesensing.org
(where I also have libtiff, PROJ.4, libgeotiff, and GDAL) saving the trouble
of setting up the required services. 

I agree it would be a significant effort to place the existing bugs into the
system, especially because many of the bugs are not adequately documented as
they are recorded now.  I don't think it is critical to move them all into
the bug database; however, any bugs that people are particularly concerned
about (such as release critical ones) might be worth incorporating. 

Note that it isn't critical to add bugs to the database if they are fixed
quickly.  It is most useful for bugs that might otherwise be lost track of.
However, I have used bug systems on most of my commercial and open source
work and found them a great organizational aid.

I skimmed over your bug report form.  I assume this would get mailed to Markus
who would have to put the important information into the BUGS file.  Is that
right?  I think the need to boil everything into one managable text document
results in the loss of a lot of detail (or detail that might be kept).  It
is also hard to keep track of updated information when it becomes available.
I would also like to see us make the GRASS development organization more 
"scalable" - reducing our dependence on pinch points like Markus where 
practical. 

One good aspect about managing bugs this way is that it isn't critical to 
the success of the effort that all bugs be managed through the bug system.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

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



More information about the grass-dev mailing list