Re: Kudos - keep up the hard work!

[Derek Neighbors]

On Sat, 2002-10-19 at 07:20, Jan Ischebeck wrote:
> On 17 Oct 2002 08:22:48 Derek Neighbors <address@hidden> wrote:
> > This and some other release type issues makes me wonder about road
> > maps.  Should we fix a few things and do a 0.4.1 release of things or a
> > 0.5.0 and then begin roadmapping for the future? =20
> > 
> > Jason/Jan???
> 
> IMO the main problem with this release seems to be that there were many 
> changes and too little testing of the prereleases. 
>
> Although roadmapping could solve some release type issues, because you
> can plan things more concrete, it is not the most important part needed to get
> a release, which is working in 90% percent of all cases.

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.

1. We dont have a good vision of what is in the release to help for
testing. (ChangeLogs and such help with this)
2. Features get thrown in last minute and are not done in a reliable
way. (this is what killed much of this release)
3. Outstanding bugs that are important are overlooked


> 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.
 
-- 
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
address@hidden

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo

signature.asc
Description: This is a digitally signed message part