dulwich-users team mailing list archive

[Augie Fackler <durin42@xxxxxxxxx>]

http://github.com/durin42/dulwich now has two branches:
d42-send-fix: the send-pack fix along with some already-passing compat
tests, for 0.6.0
d42-refactor-clients: the larger client refactor, for after 0.6.0,
pending discussion

Peace,
Augie

On Thu, May 20, 2010 at 4:11 PM, Augie Fackler <durin42@xxxxxxxxx> wrote:
>
> On May 20, 2010, at 4:08 PM, Jelmer Vernooij wrote:
>
>> 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.
>
> Sounds great!
>
>>
>>> 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 ?
>
> Trying to have hg directly manipulate .git and not convert everything to
> revlogs before allowing the user to get work done. In theory it'll work
> great!
>
>>
>>>>> 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
>
>