[Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0

[Brett Cannon]

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