[darcs-users] Hashed-storage & darcs 2.3 (Was; Re: 2.3 release schedule )

[Dan Pascu]

On Wednesday 27 May 2009, Eric Kow wrote:

> Well, as usual, my job is to let managers get on with it and do their
> jobs, so if there isn't a consensus on this (and one seems to be forming
> anyway), what Petr says goes.

I agree with Petr on this. Keeping the code under the shelf for the next 7 
months, will only get it tested by less than 5-7 people. Now testing would be 
a too strong word to describe the activity, since there will be no dedicated 
people doing testing all day long trying to discover bugs. The process is more 
like random findings of bugs caused by specific usage patterns of people who 
develop darcs and stay synced with the head version and at the same time use 
it for day to day work.

I do not expect anyone outside this mailing list to actually compile and test 
darcs taken from the unstable branch. One needs to be both a darcs and haskell 
enthusiast to do that. Unlike other projects where it is enough for one to be 
a fan of the project and just do the ./configure; make; make install dance, 
here having the need to have a haskell environment installed and correctly 
setup is a serious barrier for people who like darcs and are willing to test 
the latest developments, but have no haskell knowledge and nor the time to 
fiddle with installing a haskell environment which they use for nothing else.

Given that none is actually doing systematic testing, but bugs are more likely 
to be discovered randomly when they are triggered by a specific usage pattern 
of some user, your best chance to get some better coverage is to get as many 
people involved as possible, which is only realistic if the code is included 
in a release. Probably releasing micro versions more often after a x.y.0 
release, will alleviate the pain caused by bugs that can slip into a x.y.0 
release (bugs will slip in there no matter what you do and how conservative 
you are in accepting patches). They should only contain bug fixes and no new 
features. Having a lot of users trying it out and reporting problems is more 
effective even that 24/7 dedicated testers, if you indeed have a lot of users 
exposed to the software. IMO the only way you can do that given the context 
and the barriers mentioned earlier, is through a release.

-- 
Dan