Personally, I have little preference, sipa and gmaxwell fall on the side
of cherry-pick, but I think it might be good to do a broad-base test of
CWallet in 0.3.24 so potential bugs can be found in it before crypto and
0.4. In either case, I dont think we should spend too much time as this
is just a minor update release, just get it out the door so we can focus
on 0.4 (hopefully) without interruption.

Matt

On Fri, 2011-07-01 at 20:37 -0400, Jeff Garzik wrote:
> Hum, it sounds like there was some misunderstanding, on my part at
> least.  On IRC, people are talking about a cherry-picked release,
> basically 0.3.23 + a couple specific fixes, rather than what is
> current in upstream git.  I had assumed people meant releasing current
> git + some specific fixes not yet in git.
> 
> Wearing the Release Mangler hat, cherry-picked branches have a few
> disadvantages:
> 
> * you're throwing away the testing people have done on upstream git
> * the new branch would have zero testing, as most people have been
> testing 0.3.23 or upstream git
> * it would be a dead-end branch, never touched after release.  bug
> reports for such a release might not necessarily be applicable to last
> version or current upstream or anywhere in between.
> 
> That is the convention wisdom, anyway.  But to paraphrase Pirates of
> the Caribbean, release management rules aren't really rules, they're
> more like... guidelines.  :)
> 
> The cherry-picked 0.3.24 release, according to IRC wisdom, wouldn't
> have to worry about shipping CWallet, which needs a fix or two from
> https://github.com/bitcoin/bitcoin/pull/358
> 
> I can live with, and roll a release for, either (a) 0.3.23 + select
> fixes or (b) current upstream + pull #358.  My preference is (b), but
> this is a community and Holy Alpaca decision, not just a call I will
> make on my own.
> 
> Comments welcome...
>