Re: [Plib-devel] Portability - policy suggestion

[Martin S. <Mar...@un...>]

Bert Driehuis wrote:
> On Sat, 15 Jan 2005, Alex Perry wrote:

>> Steve, maybe we could have a policy that, for every apparently-supported
>> target architecture, at least one of the developers with write access
>> must be able to build and run code on that architecture.  If that is not
>> the case, either none of the relevant contributors meets the project's
>> criteria for write access or (more likely) they need to be added ...

> Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up. 
> Let me share what I did.

> I reviewed all patches Martin had pointed me to, applied the good ones 
> one by one on my development machine, and reported the ones I would not 
> take ownership of to this list. After applying a patch, I do a build in 
> the development tree to verify that the problem has gone before I commit 
> it (for a build problem, that's verifying that the build proceeds, for a 
> crash, it's running the appropriate test code, etc).

> If I don't have a perfect explanation for why something fixes it, I even 
> go as far as temporarily backing out the change in a scratch build tree 
> to check that the problem comes back without the fix.

> When I'm done, I go back and do a cvs -q diff over the whole tree. I 
> obviously borked this step (probably by not running it over the entire 
> tree), as the uncommitted patch was happily staring at me when I diffed 
> it this morning.

> I usually catch such goofs by building a test straight from anon-cvs, 
> but that day anon-cvs was a bit backlogged so I couldn't do it at home. 
> I did a test build at $ORKPLACE under FreeBSD 4.10 the next day, and as 
> fate would have it, the 4.10 has both 
> /usr/include/{sys,machine}/soundcard.h, so the patch isn't required 
> there.

> Anyway, I apologize for the goof. If you can think of procedural changes 
> to prevent reoccurance I'm all ears.

> For what it's worth, just applying all patches that are available isn't 
> the answer. Patch trackers, like the one on Sourceforge, only work when 
> patches that are below par get rejected immediately. I've payed dearly 
> for keeping patches because they "contain good ideas" -- they linger and 
> realistically, if the submitter doesn't find the time to do them right, 
> what is the chance that you as a maintainer will?

> Cheers,

>  				-- Bert

> -- 
> Bert Driehuis -- dri...@pl... -- +31-20-3116119
> If the only tool you've got is an axe, every problem looks like fun!


> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel



-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------