Re: [96] [Libbt-devel] Coordinating development
Brought to you by:
ksmathers
From: Kevin S. <ke...@an...> - 2005-04-23 04:31:28
|
>> * Hanging out on the IRC channel (#libbt on irc.freenode.net) >> >> > >i'm already there ;-) > > > I'm not on IRC, but I can be IM'd at any of: Y!: kevin_at_ank AT yahoo DOT com MSN: kevin.smathers AT hp DOT com ICQ: 56409049 >> * Having someone actually be in charge: Kevin, could you clarify >> what role you want to play in libbt? >> >> > >yes, actually in charge, this is the major problem I have been having, i >cannot seem to contact kevin... > > LibBT is one of several spare time research projects of mine. I do work on it when I happen to need to transfer something through BitTorrent and find that it has broken with respect to current client customs. At present my real research project at the lab is taking most of my attention (I was up at 4am for telecon's all this week for example), and what spare time I have I've been working on a different, though complementary program. When that development is at a stage where I will need BT again, I'll take the time to either retread LibBT or else rewrite based on whatever the current protocol spec is (if Bram ever gets his Merkle tree specification finished.) If LibBT main branch manages to track the protocol (through people like Vanraes who have the time to make it do so), and simultaneously define some sort of library API, then great, I might not have to do any work when I need LibBT again later. I see the main trunk as a playground -- there should be room for experimentation there. If the experiment fails, I'll revert the trunk and start over, or else let whoever wants to play on the trunk next do so. If the experiment succeeds in being more useful than the stable branch (with all of its limitations) then I have no problem with letting it evolve. > > >>In addition to these logistic items (which don't require any one to >>write any code), it might be nice if there were some sort of >>consensus on these items before people continue hacking: >> >> * Release goals/plan >> * API definition >> - Model for integration with applications (separate process or >> linked in library with appropriate I/O multiplexing) >> >> > >more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO > > > >> * Implementation decisions: >> - code style >> - portable string/binary library >> - portable network I/O >> >> > >can be usefull to agree upon. > >The big problem is that there is no active maintainer, therefor I repectfully >ask of kevin or Pandora that I be given maintainer priviledges. I will not >act without consulting the mailing list, but I can be there _every_ day to >"maintain" libbt. > >I have a buddy who wanted to help me coding on libbt HEAD CVS, and he still >(more or less a month) waits for ext CVS access or for kevin to contact him. >I just hope he wants to help now... > > > No offense but I didn't see anything in his email that made me want to grant him developer access. Have the guy submit patches until he shows an interest in some development project. >As a side note, I have mostly rewrote the existing code (at least i copy paste >some stuff, and some stuff I leave; but there isn't a file that's been >changed; and some are now obsolete ). > > |