dulwich team mailing list archive
-
dulwich team
-
Mailing list archive
-
Message #00027
Re: Other changes?
On May 20, 2010, at 3:16 PM, Jelmer Vernooij wrote:
Hi Augie,
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.
now it's living longer. SSHVendor is deprecated but bzr-git relies
on
it existing so it can override it, e.g. with the Paramiko SSH
Vendor.
If that deprecation isn't acceptable I'm fine with changing it -
dependency injection just felt like a significantly cleaner way to
go.
Maybe both would be nice?
I'd rather have one way of doing this. What's the reason for
preferring
a function rather than a class?
Mostly test simplicity and overall code cleanliness (it feels really
wrong to me to have to swap out a function in a module to alter
behavior when you expect that behavior to require modification), but
I'm certainly not married to it. I'll refactor it back out and we can
re-discuss later if I get motivated.
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). 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.
To be completely fair, some of this is my fault for being a terrible
maintainer of hg-git, but I'm progressively getting more and more
frustrated with that codebase and am experimenting with alternative
approaches.
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).
I must have missed the list archives in the confusing UI of Launchpad.
Cheers,
Jelmer
Peace,
Augie
[0] I don't know a blasted thing about LaunchPad, and find the entire
site horribly baffling most of the time I try and do anything, so it's
entirely possible I'm missing some LP detail that justifies this.
References
