On Thu, 2010-05-20 at 15:33 -0500, Augie Fackler wrote:
On May 20, 2010, at 3:16 PM, Jelmer Vernooij wrote:
On Thu, 2010-05-20 at 13:07 -0500, Augie Fackler wrote:
On Thu, May 20, 2010 at 12:13 PM, Jelmer Vernooij
<jelmer@xxxxxxxxx> wrote:
On Wed, 2010-05-19 at 20:12 -0500, Augie Fackler wrote:
Wow, that was *totally* undocumented. Plus, the class hierarchy
totally implies something different.
Yeah, it's bad it's not very well documented. All the more reason to
be
prudent in this area. :-) I'd also like to get it right this time,
not
end up having to change it for the next release again.
Fair enough, I'll split those changes off into their own branch.
FWIW,
the existing semantics of how you use any of the concrete GitClient
subclasses remains the same (although you *can* reuse the concrete
connections now and they'll behave rather than potentially crashing
in
strange ways) - only the implementation details are different. The
refactor was motivated so that all of the protocol bits were in a
single place so it'll be trivial to write a non-compat mock-using
test
for the client layer.
Ok, that sounds reasonable. I'm not particularly tied to the current
way
in which bzr-git hooks in alternative SSH clients such as Paramiko as
long as we can keep it working.
Yes please - I'm not terribly comfortable relying on dulwich at the
moment, since its development and release cycle has been fairly
opaque
(and things that break hg-git sometimes land without warning).
Which things in particular have done this? I've tried to be careful
about not breaking the important APIs or at least deprecating public
APIs before removing them completely so I'd like to hear if we break
things in hg-git. We've only broken bzr-git once since 0.4.0.
Most recently the change from Tag.get_object to Tag._get_object broke
hg-git (I don't think that's released yet, but I only found it
because
rctay send me a patch).
That one was unfortunate; the recommended way of accessing that sort
of
information is through the property - in this case Tag.object; that
property is implemented using _get_object. Tag.get_object was never
intended to be public. That particular change was made for dulwich
0.3.0
though, a bit over a year ago.
I think we've been a fair bit better about it since then. Generally we
try to document API breakages in the commonly-used public APIs in the
NEWS file. But again, please mention if you notice unexpected
breakages
- we do care about API compatibility.
Could be hg-git shouldn't have used that
function, but it'd be nice to have more warning that a release is
upcoming so that I can test it. I may also be mixing dulwich breakage
in my head with Mercurial breakage - I don't yet have a buildbot to
test hg-git against dulwich master continuously.
Right, I'll make sure to announce that I'm going to do a release a
some
time before so other people have the opportunity to test. I might also
do release branches so that trunk can stay open for more risky
changes.
Also, dulwich@lists doesn't count as public to my mind - almost
nobody
can see that, and membership is closed (I'm not even on it). I'd
much
prefer either that list was open, or we conduct discussions on a
public list that everyone can see.
I'm happy to do those sorts of announcements on dulwich-users@. FWIW
the
archive for dulwich@ is open, it's just the team membership that is
moderated.
Why is the team membership moderated? What's the value in that?[0] It
seems like the ideal place to have development discussions without
doing so on the -users list (although at this point I'm not sure
there
are users that aren't hacking on dulwich so maybe -users is fine).
The dulwich team is the owner of the Dulwich project on Launchpad, and
its members get notified individually when security bugs are reported,
they can set the location of the main branch, purge bugs, upload
ubuntu
packages, etc. I've deactivated its mailing list for now in favor of
the
dulwich-users@ list.
I must have missed the list archives in the confusing UI of
Launchpad.
See the "View archive" link on http://launchpad.net/~dulwich.
Cheers,
Jelmer
