Re: [Linux-igd-devel] Next steps [was: Release goals and roadmap...]

[Nektarios K. P. <npa...@in...>]

Hi Daniel,

Daniel J Blueman wrote:
> Hi Nektarios,
> 
> On 14/08/06, Nektarios K. Papadopoulos <npa...@in...> wrote:
> [snip]
>>> Following this, I'd like to get some other security-related items
>>> tightened up and I have a patch half-cooked for item #1 - this should
>>> take a couple of weeks, then after a couple of weeks of code being
>>> tested to some degree, perhaps a grand 1.0 release?
> 
>> I guess you'll finish item #1 on your own. What about #2 (security
>> related issues). Could you elaborate more,  can you split the work to
>> pieces so others can help? I could spent some time on this if you
>> provide some more details and be sure I don't do duplicate work.
> 
> Yes, no problem fixing the interface byte counter bug.
> 
> See my next email on the security stuff - it's worthwhile for one on it's own.
> 
>>> Following this, it would be great to get Nektarios's excellent patches
>>> in and iron out any issues; I've seen at least one potential one,
>>> which I'll raise separately
> 
> See below.
> 
>>> - (I like the "harmonizing" concept I
>>> think Juho mentioned) and release version 1.2/1.5/2.0 depending on how
>>> significant our renewed energy and redefined image is.
>> Thanks for your kind comment. Please raise the issues related to my
>> patches as soon as possible, so I can fix them ;-)
>> Do you also think I need to split the "Layer3Forwarding and minor
>> enhancements" patch into smaller patches or is it ok as is ?
> 
> It would be great if you could split the patch, so I can merge them
> separately. With the Layer3Forwarding + enhancements patch, I've
> started to see "TimerThreadRemove failed!" messages, which weren't
> there previously - I don't see anything against merging some or all of
> the minor enhancements for 1.0 if they aren't causing this.
I believe my changes should not cause the "TimerThreadRemove failed!". I 
think I've seen it occasionally when running without my patch. I'll 
check again for this.

Anyway, regarding splitting the patch. Since all changes are practically 
in gatedevice.c, I'm not sure I can create patches that can be accepted 
rejected independently.
I'll have a first patch that just defines ActionError(...). All other 
patches would require this to be applied since I'm using ActionError all 
over :-).

> 
>> I don't remember what the "harmonizing" concept is. Juho could you explain?
> 
> IIRC, this was converging on the "upnpd" name, rather than an
> inconsistent set of names from init script, binary, UPnP service name
> etc.
Ok, I totally agree with this. However I prefer upnp-igd as in my other 
patch ("Building enhancement and a new name" [1]). Although it is rather 
established, I find "upnpd" to be too general as if we expect linux-igd 
to be the only upnp daemon in a system ;-)

> 
> Thanks for your help!
Glad to be able to help ;-)

[1]http://sourceforge.net/tracker/index.php?func=detail&aid=1511242&group_id=52728&atid=467823
-- 
Nektarios K. Papadopoulos
inAccess Networks