Re: [96] [Libbt-devel] Coordinating development

[Alien <ali...@us...>]

Op zaterdag 23 april 2005 06:33, schreef Kevin Smathers:
> >>  * 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.

I think it's well on it's way to become more usefull, but it isn't now... I=
=20
may well like to make a pre-release within a few weeks, maybe a month

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

ok, no problem

but the real problem is that you aren't in contact when I need to contact y=
ou,=20
don't you check your mails? or didn't my mails come through?

as a second thing, how about maintainer priviledges, so I can change trove=
=20
categorisation, and change tracker stuff and etc... and file releases when =
i=20
have to.