On Wed, Jan 26, 2005 at 02:18:29PM +0000, Lars Hecking wrote: > > no. create a clear commit policy, and give write access to as many > > people as possible. this makes the project much more responsive, > > particularily for tiny things. also, the nay-sayers have to really > > convince people why something will not go in, instead of just saying > > (and sometimes even only thinking) "i don't like it and nobody can > > commit anyway". > > This opens the door to creeping featuritis. The problem with the current develpment model, and the reason for the fork, is that those who do have commit access are exceedingly reluctant to add features that lots of people want. In many cases those features don't add much in the way of technical complexity, so there's very little real justification to NOT add them (that being the main argument against allowing feature creep). That's getting in the way of progress. It also means that those of us who've written patches to improve mutt's functionality have to keep maintaining them independantly of the mutt development process, which frankly sucks. It balloons the overall development effort, making for lots of wasted time on various people's parts. Giving a zillion people commit access is probably not the way to go, but there's got to be a happy medium. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpkX5NPUaY6i.pgp
Description: PGP signature