Re: Kudos - keep up the hard work!

[Jason Cater]

> You are completely missing my point for a roadmap. :)  I meant that now
> that releases are out, we should look at a roadmap.  Specifically part
> of the problem of not having roadmaps, that are seen in this release.

I don't mind doing ROADMAPS, so long as they are visions/goals and do not
turn into anything more. 

> 
> 1. We dont have a good vision of what is in the release to help for
> testing. (ChangeLogs and such help with this)

We do have changelogs in each tool's directory. These are updated
beginning with the first release. Also, the NEWS file is updated usually
early on. I think prerelease 1 had an up-to-date NEWS file announcing all
the new features. This is a 6-10 line condensed changelog that gives
anyone a feel for what has happened. 

> 2. Features get thrown in last minute and are not done in a reliable
> way. (this is what killed much of this release)

True. 

> 3. Outstanding bugs that are important are overlooked

True to a point. 

One thing I would like to see is a tool for our DCL setup that creates a
BUGS file from outstanding tickets (or TODO, from the workorders).  

The DCL setup we have is fine for on-going stuff. But it sucks for
bug-smashing sessions. It also sucks since the outstanding bugs/todo list
isn't in any way sinced with DCL, so the end-users don't know where things
stand. 

I would think it would work like the ultra-cool cvs2cl.py script that
creates the ChangeLog from CVS history.  Perhaps, dcl2bugs and dcl2todo? 

I commented on the rest of this in gnue-dev since I didn't think it
belonged in the general discussion area. 

> > More important is to document which parts of the gnue prereleases are
> > tested on which platforms. (f.e. appserver was not tested in
> > combination with python2.2, etc.)
> 
> We need a test environment and more formal testing.  We have always not
> 'pushed' this too much because of minimal resources.  As the product
> gets more and more functional and stable it becomes more and more
> important.
> 
> > To reach this goal,  we need to define
> > 
> > 1. a list of platforms/configurations to test:
> > "Debian Woody (deb install,python2.1),Debian Sid
> > (setup-cvs.py,python2.2), Windows (setup.exe,python2.2)" should be the
> > minimum
> > 
> > 2. a list of tests to run: 
> > I thought of something like
> > http://www.mozilla.org/quality/smoketests/.
> > there are already some test cases in the samples/testcases directory.
> > testing should be made as easy as possible, f.e. file
> > samples/testcases/testrun.gpd can be used to start all forms in the
> > subdirectories of samples/testcases.
> > 
> > 
> > 3. a way to document which testcases were tested on which
> > configurations
> >    and if they worked or not.
> > 
> > The status of testing efforts could be shown on a web page. like:
> > http://www.openoffice.org/dev_docs/source/643/release_notes.html#qa 
> > 
> > for now a simple php script which creates a web page out of database
> > records and a gfd file to populate the database would be sufficient.
> > 
> > A web form to add/change entries would be the next step. Later this
> > functionality could be implemented in DCL.
> 
> This works for me.
> 
> > Although having a fixed testing environment will be another thing to
> > be maintained (and to be created), but it will help to increase the QA
> > of gnue, and there will be one point in the nearer future, when it
> > will become mandatory.
> Agree.

-- Jason