All fail in test_compiler.py. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
All fail in test_compiler.py.
Thomas Herve has worked out a patch: http://bugs.python.org/issue2177 Christian
2008/2/25, Christian Heimes <lists@cheimes.de>:
Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
After reviewing, testing and etc, I commited it. Let's see the buildbots! :) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
2008/2/25, Facundo Batista <facundobatista@gmail.com>:
2008/2/25, Christian Heimes <lists@cheimes.de>:
Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
After reviewing, testing and etc, I commited it. Let's see the buildbots! :)
Some are green, now, but others still are in red, failing in test_shelve.py, because of errors like this: ====================================================================== ERROR: test_get (test.test_shelve.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py", line 271, in test_get self.assert_(d.get(self.other.keys()[0]) is None) File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py", line 104, in get if key in self.dict: TypeError: argument of type 'dbm.dbm' is not iterable Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista a écrit :
2008/2/25, Facundo Batista <facundobatista@gmail.com>:
2008/2/25, Christian Heimes <lists@cheimes.de>:
Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
After reviewing, testing and etc, I commited it. Let's see the buildbots! :)
Some are green, now, but others still are in red, failing in test_shelve.py, because of errors like this:
====================================================================== ERROR: test_get (test.test_shelve.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py", line 271, in test_get self.assert_(d.get(self.other.keys()[0]) is None) File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py", line 104, in get if key in self.dict: TypeError: argument of type 'dbm.dbm' is not iterable
Hello, I've worked on that problem during the bug day. I've open a ticket with a patch at http://bugs.python.org/issue2168. -- Thomas
2008/2/25, Thomas Hervé <therve@free.fr>:
I've worked on that problem during the bug day. I've open a ticket with a patch at http://bugs.python.org/issue2168.
Most of the buildbots are green now!!! Thank you all! This community is as awesome as Python itself, ;) Three remains in red, though: - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled correctly. Neil is hunting this, I think. - X86 XP-3: seems to crash after test_bsddb3.py. - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in those windows is correctly installed? Thanks again. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
- Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled correctly. Neil is hunting this, I think.
Last time we looked at the _ssl problem, the machine had an out-of-date installation of OpenSSL. Don't know if that ever got rectified; I just crossed that buildbot off my list :-). Bill
- X86 XP-4: idem. For this two, how can be tried if the bsddb lib in those windows is correctly installed?
They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it. Regards, Martin
2008/2/26, "Martin v. Löwis" <martin@v.loewis.de>:
They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it.
No, I wasn't aware of this mechanisms at all. I don't even know how to build Python in a Windows... Anyway, I don't think it's a bad checkout or something, as the same error happens in two different machines. I don't know, :( -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/2/26, "Martin v. Löwis" <martin@v.loewis.de>:
They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it.
No, I wasn't aware of this mechanisms at all. I don't even know how to build Python in a Windows...
Anyway, I don't think it's a bad checkout or something, as the same error happens in two different machines.
I don't know, :(
Or we can get rid of bsddb and not have the problem anymore. =) -Brett
On Tue, Feb 26, 2008 at 02:04:47PM -0800, Brett Cannon wrote:
Or we can get rid of bsddb and not have the problem anymore. =)
+1 for smaller stdlib and fewer problems. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On 2/26/08, Brett Cannon <brett@python.org> wrote:
On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/2/26, "Martin v. Löwis" <martin@v.loewis.de>:
They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it.
No, I wasn't aware of this mechanisms at all. I don't even know how to build Python in a Windows...
Anyway, I don't think it's a bad checkout or something, as the same error happens in two different machines.
I don't know, :(
Or we can get rid of bsddb and not have the problem anymore. =)
-Brett
-1 Using that logic I prefer just getting rid of Windows to stop having these problems. That'd solve the ssl applink issue and msi installer building issue as well. =P My opinion on bsddb as a standard library module is based mostly on "its always been there" and a vague memory of the last time this came up I thought people piped up saying they liked batteries being included, including bsddb and sqlite, but I don't have a handy reference to that email thread. -gps
On Tue, Feb 26, 2008 at 9:46 PM, Gregory P. Smith <greg@krypto.org> wrote:
On 2/26/08, Brett Cannon <brett@python.org> wrote:
On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/2/26, "Martin v. Löwis" <martin@v.loewis.de>:
They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it.
No, I wasn't aware of this mechanisms at all. I don't even know how to build Python in a Windows...
Anyway, I don't think it's a bad checkout or something, as the same error happens in two different machines.
I don't know, :(
Or we can get rid of bsddb and not have the problem anymore. =)
-Brett
-1
Using that logic I prefer just getting rid of Windows to stop having these problems. That'd solve the ssl applink issue and msi installer building issue as well. =P
=) Well, we can't have all our dreams come true.
My opinion on bsddb as a standard library module is based mostly on "its always been there" and a vague memory of the last time this came up I thought people piped up saying they liked batteries being included, including bsddb and sqlite, but I don't have a handy reference to that email thread.
Well, in my opinion "batteries included" is great, but not when one of the batteries consistently acts up and requires a good shake to get working again. The bsddb module has consistent reliability issues when it comes to testing (and I suspect it has more to do with Sleepycat than the bindings). I know I am tired of getting buildbot errors saying that the bsddb tests died more consistently than most tests over their history. And I did some work on porting bsddb over to Python 3.0 and it was painful. Anyway, I am not pushing for this now. Any major removal plans will go through the stdlib-sig first and require justification before I even attempt to seriously suggest something beyond a joking line in an email (in other words, no one needs to worry about anything right now). -Brett
On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <brett@python.org> wrote:
Well, in my opinion "batteries included" is great, but not when one of the batteries consistently acts up and requires a good shake to get working again. The bsddb module has consistent reliability issues when it comes to testing (and I suspect it has more to do with Sleepycat than the bindings). I know I am tired of getting buildbot errors saying that the bsddb tests died more consistently than most tests over their history.
I agree that bsddb has been a pain. It's about 1 of 10 tests that fill that category. I've been working on reducing these problems (recently: test_bsddb3, test_smptlib, test_xmlrpclib, and I'm sure there are others I forgot). Rather than remove modules, it would be more productive if we fixed the flaky tests. Then we wouldn't have to ignore failures, we could trust the buildbots. test_urllib*net tests still fail regularly, I think because some hosts aren't available from time to time. Can someone look into making test_urllib*net more robust? We also need to make the tests more robust. By fixing test_smtplib, I sped it up by over 99% while making it more robust. Any test that uses threads and sleeps (really just sleeps) needs to be fixed similarly. Can someone find which tests still use sleep? n
Neal Norwitz schrieb:
On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <brett@python.org> wrote:
Well, in my opinion "batteries included" is great, but not when one of the batteries consistently acts up and requires a good shake to get working again. The bsddb module has consistent reliability issues when it comes to testing (and I suspect it has more to do with Sleepycat than the bindings). I know I am tired of getting buildbot errors saying that the bsddb tests died more consistently than most tests over their history.
I agree that bsddb has been a pain. It's about 1 of 10 tests that fill that category. I've been working on reducing these problems (recently: test_bsddb3, test_smptlib, test_xmlrpclib, and I'm sure there are others I forgot). Rather than remove modules, it would be more productive if we fixed the flaky tests. Then we wouldn't have to ignore failures, we could trust the buildbots.
Maybe the flaky tests could be moved towards the end? This way we could at least see if the other tests work. Thomas
On Tue, Feb 26, 2008 at 09:46:04PM -0800, Gregory P. Smith wrote:
My opinion on bsddb as a standard library module is based mostly on "its always been there" and a vague memory of the last time this came up I thought people piped up saying they liked batteries being included, including bsddb and sqlite, but I don't have a handy reference to that email thread.
Looking at the July 2000 python-dev archive, it was added in the lead-up for Python 2.0 because the bsddb185 module was becoming increasingly difficult to support; fewer and fewer platforms were including it, I think. So we included the BerkeleyDB wrapper which was backward-compatible and provided much lower-level access. I think BerkeleyDB was also the only stdlib database that included transactional features until sqlite was included. It's disappointing that the API has gotten so complicated and that a few releases have been broken. Doing a code search finds a fair number of users of the module: Zope's BDBStorage, Mailman 2.x's archiver, 4Suite, PyTone, OuterSpace, Chandler, BioPython. --amk
On Feb 27, 2008, at 9:13 AM, A.M. Kuchling wrote:
Doing a code search finds a fair number of users of the module: Zope's BDBStorage, ...
The BDBStorage is long gone at this point. Few are so unfortunate as to remember it (though a few who may just might be on this list). :-) -Fred -- Fred Drake <fdrake at acm.org>
On Feb 27, 2008, at 10:45 PM, Fred Drake wrote:
On Feb 27, 2008, at 9:13 AM, A.M. Kuchling wrote:
Doing a code search finds a fair number of users of the module: Zope's BDBStorage, ...
The BDBStorage is long gone at this point. Few are so unfortunate as to remember it (though a few who may just might be on this list). :-)
Age related memory loss has its upside, I guess. -B
Fred Drake wrote:
The BDBStorage is long gone at this point. Few are so unfortunate as to remember it (though a few who may just might be on this list). :-)
Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high hopes and ending in tragedy ... Several projects like Zope and Subversion worked hard on a a Berkeley DB backend but in the end all projects had the same fate. A few years ago in Göteborg/SE during lunch Jim explained me the reasons for the cancellation. As far as I remember the conversation he used some words I dare not to repeat in public. Some kids may read the Python dev list. :) Christian
Correction: the subversion BerkeleyDB backend is still very much alive and kicking. There were some early issues (they did things that SleepyCat told them not to do :-) but it was corrected and it's still working fine for several large users. On Thu, Feb 28, 2008 at 12:00 PM, Christian Heimes <lists@cheimes.de> wrote:
Fred Drake wrote:
The BDBStorage is long gone at this point. Few are so unfortunate as to remember it (though a few who may just might be on this list). :-)
Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high hopes and ending in tragedy ... Several projects like Zope and Subversion worked hard on a a Berkeley DB backend but in the end all projects had the same fate.
A few years ago in Göteborg/SE during lunch Jim explained me the reasons for the cancellation. As far as I remember the conversation he used some words I dare not to repeat in public. Some kids may read the Python dev list. :)
Christian
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Correction: the subversion BerkeleyDB backend is still very much alive and kicking. There were some early issues (they did things that SleepyCat told them not to do :-) but it was corrected and it's still working fine for several large users.
Thanks for the correction! It seems my information is a bit outdated. Several years ago we have moved most or all subversion repositories to fsfs because we had major issue with the Berkeley backend. I haven't used the bdb backend since then. Christian
On Thu, Feb 28, 2008 at 12:23 PM, Christian Heimes <lists@cheimes.de> wrote:
Guido van Rossum wrote:
Correction: the subversion BerkeleyDB backend is still very much alive and kicking. There were some early issues (they did things that SleepyCat told them not to do :-) but it was corrected and it's still working fine for several large users.
Thanks for the correction! It seems my information is a bit outdated. Several years ago we have moved most or all subversion repositories to fsfs because we had major issue with the Berkeley backend. I haven't used the bdb backend since then.
This was the fault of the svn developers, not of BerkeleyDB. And svn has fixed the issues. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guido van Rossum wrote: | Correction: the subversion BerkeleyDB backend is still very much alive | and kicking. There were some early issues (they did things that | SleepyCat told them not to do :-) but it was corrected and it's still | working fine for several large users. I use BerkeleyDB everyday in a lot of application critical environments, like mailbox storage and such, specially combined with Durus persistence engine. I have medical clients with hundred of terabytes of data under Durus+BerkeleyDB, happy and glad to have met me :). PS: Yes I tried also ZODB+BerkeleyDB. It was ugly and unusable (sigh!), but I don't know why you suppose BerkeleyDB was the one to blame. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83hLJlgi5GaxT1NAQJJ0wQAhjmGh5CWxaiEEkduXuJJFTl1kr4mg8Rr i5Fy+xuquYXScGlv8p0O2G7B+bqji+46cuhk6htuFfXpfIBXBW7QSTBDS4KlsD2+ 8dHxZvKg7irH1rISD6mOfeeAkqFWcVFOBgLOGbwU1EPD+Jfqppaa2dPZ0XemHQon ve3ZAC6wWyg= =xecT -----END PGP SIGNATURE-----
On Thu, Feb 28, 2008 at 09:00:54PM +0100, Christian Heimes wrote:
Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high hopes and ending in tragedy ... Several projects like Zope and Subversion worked hard on a a Berkeley DB backend but in the end all projects had the same fate.
A few years ago in Geteborg/SE during lunch Jim explained me the reasons for the cancellation. As far as I remember the conversation he used some words I dare not to repeat in public. Some kids may read the Python dev list. :)
Sorry, can I ask an additional question? These words - what they were about? about the architecture of BDBStorage and Subversion, or about the very BerkeleyDB, or about what? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
Sorry, can I ask an additional question? These words - what they were about? about the architecture of BDBStorage and Subversion, or about the very BerkeleyDB, or about what?
I don't know all details and it was several years ago so some of my saying may not be correct. I wasn't involved in the project. Please contact Jim Fulton from Zope Corp if you are interested in more details. More than 5 years ago Zope Corp was working on a Berkeley DB backend for ZODB. It was more of a marketing decision to show large companies that ZODB is using a well known database instead of a self made one. The project failed due to problems with the Berkeley db. I vaguely remember something with transactions and speed ... Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Heimes wrote: | More than 5 years ago Zope Corp was working on a Berkeley DB backend for | ZODB. It was more of a marketing decision to show large companies that | ZODB is using a well known database instead of a self made one. The | project failed due to problems with the Berkeley db. I vaguely remember | something with transactions and speed ... BerkeleyDB transaction performance, like any other ACID database, is limited to disk performance (unless you have a non volatile ram, of course). Using ext2 and such, you are happy if you get 30-50 transactions per second. Using nice Solaris ZFS, I do a transaction per rotation; that is, 120 transactions per second with a consumer level 7200RPM disk. PS: Until Oracle takeover, BerkeleyDB was the heart of MySQL transactional engine. I don't like mysql, but not for its use of BerkeleyDB :-). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83ia5lgi5GaxT1NAQJ5NwP/bIBXEDO3158cnAQhfz2TH70aPK7T3YDg SD3FQMoALNSKb5JP8MsMicRB9JcQUdmznEmi3L2C5TrhvLv/Rb2GBZVyJqqGrFn/ ceBYwIzbV2utniWkk7J7bUWisutZQp72//6CNZFNqM6kPA/MLSngm732V1ZX6JRC vzhsWQhO9i8= =2AQ8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Heimes wrote: | Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high | hopes and ending in tragedy ... Several projects like Zope and | Subversion worked hard on a a Berkeley DB backend but in the end all | projects had the same fate. | | A few years ago in Göteborg/SE during lunch Jim explained me the reasons | for the cancellation. As far as I remember the conversation he used some | words I dare not to repeat in public. Some kids may read the Python dev | list. :) I would like to know. Private email is fine to me :-). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83gCZlgi5GaxT1NAQJXKgQAkq6E9zmLRPPINh0rfDy/cOQTY74IS8BP SnBbx2/317nTxe7aNMY4HUAMptA5cae5LKOW+b7+WuHn+F2DMmfbKxvq4PHop2b3 zx9Q3lv4qk6p0ZYL6KLuis5sYivpejuxbRgwFI2m8gkdFsRh5a0MgmVG0b4768TW 6c9ELDY/Xr0= =7pRA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A.M. Kuchling wrote: | Doing a code search finds a fair number of users of the module: Zope's | BDBStorage, Mailman 2.x's archiver, 4Suite, PyTone, OuterSpace, | Chandler, BioPython. I'm pybsddb maintainer since late January. Maintainer transfering ownership is going a bit slow, since both Greg and I are busy guys. Also, I have no commit access to python svn, and I'm barely familiar with practices here (just reading PEP are not enough); managing by proxy is a bit... difficult. That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings. Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach). I see a lot of complains about bsddb3 in stdlib, spitting buildbot red status, and such. I want to help there. Just remember that I have no direct control over python svn and, although I spend last 28 years breathing computer programming (python since 1998), I'm a newbie in python-dev policies and procedures. PS: I have tried to sign the Python Contributor Agreement, but I am not sure about current pybsddb license terms. Help welcomed. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR83fUZlgi5GaxT1NAQIx5AP/VR6HD3HBGbYBl+OeMkL+cHUFgBljIZgl T/N1T2CnertBc6EqEJ2ejEfMuVJF/icCyzwmldXbQWsVjd9XFq7gVGe7h9r7RTc5 DaiBrZk2ZBVEXk5Vp+QcWiyObMU4dYYF5JRyjRl4hCdKPRXo1TLTkQchoc945ubc VEgLgCHROcE= =1I5Z -----END PGP SIGNATURE-----
On Tue, Mar 4, 2008 at 3:46 PM, Jesus Cea <jcea@argo.es> wrote:
That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings.
Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach).
I think that approach is fine. Hopefully you can keep the changes reasonably small (preferably less than 500 lines per change). That will ensure more people will review your changes. Cheers, n
That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate.
I think it would be helpful if you could analyze the crashes that bsddb caused on Windows. Just go back a few revisions in the subversion tree to reproduce the crashes. These were particularly bad since they invoked the CRT abort() inside bsddb, namely inside __db_win32_mutex_unlock, which, in debug mode, would __db_panic with "Win32 unlock failed: lock already unlocked". This problem has now been worked-around, by reformulating the test cases so that the situation doesn't occur anymore, but IMO, it should not be possible for an extension module to cause an interpreter abort. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote: | I think it would be helpful if you could analyze the crashes that bsddb | caused on Windows. Just go back a few revisions in the subversion tree | to reproduce the crashes. I have no MS Windows machines in my environment :-( | This problem has now been worked-around, by reformulating the test cases | so that the situation doesn't occur anymore, but IMO, it should not be | possible for an extension module to cause an interpreter abort. Agreed. But I can't test Windows builds myself. Could anybody help me in this issue?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSAyr9Zlgi5GaxT1NAQKzHgP/YKQ/9eLlwQfEKxePb5VtapkbfDri5T6C dulFrvuEEQqsefBopC1K70Tm4XGNmmLpf6U4Ew5ran0dQwjRPfQH+AWo8Cloh9IC ta8KjxHzIdl6myzitDwH1YKkDbrqdd1M5qs2QDKDjVx5c53ePHQNfLS9oOqtoWcc XNg6ro8K4os= =eQC0 -----END PGP SIGNATURE-----
| This problem has now been worked-around, by reformulating the test cases | so that the situation doesn't occur anymore, but IMO, it should not be | possible for an extension module to cause an interpreter abort.
Agreed. But I can't test Windows builds myself. Could anybody help me in this issue?.
Sure. If you post a patch, I'm sure someone will be able to test it on Windows and report results; when it's committed, also the buildbots will test it. Regards, Martin
Hi Jesus,
Martin v. Löwis wrote: | I think it would be helpful if you could analyze the crashes that | bsddb caused on Windows. Just go back a few revisions in the | subversion tree to reproduce the crashes.
I have no MS Windows machines in my environment :-(
I remember those rampant BSDDB crashes on Windows well. I brought this up with Martin at PyCon; I really don't think we can fault BSDDB here -- basically, the tests weren't cleaning up their environment in the right order, so BSDDB was getting passed completely and utterly bogus values. I *think* I managed to persuade Martin that this was indeed our fault, and we can't really hold BSDDB accountable. (My argument being that if a 3rd party app says the behaviour of a method is undefined if you pass it a null pointer, and you pass it a null pointer, and it crashes your program, it's your fault, not theirs.) Once this was addressed, the BSDDB tests ran more or less on Windows 32-bit without error. Windows x64 was another matter though -- I traced the problem down to wildly conflicting compiler and linker flags between our Python build and how we were building BSDDB (or rather how BSDDB builds out of the box on Windows). My solution was to drop our reliance on the Berkeley_DB.sln/db_static.vcproj files completely, and mimic a bsddb44 vcproj in our own pcbuild.sln, which basically meant all the BSDDB source code got built in the exact same fashion as the rest of Python. I also took this approach with sqlite3 and it's worked really well -- there have been no issues with either module since this change. I've also got bsddb45.vcproj and bsddb46.vcproj projects floating around in one of my local branches somewhere. These mimic the corresponding BSDDB projects, with the intent being that when it comes to release time for 2.6 and 3.0, we'd make a decision about which one to ship with, and then set the Python _bsddb module to use that. I should probably pick that up again... Hope this clarifies things... Regards, Trent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: | I remember those rampant BSDDB crashes on Windows well. [...] | basically, the tests weren't cleaning up their environment in | the right order, so BSDDB was getting passed completely and | utterly bogus values. Next week I will (if nothing goes wrong) publish pybsddb 4.6.4. This release supports distributed transactions and replication, testsuite is way faster, and rewritten to be able to launch tests from multiple threads/processes if you wish, setuptools/pypi support, etc. I think this release would be appropiate to integrate in Python. I think most demands are solved and new features are interesting (replication, distributed transactions, do not crash when closing objects in the wrong order...). Also, I completed the documentation, with the full supported API, and ported it to Python 2.6 documentation system. The result: http://www.jcea.es/programacion/pybsddb.htm#bsddb3-4.6.4 http://www.jcea.es/programacion/pybsddb_doc/preview/ I'm very interested in integrating this release in Python 2.6 for the new features, the full documentation, and to get feedback from Buildbot and python-dev community. Also, I would like to avoid to integrate pybsddb late in the python 2.6 release cycle; I hope to be away of my computer in August! :). I'm a bit nervous about syncing, because I have the feeling that python-dev is committing changes to python private branch of pybsddb. I would rather prefer patches send to me and integrate "canonical" pybsddb releases in Python frequently. Somebody suggested to post patches in the tracker, but I think this is not going to work. The diff from current python bsddb and the official version is so huge that nobody could follow it. A more sensible approach, I think, is to "diff" current python pybsddb against the version I used as my root (January?), integrate the changes in current "canonical" pybsddb and, then, drop the entire updated package into python. Then, commits to python pybsddb should be avoided; patches should be send to me. I think this is the only way when integrating a project outside python SVN. Suggestions?. PS: I can't comment on Win64. It is an alien world to me :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSA6oeJlgi5GaxT1NAQItswP+KR15vZWbnYZ23WQHoUozVOWvf+ghG2Q8 acVhCwJajzvxOEfozRMZRmQkPUBmWga1zbHjkHt5c196vku7+X0bDc7aO4T2jRHx 00PbPLGnYth972elTVFfSWpZVNkX/9A4EbtTHVCav105nW+u1/Kod/rY5fzgKcTn SxYkmk4Ax7U= =98uc -----END PGP SIGNATURE-----
I'm a bit nervous about syncing, because I have the feeling that python-dev is committing changes to python private branch of pybsddb. I would rather prefer patches send to me and integrate "canonical" pybsddb releases in Python frequently.
My understanding was that the pybsddb copy in Python *is* the official code base. I think it's unfortunate that the pybsddb project was revived, even though it was already dead. Perhaps we should remove bsddb from Python again, and refer people to pybsddb instead?
Somebody suggested to post patches in the tracker, but I think this is not going to work. The diff from current python bsddb and the official version is so huge that nobody could follow it. A more sensible approach, I think, is to "diff" current python pybsddb against the version I used as my root (January?), integrate the changes in current "canonical" pybsddb and, then, drop the entire updated package into python.
-1. Who is going to do the 3k porting?
I think this is the only way when integrating a project outside python SVN. Suggestions?.
The usual solution is to not integrate then, at all. Python doesn't really ship with any libraries that also have an active life outside of Python. Regards, Martin
Martin v. Löwis wrote:
I think this is the only way when integrating a project outside python SVN. Suggestions?.
The usual solution is to not integrate then, at all. Python doesn't really ship with any libraries that also have an active life outside of Python.
Not entirely true - we have the ones listed in PEP 360. However, I think of those only Optik (aka optparse) is currently seeing active external updates. Of course, we also have a big warning at the top of the PEP saying *Never Ever Do This Again*. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
The usual solution is to not integrate then, at all. Python doesn't really ship with any libraries that also have an active life outside of Python.
Not entirely true - we have the ones listed in PEP 360. However, I think of those only Optik (aka optparse) is currently seeing active external updates.
Hence my classification "doesn't really", which I meant to be vague.
Of course, we also have a big warning at the top of the PEP saying *Never Ever Do This Again*.
I think that's what Guido once said. Regards, Martin
On Tue, Apr 22, 2008 at 11:12 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I'm a bit nervous about syncing, because I have the feeling that python-dev is committing changes to python private branch of pybsddb. I would rather prefer patches send to me and integrate "canonical" pybsddb releases in Python frequently.
My understanding was that the pybsddb copy in Python *is* the official code base. I think it's unfortunate that the pybsddb project was revived, even though it was already dead.
Perhaps we should remove bsddb from Python again, and refer people to pybsddb instead?
+1 from me! The amount of issues the bsddb module has caused over the years suggests to me it would do better as an external project again. -Brett
On Tue, Apr 22, 2008 at 8:09 PM, Jesus Cea <jcea@argo.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Trent Nelson wrote: | I remember those rampant BSDDB crashes on Windows well. [...] | basically, the tests weren't cleaning up their environment in | the right order, so BSDDB was getting passed completely and | utterly bogus values.
Next week I will (if nothing goes wrong) publish pybsddb 4.6.4. This release supports distributed transactions and replication, testsuite is way faster, and rewritten to be able to launch tests from multiple threads/processes if you wish, setuptools/pypi support, etc.
I think this release would be appropiate to integrate in Python. I think most demands are solved and new features are interesting (replication, distributed transactions, do not crash when closing objects in the wrong order...). Also, I completed the documentation, with the full supported API, and ported it to Python 2.6 documentation system. The result:
http://www.jcea.es/programacion/pybsddb.htm#bsddb3-4.6.4 http://www.jcea.es/programacion/pybsddb_doc/preview/
I'm very interested in integrating this release in Python 2.6 for the new features, the full documentation, and to get feedback from Buildbot and python-dev community. Also, I would like to avoid to integrate pybsddb late in the python 2.6 release cycle; I hope to be away of my computer in August! :).
I'm a bit nervous about syncing, because I have the feeling that python-dev is committing changes to python private branch of pybsddb. I would rather prefer patches send to me and integrate "canonical" pybsddb releases in Python frequently.
Somebody suggested to post patches in the tracker, but I think this is not going to work. The diff from current python bsddb and the official version is so huge that nobody could follow it. A more sensible approach, I think, is to "diff" current python pybsddb against the version I used as my root (January?), integrate the changes in current "canonical" pybsddb and, then, drop the entire updated package into python.
Agreed. I "forked" jcea's version found in his svn repository from python trunk at r60209. The only change to any Modules/*bsddb* files made to python trunk since then was me manually applying one bugfix that jcea had made in his repository. My goal all along had been to merge his changes back into python trunk until he had commit access. Obviously I haven't had time to do that. The changes to Lib/bsddb/* since then have been test suite updates which I think jcea should go through and selectively merge as appropriate into his repository (he has done a lot of test suite cleanup). ( svn:// svn.argo.es/jcea/pybsddb/trunk ) After that, merging his changes into trunk will be relatively easy and I think we should give jcea commit access and let him do it and henceforth use python svn as the official repository for the pybsddb code and documentation. I do not see this as a daunting task assuming jcea is willing to be volunteered to do the merge and to handle any py3k merge issues that come up. Alternatively: (removal of bsddb from the standard library) If people want to go the other route a remove bsddb from Python all together letting it thrive as a standalone addon module, what will this mean to the old shelve and dbhash standard library that use bsddb? Someone should write a sqlite backend for shelve. Either way it should not be removed from 2.6 as it needs to be marked at deprecated for one release round only to be taken out in 2.7 and that does leave open the question of should it exist in 3.0 at all or just start out deprecated there? -gps
After that, merging his changes into trunk will be relatively easy and I think we should give jcea commit access and let him do it and henceforth use python svn as the official repository for the pybsddb code and documentation.
Ok. Jesus, can you please send me your SSH key?
I do not see this as a daunting task assuming jcea is willing to be volunteered to do the merge and to handle any py3k merge issues that come up.
Ideally, yes. Jesus, if you are uncertain of how exactly the merging works, don't hesitate to ask. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory P. Smith wrote: | After that, merging his changes into trunk will be relatively easy and I | think we should give jcea commit access and let him do it and henceforth | use python svn as the official repository for the pybsddb code and | documentation. | | I do not see this as a daunting task assuming jcea is willing to be | volunteered to do the merge and to handle any py3k merge issues that | come up. Well, I would like to keep bsddb3 alive outside python SVN. There are a few reasons (like being able to accept foreign patches, for instance); the main one is: I've published *four* bsddb3 versions in the last 3-4 months. Each release gives a quantum leap improvement in Berkeley DB support (for example, replication and distributed transactions). If I link the bsddb releases to python ones, progress would be very slow. In current state, bsddb3 still needs a lot of work to catch current Berkeley DB feature sets. I think I can publish a new release per month until 2009. Those releases will be consistent improvements in Berkeley DB support. But I don't want to link Python with this much needed bsddb3 releases. My intention is to upgrade python bsddb3 versions from time to time, enough to keep them fresh without burden you with constant patches. On time for official releases. Moreover, keeping the bsddb3 separate will allow me to publish a new release when Oracle updates Berkeley DB. This has been a serious issue in the past. bsddb3, as a separate project, can support last Berkeley DB release without python build servers needing a BDB upgrade and users waiting a full release cycle (months). A last point: I can provide bsddb3 packages for python 2.3, 2.4 and 2.5, also. That said, I'm very interested in being a good python-dev netizen. I will do what needed to merge patches back and forth. I will read your comments with maximum interest. I will have the buildbot webpage open permanently :-). I will do the python 3.0 necessary changes when time comes. And Python will integrate a bsddb3 library proved in the wild, verified against 5 different python releases and 8 different Berkeley DB ones. And I will love to do additional work in python, aside bsddb. Let me show you that I can do it... - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSCoqO5lgi5GaxT1NAQJP1wP6A46t6f7wajIyrUoScLE8RSqJSncnW1jo r/7A69hRC6UW2I0JbMJ+wFVcXC2507XaCiC0l0Xljq9IqH7JAU6H/gwv6Cyp4eVF tmwiUVFmlw+wyZMCnvBAa4EOF4/ZBwrILIdNywFNpoRmCLH8RmiBDE+x4jgjcSCh N5yssDDLzPk= =/YFF -----END PGP SIGNATURE-----
On Tue, May 13, 2008 at 4:54 PM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory P. Smith wrote: | After that, merging his changes into trunk will be relatively easy and I | think we should give jcea commit access and let him do it and henceforth | use python svn as the official repository for the pybsddb code and | documentation. | | I do not see this as a daunting task assuming jcea is willing to be | volunteered to do the merge and to handle any py3k merge issues that | come up.
Well, I would like to keep bsddb3 alive outside python SVN. There are a few reasons (like being able to accept foreign patches, for instance); the main one is: I've published *four* bsddb3 versions in the last 3-4 months. Each release gives a quantum leap improvement in Berkeley DB support (for example, replication and distributed transactions). If I link the bsddb releases to python ones, progress would be very slow.
This is why I think bsddb should just be an external package. The few wrappers we still have in the core (sqlite and tkinter) do not have a high churn rate at all since both are fairly stable and not constantly changing (or at least that I can tell). Regardless, we are trying to prevent external maintenance from happening anymore. Python is not like a Linux distribution where we push patches upstream; we are the upstream. Patches should end with us.
In current state, bsddb3 still needs a lot of work to catch current Berkeley DB feature sets. I think I can publish a new release per month until 2009. Those releases will be consistent improvements in Berkeley DB support. But I don't want to link Python with this much needed bsddb3 releases. My intention is to upgrade python bsddb3 versions from time to time, enough to keep them fresh without burden you with constant patches. On time for official releases.
If the wrapper is still behind then I think this is another reason to remove the package from the core and just keep it external. Why have something in the core that is outdated when its committed?
Moreover, keeping the bsddb3 separate will allow me to publish a new release when Oracle updates Berkeley DB. This has been a serious issue in the past. bsddb3, as a separate project, can support last Berkeley DB release without python build servers needing a BDB upgrade and users waiting a full release cycle (months).
A last point: I can provide bsddb3 packages for python 2.3, 2.4 and 2.5, also.
That said, I'm very interested in being a good python-dev netizen. I will do what needed to merge patches back and forth. I will read your comments with maximum interest. I will have the buildbot webpage open permanently :-). I will do the python 3.0 necessary changes when time comes. And Python will integrate a bsddb3 library proved in the wild, verified against 5 different python releases and 8 different Berkeley DB ones.
And I will love to do additional work in python, aside bsddb.
Let me show you that I can do it...
I am always happy to have developers to step forward and want to help! And the last thing I want to do is discourage another contributor, but I still think bsddb should be gone from 3.0. The churn rate sounds too high on Berkeley DB itself to warrant making it an included package that we continue to support internally. I also worry about maintenance in terms of multiple people being able to help. bsddb sat there for a while when Gregory scaled back his work. I remember trying to do the initial port of bsddb to 3.0 and it was hard and not many people wanted to work on it (and I don't blame them). sqlite and tkinter, on the other hand, was not as difficult and we have never had issues finding people willing to help with the code. While Jesus is up for doing all of this work at this moment (which is great!), if he fell off the face of the earth we will be stuck with a stale package again. -Brett
Next week I will (if nothing goes wrong) publish pybsddb 4.6.4. This release supports distributed transactions and replication, testsuite is way faster, and rewritten to be able to launch tests from multiple threads/processes if you wish, setuptools/pypi support, etc.
Great! Once you've settled in with your changes let me know and I'll help with doing the necessary things on the Windows-side to set up the bsddb46.vcproj and switching the build to use that. Trent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: |> Next week I will (if nothing goes wrong) publish pybsddb |> 4.6.4. This release supports distributed transactions and |> replication, testsuite is way faster, and rewritten to be |> able to launch tests from multiple threads/processes if you |> wish, setuptools/pypi support, etc. | | Great! Once you've settled in with your changes let me know and I'll help with doing the necessary things on the Windows-side to set up the bsddb46.vcproj and switching the build to use that. Python SVN updated. Let me know if you need anything from me. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSCopHZlgi5GaxT1NAQKrCQQAj/HTk5oqSbF2PYkZpCw2T7Dd6yEgddlY L+qW1Cde/b3duClEfawy7kf5DkSjlGLVZ9XSS+njAMKszzYK6ZIg9N4GEu5A9TO2 Rg2PiytaPbs88Jo5IIlDjvaVFPPqsOasn7WH1wcawtUKNei8whMReOveZgYXfFFf QphSJ7zspNU= =L6jr -----END PGP SIGNATURE-----
Thanks Jesus. I'll import BSDDB 4.6.4 into svn.python.org/projects/external today. Once that's done, I'll create a new bsddb46.vcproj and update the pcbuild.sln to use this project instead of the bsddb44 one currently being used. (Hopefully I'll be able to get that done today as well.) I assume you're just working on trunk at the moment? i.e. should I block or merge the changes to py3k? For everyone else: just a heads up that there will probably be a little bit of buildbot instability whilst we transition BSDDB versions on Windows. Trent. -----Original Message----- From: Jesus Cea [mailto:jcea@jcea.es] Sent: Wednesday, May 14, 2008 12:50 AM To: Trent Nelson Cc: python-dev@python.org Subject: Re: [Python-Dev] BSDDB3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: |> Next week I will (if nothing goes wrong) publish pybsddb |> 4.6.4. This release supports distributed transactions and |> replication, testsuite is way faster, and rewritten to be |> able to launch tests from multiple threads/processes if you |> wish, setuptools/pypi support, etc. | | Great! Once you've settled in with your changes let me know and I'll help with doing the necessary things on the Windows-side to set up the bsddb46.vcproj and switching the build to use that. Python SVN updated. Let me know if you need anything from me. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSCopHZlgi5GaxT1NAQKrCQQAj/HTk5oqSbF2PYkZpCw2T7Dd6yEgddlY L+qW1Cde/b3duClEfawy7kf5DkSjlGLVZ9XSS+njAMKszzYK6ZIg9N4GEu5A9TO2 Rg2PiytaPbs88Jo5IIlDjvaVFPPqsOasn7WH1wcawtUKNei8whMReOveZgYXfFFf QphSJ7zspNU= =L6jr -----END PGP SIGNATURE-----
On 3/4/08, Jesus Cea <jcea@argo.es> wrote:
That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings.
Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach).
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. PS: I have tried to sign the Python Contributor Agreement, but I am not
sure about current pybsddb license terms. Help welcomed.
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. -gps
Gregory P. Smith wrote:
On 3/4/08, *Jesus Cea* <jcea@argo.es <mailto:jcea@argo.es>> wrote:
That said, it is my aim to keep bsddb in stdlib, providing a stable and featureful module. I think keeping bsddb development inside python svn is not appropiate. Currently (I could change idea), my approach will be keeping pybssdb as a separate project and sync with python SVN from time to time. Mainly to take advantage of buildbot architecture and, of course, to be able to release python with current bindings.
Since I have no python commit access, this seems a sensible approach. And I could do frequent pybssdb releases (let say, every couple of months) without waiting for a full python release (current approach).
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.
PS: I have tried to sign the Python Contributor Agreement, but I am not sure about current pybsddb license terms. Help welcomed.
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.
Unfortunately that won't do it. At present the PSF can only accept contributions under two initial licenses: either the Academic Free License v 2.1 or the Apache License v 2.0. See http://www.python.org/psf/contrib/ This is because only these licenses have been approved by attorneys as giving the PSF the necessary unencumbered permission to relicense for distribution *under* the Python license. So Jesus was right to be concerned about licensing. I know it's a pain, but there are reasons. I don't see anything in the file to stop _bsddb.c being licensed to the PSF under either approved initial license. The licensing FAQ http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq explains why you can't just contribute code "under the PSF license", and the contributor agreement requires that each contribution should include the contributor's valid copyright notice and the phrase "Licensed to PSF under a Contributor Agreement." This condition appears to be more honored in the breach than the observance though, since the phrase currently only seems to appear five times in the whole source unless I need to practice my grep-fu. As to the library that _bsddb wraps, I have not checked its licensing conditions and so cannot say how it is licensed to the PSF for redistribution, nor do I know whether Oracle's acquisition of SleepyCat will affect future versions. Bet it gave the MySQL guys some sleepless nights, though. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory P. Smith wrote: | 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. But Python license is not accepted for Python Contributor Agreement. This is even in the FAQ. MIT is not accepted either. Software patents sucks :p - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR9ACuJlgi5GaxT1NAQLSNwP/f4x813gpXcG3HhIbav1PVTMnzKhe6PNx 5jDxEwpUNoXFRtRH2aj5Et5ecUghm2B1sbsSX5Mpfb/yKWsc9yvyDe50Z05Tm961 MvPj3o39eztZr5LtHW+FwFJuUfbAO2SMC98aGDZ+9IhwNt3/3emB1hMNCh+90tFF aiPU0nQ14vU= =DIGQ -----END PGP SIGNATURE-----
participants (21)
-
"Martin v. Löwis" -
A.M. Kuchling -
Barry Warsaw -
Bill Janssen -
Brett Cannon -
Christian Heimes -
Facundo Batista -
Fred Drake -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Jesus Cea -
Jesus Cea -
Neal Norwitz -
Nick Coghlan -
Oleg Broytmann -
Steve Holden -
Thomas Heller -
Thomas Hervé -
Trent Nelson -
Trent Nelson