> Can we have a short description from everyone thats currently working on
> a project stating whats been done since last time? (Gte/ripper/Mr Bean
> I'll let kev off the hook - he's been on holiday ;)
I'll give one anyway. I am satisfied with the code in u2.10.11; it appears
to be proving stable on the test net, though I have had to fix a few bugs
so far. At this point, all that remains is documentation; I've got Braden
writing up new README and RELEASE.NOTES, and he should have the first draft
to me within a couple of days. I also had INSTALL retranslated by delete,
and just checked that into the tree last night. Once I feel satisfied with
the documentation, and once pl15 is officially released, I want to chop off
u2.10.11 for its official alpha.01 release. Assuming it remains stable, I
want to link it to the production network (with no clients) to see if it
can handle the load, and also to get some idea of relative load with
respect to hubs. The events system should have very little impact on the
numbers; I expect the gain to be seen mostly on heavy client servers. Once
I'm satisfied with that test, and have fixed any bugs that crop up, I'll be
prepared for an official beta release, to get it on the client servers and
vet out any remaining bugs, and then we'll release u2.10.11.01.
I want to wait for pl15 before chopping off for alpha so that I can keep
forward-porting of u2.10.10-series changes to a minimum. Once u2.10.11
goes into production, I'll begin work on the u2.10.12 series, though most
of that will probably not be in our tree initially--I'm already working on
a set of libraries which will be used in the work that I want to do on
u2.10.12. The main things I want to accomplish with u2.10.12: rewrite of
the entire database system, with thread-safety in mind; rewrite of the
resolver, possibly by off-loading that to an iauth daemon; and a redesign
of the configuration file (drawing on the work that we had already done).
I also have, as lower priority: support IPv6 (by-product of the database
rewrite, but will involve a protocol change); get rid of sent_along[] in
send.c, in the name of thread-safety; extension of the events system to
cover socket creation tasks (by-product of lib-ifying events, which I've
already started on); and, possibly, breaking the reply table out into
external files to provide a language-selection feature for clients whose
native language is not English.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
