[Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0 (original) (raw)
Brett Cannon brett at python.org
Thu Sep 4 20:30:54 CEST 2008
- Previous message: [Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0
- Next message: [Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Sep 4, 2008 at 6:35 AM, Jesus Cea <jcea at jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brett Cannon wrote:
Also, the reason for removal may yet disappear if jcrea steps in an continues to make updates.
OK, but none of his changes have received a code review, so if we are going to go down the whole "disciplined" route about it being an rc then we should back out all of Jesus' changes for both 2.6 and 3.0, which puts us back to the same instability issues. I was wondering if somebody could write a "TO DO" list of things need to keep bsddb in the stdlib. Then I could work to trying to comply :).
[Guido already made his public statement in support of removing pybsddb from 3.0, so this is more just for general benefit of Jesus to know why I think this all happened; I don't view these as points to argue over]
Follow python-dev practices. The biggest example of this was checking in code during an rc release cycle without code review. That was stated on python-committers which you should be subscribed to and paying attention to.
Maintain bsddb in Python and cut external releases separately. That would help make bsddb feel more like a stdlib thing instead of something that just gets dumped in our lap when we get close to a release.
Stay on top of the buildbots. test_bsddb has been such a consistent failure on the buildbots that it has left a very sour taste in the mouths of many core developers over the years (and I mean years; Pythonlabs folks are saying how much they remember the bindings being unstable back in the day).
Convince some folks that Sleepycat is actually doing a decent job now. As I believe Fred mentioned and you pointed out with the 4.7.0 release, Sleepycat does not always do solid releases.
Get another committer to help you maintain the code. When Gregory stepped down from maintaining bsddb, the code languished with its traditionally flaky tests until you stepped forward. That suggests to me that no one really wants to maintain that code but you. Sure, people want the code to be there, but "want" does not translate to man-hours to keep the code in good shape.
Yes, we are all very busy guys, but still...
Yes, we are all busy, including you. And that is what makes bsddb the largest maintenance headache in the stdlib; you are a single point of failure for a chunk of code that has garnered a reputation over the years as being flaky. And I realize the reputation is not your fault, Jesus. And I understand people wanting bsddb to be there. But from a core developer's POV, I want to keep the stdlib to code that at least a couple of core developers would be willing to work on if a bug was reported in the issue tracker; bsddb has not shown to be such code base.
And just so people know, I hear the argument about keeping bsddb in 3.0 and then ripping it out in 3.1, but I'm cynical when it comes to python-dev, so I see that as a potential ploy to keep the code in and then have a year or so to argue about this all over again with no change on either side.
Another thing to keep in mind with the whole shelve/dbm.any argument is that for 3.1 there is nothing saying we can't change shelve and the dbm package to allow 3rd-party code to register with the dbm package such that bsddb can be used as needed behind the scenes.
-Brett
- Previous message: [Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0
- Next message: [Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]