Re: patch - vote

[Randy Terbush <ra...@zyzzyva.com>]

>  -1 72a.mod_imap_overhaul This didn't work for me... I had to patch it in by
>  			 hand, and then it complained about index being 
>  			 redeclared. 

Sorry, but I don't think this is criteria to veto a patch. It's impossible
to make changes that are guaranteed to work on every OS that you *don't*
have access to. If it's a showstopper compile problem, then we need to
be flexible enough to accept a last minute patch to fix the problem.
*Especially* when there are this many patches.


>  +0 99.bind.patch	Doesn't compile on linux alone / doesn't patch with
>  			other patches 
>  
>  http_main.o(.text+0xd0f): undefined reference to `FD_ISSET'
>  http_main.o(.text+0x1270): undefined reference to `FD_ZERO'
>  http_main.o(.text+0x129c): undefined reference to `FD_SET'

Again.

>  -1 100b.os_port.patch	I think we should build the next release, and make the
>  			OS/2 port available as a patch.... I think it's more 
>  			the other patches that don't allow OS/2 to patchin/
>  			compile cleanly.

Garey has been waiting patiently for nearly 6 months now. I think that is
long enough. The changes appear to only effect the __EMX__ defined code.
I see no reason to keep vetoing these patches.

>  And, I would LIKE to see more SQL based modules/patches/additions.
>  SQL is VERY
>  widely used by anyone who has any commercial application.  It is gaining more
>  and more backing as well... 

I agree. I would like to see the mod_auth_msql.c included in the distribution.

>  I propose we change the rules of accepting/declining a patch as well... we
>  should change the decline of a patch from a single -1 vote to a minimum of 2
>  or 3 people, more and more people are getting involved, and a +5 -1 vote 
>  shouldn't make it a bad patch... if it's a OS thing okay, but just on marrit
>  no.

That, or just remember to be somewhat flexible as we hash out this voting
stuff.