Status of default branch

[Eli Stevens (Gmail)]

I was wondering what the status of:

- The default branch in general is. What would it take to get an
0.8.1 or 0.9.0 ready? What's changed since 0.8?
- What state the tests are in. Can someone wanting to contribute rely
on the current set of tests to provide adequate coverage?
- _replicator DB support. Anyone worked on this? Is there a "right
way" to override the rule that says DBs can't start with '_'?
- I recall there being some changes to session handling from 0.8; is
that work done, or was more planned?

Thanks,
Eli

[Alexander Shorin]

> - The default branch in general is. What would it take to get an
> 0.8.1 or 0.9.0 ready? What's changed since 0.8?

Since there was major changes in http module, cjson deprecation and
support all design functions, it couldn't count for revision release
imho. Full changes easy to view via hg log -r 0.8:tip

> - What state the tests are in. Can someone wanting to contribute rely
> on the current set of tests to provide adequate coverage?

Some things currently are not test friendly (like http module). Some
things are not well testable like:
http://code.google.com/p/couchdb-python/issues/detail?id=208
since I dont know any good methods to emulate race conditions without
massive threading usage and patching internals. May be you know?

I have local branch with his refactored version that more-less test
friendly, but does it really needed since all his tests are done
through usage of CouchDB API?

> - _replicator DB support. Anyone worked on this? Is there a "right
> way" to override the rule that says DBs can't start with '_'?

Full story is there:
http://code.google.com/p/couchdb-python/issues/detail?id=188
Simple and fast solution is just add it to exception name set. But in
perspective this could be wrong way to go.

> - I recall there being some changes to session handling from 0.8; is
> that work done, or was more planned?

Since everything works, looks that session changes are complete.

--
,,,^..^,,,

> --
> You received this message because you are subscribed to the Google Groups "CouchDB-Python" group.
> To post to this group, send email to couchdb...@googlegroups.com.
> To unsubscribe from this group, send email to couchdb-pytho...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/couchdb-python?hl=en.
>

[Eli Stevens (Gmail)]

On Tue, Sep 18, 2012 at 6:54 PM, Alexander Shorin <kxe...@gmail.com> wrote:
>> - The default branch in general is. What would it take to get an
>> 0.8.1 or 0.9.0 ready? What's changed since 0.8?
>
> Since there was major changes in http module, cjson deprecation and
> support all design functions, it couldn't count for revision release
> imho. Full changes easy to view via hg log -r 0.8:tip

Would it be possible to get an 0.9 milestone, and have issues assigned
to it? For example, it seems like this has been fixed already:

http://code.google.com/p/couchdb-python/issues/detail?id=183

I'd be willing to wade in and work on the organization, but I
recognize that I probably haven't earned the trust that being imbued
with that kind of authority / responsibility would require.

>> - What state the tests are in. Can someone wanting to contribute rely
>> on the current set of tests to provide adequate coverage?
>
> Some things currently are not test friendly (like http module). Some
> things are not well testable like:
> http://code.google.com/p/couchdb-python/issues/detail?id=208
> since I dont know any good methods to emulate race conditions without
> massive threading usage and patching internals. May be you know?

While it probably doesn't make sense to have it as a unit test, I
think that massive threading, etc. is fine to have as a test script
that can be run to provoke the problem (and then be run and not
provoke after the fix is in).

> http://code.google.com/p/couchdb-python/issues/detail?id=188
> Simple and fast solution is just add it to exception name set. But in
> perspective this could be wrong way to go.

I think that some clear direction from the owners would be helpful. I
would suggest that it might make sense to split the issue into two;
one for fixing the immediate problem, and one for addressing the
long-term change.

>> - I recall there being some changes to session handling from 0.8; is
>> that work done, or was more planned?
>
> Since everything works, looks that session changes are complete.

Heh, I was more meaning "is there another phase of refactoring yet to come."

Cheers,
Eli

[Dirkjan Ochtman]

On Wed, Sep 19, 2012 at 8:14 PM, Eli Stevens (Gmail)
<wicke...@gmail.com> wrote:
> Would it be possible to get an 0.9 milestone, and have issues assigned
> to it? For example, it seems like this has been fixed already:
>
> http://code.google.com/p/couchdb-python/issues/detail?id=183

There's a patch that's said to be good, but it hasn't been applied to
the default branch, so I would not call it "fixed". :)

> I'd be willing to wade in and work on the organization, but I
> recognize that I probably haven't earned the trust that being imbued
> with that kind of authority / responsibility would require.

Perhaps just start with collecting a list of issues that you think
should/could easily be fixed before a 0.9 release here, in the mailing
list? I'd be happy to go through, do some review and apply patches
where necessary.

>> http://code.google.com/p/couchdb-python/issues/detail?id=188
>> Simple and fast solution is just add it to exception name set. But in
>> perspective this could be wrong way to go.
>
> I think that some clear direction from the owners would be helpful. I
> would suggest that it might make sense to split the issue into two;
> one for fixing the immediate problem, and one for addressing the
> long-term change.

I added _replicator to the SPECIAL_DB_NAMES for now.

> Heh, I was more meaning "is there another phase of refactoring yet to come."

I'll ask Matt to get his stuff from issue 208 out in public in some
way. There's also Alexander's query server stuff, but I no longer
think that's mandatory for 0.9 (although it would be nice to have!).

Cheers,

Dirkjan