Release status and plans
rra at stanford.edu
Sat Mar 3 12:24:49 UTC 2001
I had two other items on my mental "must have" list for INN 2.3.2, namely
the fixes to innxmit so that it can take file paths as well as storage API
tokens again and the backport from CURRENT of the protocol bug fix in
message retrieval by message ID.
I have code in my development tree on my laptop that should handle
innxmit, although it's not been tested yet, and I think that the protocol
fix has survived CURRENT. I think it's also time for a new stable
release; my original intention was to try to release a new stable version
about every two months and while I missed that badly with the first 2.3
stable release, I'd like to get back to that schedule. A 2.3.2 in the
middle of March would be about right.
I'm going to work on getting those two things into STABLE and then
anything else people think should be in 2.3.2 should go in ASAP so that we
can start looking at spinning up a release.
For current, I have several patches from Jeffrey Vinocur pending (thank
you!) that I want to get in soon, along with gpgverify and some configure
changes to enable it. Marco's controlchan work and Alex's history work
I'm willing to put in the tree whenever they think it's ready.
I also want to find time to write the new configuration parser or the
basic beginnings of it sufficient to parse inn.conf and then drop it into
the tree. That clears the major to-do items for INN 2.4.0.
I'd like to do a major release of INN about once or twice a year; a major
release this summer, around July, would be my current ideal. I hope that
will be enough time to get the history API into 2.4.0 and let it stabilize
some. The other major need that I see for 2.4.0 if at all possible is
better recovery tools, ones that can take advantage of the internals of
the storage methods and the structure of the overview systems in
particular to recover corrupted information.
So for a rough time scale of major features that are on my internal radar:
2.4: History API, new controlchan, basic configuration parser, inn.conf
converted to the new parser
2.5: Filter API and rework of the filtering internals, all documentation
in POD, readers.conf, storage.conf and overview and storage config
files, incoming.conf, and innfeed.conf converted to the new parser
2.6: Unified newsfeeds, incoming.conf, innfeed.conf configuration file,
everything (or nearly everything) converted to the new configuration
parser, headers-only caching storage backend, stable libinn
Obviously, the farther into the future these things are, the fuzzier they
are. Work on a threaded INNT can continue in parallel to all of this and
takes precedent in the version numbering system, so to speak, meaning that
once it's ready to call production I think we should call the next stable
release containing it a 3.0 release.
Also, I've already done a lot of large-scale mechanical changes to INN for
2.4, so I'd like to go ahead and get the rest of those that we can do over
with. They interfere with patch merges, so the more of them we can get
out of the way, the sooner new patches will be easily applicable to the
current development source. I won't do any more until the new history
stuff is in, but after that I'd like to finish moving the manual
configuration stuff out of config.h into an inn/*.h header, try to move
and clean up more of the other headers into inn/*.h, eliminate TRUE and
FALSE everywhere in favor of true and false, eliminate as much of the rest
of macros.h as we can get consensus for, and try to take a stab at getting
rid of the rest of the legacy section in config.h.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers