On Tue, May 13, 2008 at 4:54 PM, Jesus Cea <[EMAIL PROTECTED]> 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 _______________________________________________ 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/archive%40mail-archive.com
