<br><div><span class="gmail_quote">On 3/4/08, <b class="gmail_sendername">Jesus Cea</b> <<a href="mailto:jcea@argo.es" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jcea@argo.es</a>> wrote:</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> That said, it is my aim to keep bsddb in stdlib, providing a stable and<br> featureful module. I think keeping bsddb development inside python svn<br>
is not appropiate. Currently (I could change idea), my approach will be<br> keeping pybssdb as a separate project and sync with python SVN from time<br> to time. Mainly to take advantage of buildbot architecture and, of<br>
course, to be able to release python with current bindings.<br> <br> Since I have no python commit access, this seems a sensible approach.<br> And I could do frequent pybssdb releases (let say, every couple of<br> months) without waiting for a full python release (current approach).</blockquote>
<div><br>That makes sense. I also agree with Neal's comments, merging back into python in reasonable sized chunks is good. Don't worry about commit access for now, I'll do the initial pybsddb back into python trunk merges until we get that setup. I've merged the python trunk changes that others have made back into the pybsddb tree.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> PS: I have tried to sign the Python Contributor Agreement, but I am not<br> sure about current pybsddb license terms. Help welcomed.</blockquote>
<div><br>The current bsddb license first and foremost is the Python license. If I read the comments in the _bsddb file correctly I believe you could also call it a MIT style license. Keep things simple, just write "Python License" on your contributor form and submit it.<br>
<br>-gps<br></div></div><br>