[ZODB-Dev] StandaloneZODB release: when?

[Barry A. Warsaw]

Getting back on the Standalone 1.0 release wagon...

>>>>> "AK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:

    >> - documentation ;)

    AK> What's missing?  READMEs, docstrings, a manual, what?  If the
    AK> latter, I'll happily contribute the source code for the ZODB
    AK> guide.

I've read your guide over Andrew (from current cvs of the zodb SF
project), and it's very good.  I have a number of minor corrections
and a meta comment.  The meta comment is that the doc is geared toward
the zodb SF distribution and would need some tweaks to make it more
appropriate for the ZC StandaloneZODB distribution.  Is it worth doing
that, under the assumption that we'll eventually be merging everything
into the StandaloneZODB release?
    
    AK> (Docstrings aren't a bad idea, now that I think of it;
    AK> right now "pydoc ZODB" doesn't get you anything very helpful.)

Right, but probably too much work for now.

    >> - integrating Greg's ConflictError patch

    AK> Agreed.  It's an obvious cleanup.

I believe this is now integrated.
    
    AK> Neil, do you think your zeod cleanup could go in, or is it too
    AK> radical?

    >> - integrating the contributions, e.g. PersistentList

    AK> I'd consider them optional, at least for a 1.0 release,
    AK> because IMHO more discussion is needed on what should be
    AK> integrated and how it should be done.

Okay, let's leave the contrib stuff out for now.  We'll add READMEs
pointing back to zodb.sf.net for the contrib stuff in the interim.
    
    AK> See, I'd like to make it falling-off-a-log easy to use ZODB as
    AK> a data store in Python programs, and it's not quite there yet.

Me too.  Jim and Guido too. :)  We're looking at what it would take to
add enough of the machinery to the standard library so that
persistence could become a standard Python service.  Don't expect
anything soon though.

    AK> It's almost there if you don't need concurrent access
    AK> (concurrent access drags in ZEO and the necessity for a
    AK> running server process), but I suspect anyone using the ZODB
    AK> seriously would end up writing tools similar to opendb and
    AK> zodb_census, and we should try to save users from reinventing
    AK> the wheel.

    >> I'd definitely like to keep it alive for the bug and patch
    >> tracking!

    AK> OK, that's easily left alone.

Cool.  We'll want to leave the cvs running to for now, until we suck
over all the functionality we're leaving out of 1.0.

    AK> (In fact it's not clear to me that you can withdraw a
    AK> SourceForge project, which is unfortunate.)

That would hurt their stats too much. :)

To summarize: I don't think there's much left to do for the
StandaloneZODB 1.0 release, at least for beta 1.  We can pull your
guide into our cvs and that will go a long way towards a good
programming manual.  I'll need to read the rest of the documentation
floating around to see what needs updating -- or merging into your
guide.

I think Jeremy's still looking at some minor ZEO issues, and I'm
waiting to hear from Sleepycat on the latest in the search for better
performance (which I believe I have a good handle on).  We needn't
wait on either for a 1.0b1 release though.

-Barry