dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxx>]

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.

> 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.
I'm not sure I follow; alternatively approaches in what way ?

> >> 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