discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug reporting


From: Richard Frith-Macdonald
Subject: bug reporting
Date: Wed, 14 Feb 2007 06:56:16 +0000


On 13 Feb 2007, at 23:59, Chris Vetter wrote:

On 2007-02-13 21:40:26 +0100 Richard Frith-Macdonald <address@hidden> wrote:
I suspect that comments like that do a lot to put developers off working on GNUstep, doing immeasurably more harm than breakage of code in svn-trunk. The implied notion that a change must be tested on all platforms before submission to svn-trunk in order to qualify as demonstrating 'some care' is frankly ridiculous and insulting.

No. I'm sorry, but no.

I'm NOT saying that code needs to be tested on every possible platform. That would indeed be ridiculous.

I'm saying that you should use a bit of brain-work before commiting code. Using a hard-coded call to make(1) simply ASSUMING that said make(1) IS actually 'GNU make' is, pardon my French, stupid.

Well, the issue is not really whether you are saying that people should have tested thoroughly on all platforms or should have spotted all errors by using 'a bit of brain work' is it? It's whether it's appropriate and productive to react to bugs in software contributions put on svn-trunk by insulting/swearing.

The whole point of svn-trunk is to provide a repository where a large number of people can test out work, so that we end up with reliable and portable code before a release rather than fixing lots of bugs after a release. It is unreasonable to expect code submitted for testing to be perfect ... indeed it's unreasonable not to expect it to contain major and glaringly obvious errors on occasion... most errors are obvious once spotted, and everyone makes stupid mistakes sometimes.

For svn to work effectively in that role, It is essential that updates should be made in relatively small, frequent batches ... so that the revision control can be used to roll-back to earlier versions and localise problems. The use of frequent comittal means that instead of one core developer spending a huge amount of time testing and considering a load of changes, lots of less experienced people can spot problems and localise them so they can be fixed.

The responsibility of people using svn-trunk is to test, spot errors, and politely report them with plenty of detail/explanation (preferably with a fix) or just fix them. The incentive is that they get to play with new features early, and they get to know that they are helping the project progress. And using svn, you never have to wait for someone to provide a fix after submitting your bug report... if you can't (lack of skill or time or inclination) fix a problem yourself, you just use the previous revision.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]