Status of 2.4 release

Jeffrey M. Vinocur jeff at litech.org
Fri Dec 27 09:03:00 UTC 2002


On Fri, 27 Dec 2002, Russ Allbery wrote:

> The only thing left on the 2.4 TODO list is documenting problems with the
> IPv6 support.  

*waves*

As far as I know, the only two things are those listed in doc/IPv6-info, 
namely that when --enable-ipv6 is used:

- innd can only be started via inndstart, not directly.  There's no true 
  reason for this, but Nathan didn't want to duplicate the socket-binding
  code into innd if it doesn't actually get used.  So one of two things 
  needs to happen:  (1) we can put "be able to start innd directly" into
  TODO, or (2) we can declare that use of inndstart is in fact required
  and phase out support for the other.  Thoughts?

- there's some problem with clearing IP_OPTIONS.  It's a little vague 
  here, but I think we collectively couldn't figure out exactly what the
  intent was with those options and whether they were still needed, so we
  punted.  (The code in question is innd/rc.c:RCfix_options() and the sole
  callsite of that function later in the file.)


> Does anyone else have any large patches to commit?

I just committed the only thing I have outstanding of my own.  (Um, unless 
there's something on the laptop, will check that in the next few days.  
Pretty sure not though.)  However, I've been planning on skimming through 
the past few months of email looking for patches -- I blocked on all of 
those SSL patches that Russ just committed.  I will still do that, but 
Russ, it looks like you've just been over the same stuff so I see no 
reason to wait on me finding time to take care of my mail backlog.


> code slush 

Heh.


> aim for kicking out INN 2.4 within a few weeks.

Sounds good by me.  Is anybody testing the SSL code?  I don't think any of 
my users are actually connecting via SSL anymore, so while I'm running 
with the support compiled in, it doesn't see much use.

What sort of stability will we claim to have in 2.4.0?  It seems like we 
haven't allowed all that long for things to settle down.  Or maybe there 
are more people running on the bleeding edge than I realize?


> It would be nice to fix Jeff's problem with
> continuation lines and overview generation first.

Aww, mine?

I do plan on looking into that more.  Possibly right now, hang on tight.


> How does that sound to folks?

All cheer for forward progress and minimal necessary harm to our enemies.

:-)


> Also, one other question.  There are several mechanical changes to lots of
> INN that I think should be done at some point, but that tend to make it
> harder to apply old patches.

I agree with making them.


>  * Remove all the (void) casts on functions everywhere.

Were those inserted just to make lint shut up, or because we actually
don't care about the result?  (What I'm really asking is, does the person
doing this need to keep an eye out for system calls with return values not
being checked?)


>  * Don't ever do them globally.  Instead, just fix code as we work on it.

I don't like this much.  I think it causes confusion to have a mixture of 
styles, especially since this is a pile of code that people dive into from 
necessity.  I would have no problem fixing and entire file at a time, but 
that seems silly (especially since some files never get touched).  So I 
think we're going to have to do it all at once (or at least by 
subdirectory -- and by the way, whatever are we going to do with 
innfeed?).


>    My goal with these changes is to make all the INN code look more like
>    standard C, and therefore make it easier for people to read and follow
>    and possibly reuse in other projects.  That may not be worth the
>    disruption.

May, may not, hard to say.  But internal consistency is important, and for 
that reason I think it's worthwhile.  It would be so nice not to have to 
be fiddling with five files and need four different tabstops.  Same goes, 
in a less mechanical way, for the standard library functions.


>  * Make some or all of these changes now, before the INN 2.4 release,
>    since a new major release will be a new synchronization point for
>    patches from others, and because we're probably at a low point in terms
>    of outstanding patches right now.

I like this best.

Of course, it doesn't have to be before *this* major release, but I think 
it should be before some such.  I'll leave the choice of which to whoever 
has an opinion.


>  * Make some or all of these changes after we branch the release, as the
>    beginning of INN 2.5.  I think this is the worst option.

Agreed.  There's no reason to introduce stuff that would make it hard to 
apply the same patches to 2.4.x and pre-2.5.  All that does is encourage 
people to maintain their own little code forks because it's too hard to 
keep current.


-- 
Jeffrey M. Vinocur
jeff at litech.org



More information about the inn-workers mailing list