[Monetdb-developers] Re: [MonetDB-users] MonetDB Bug-Etiquette

Niels Nes Niels.Nes at cwi.nl
Mon Nov 21 10:58:34 CET 2005


On Mon, Nov 21, 2005 at 09:15:59AM +0100, Fabian Groffen wrote:
> On 21-11-2005 02:38:01 +0100, Stefan Manegold wrote:
> > Since both the user who submits a bug report and the developer(s) who
> > take(s) care of fixing a bug are by definition very familiar with the
> > details of a bug report, it seems more than obvious that they should share
> > the task of adding a test script to the CVS repository while dealing with
> > the respective bug, i.e., *before* closing the bug report.
> 
> It is not obvious that the submitter knows the problem very well to me.
> Hence, I'd like to reduce the 'options' here, and let the developer add
> the script when (s)he closes the bug.
> 
> > User/Submitter:
> > ===============
> > - Please fill in Category and Group.
> > 
> > - Feel free to set the Priority if you think the default is no appropriate.
> 
> not appropriate
> 
> > - Please provide a detailed description how to repeat the bug you report, or
> >   even a concise test script to do so. Preferably, the test script should
> >   also be added to the standard test-suite (in the CVS repository; see
> >   "Adding test scripts" below for more details!).
> 
> I strongly suggest to drop the CVS thing.  Many users don't have it, and
> it's confusing and more work for devs, see below.
> 
> > - Please feel free to close your bug report, in case you notice it does not
> >   occur any more (your test script in the standard test-suite is your
> >   free-of-charge monitor; simply check our "TestWeb" at
> >   http://monetdb.cwi.nl/Development/TestWeb/ ;-)). 
> >   See "Closing bug reports" below for more details!
> 
> This is weird.  So a bug can suddenly vanish?  Yes it can, but then the
> exact cause of the bug was not found, so it can be gone just by
> coincidence, which is *not* good.  Submitters should only close their
> bug if they think they made a mistake and that their bug is invalid.
> 
> > - Once a developer closes your bug report, please double-check whether the
> >   solution indeed works for you (simply check the status of your test script
> >   in our "TestWeb" at http://monetdb.cwi.nl/Development/TestWeb/ ;-)).
> >   If is does not work for you, feel free to re-open the bug report,
> >   or file a new one. In either case, please give a detailed description
> >   of the remaining or new problem!
> 
> Why not let the developer *always* add the test script before closing
> the bug.  Checking that a bug is already there (hoping it complies to
> the naming conventions as pointed out below) is just some extra hassle.
> Besides that, IMHO it's just more well organised if the dev adds the
> script once (s)he fixes the problem and as such the correct output can
> be determined as well as the test possibly made somewhat more extensive
> to cover more possible problems.  The dev that fixes the problem should
> ideally have the best knowledge on why something went wrong.

All okay but your are forgetting one very important problem here. Developers
do not have the right attitude towards testing. They construct while for 
testing a destructive attitude is needed. So leaving it all to the developer
as your suggesting will also leave some bugs.

Niels
> 
> Just my e0.02
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> MonetDB-users mailing list
> MonetDB-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-users

-- 

Niels Nes, Centre for Mathematics and Computer Science (CWI)
Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
room C0.02,  phone ++31 20 592-4098, fax ++31 20 592-4312
url: http://www.cwi.nl/~niels   e-mail: Niels.Nes at cwi.nl




More information about the developers-list mailing list