Release 3.16
Closed this issue · 3 comments
Hi @dfskoll
I note you updated a few things in preperation for the 3.16 release, so I went off to try and get that packaged for Gentoo to start my own testing ... just to find it's not actually released yet - or am I missing something?
What's the plan?
(Not looking to apply pressure, just looking to understand your timelines and thought patterns here.)
Kind Regards,
Jaco
Hi, Jaco,
I bumped the version number to avoid confusion with the released 3.15 version.
I've done a lot of cleanup on the code, removal of conditional code and tests for unnecessary headers. Also removed BSD and Solaris support as I have no access to machines running those OSes (and haven't for more than a decade, so the code is almost certainly bit-rotted.)
I want to remove all the crufty shell and Tcl scripts because they too have bit-rotted and are likely inappropriate for modern systems. And finally update the docs and release notes. I was going to remove support for user-mode PPPoE, but as #23 shows, there's still a use-case for that. This has made me re-think the idea of merging all of the PPPoE client code into the PPP project, because I'm pretty sure they only want the kernel-mode plugin. As such, I'm likely to keep going with RP-PPPoE and not attempt to do any merging with the PPP project.
Distro packagers can decide whether to package the pppoe.so plugin from the PPP project, or the rp-pppoe.so plugin from this project. But I've concluded that merging the two projects will be way too much effort for not much gain, seeing as all the code will need to be replicated here anyway for user-mode PPPoE.
I have no timeline for when 3.16 will finally be ready.
A few changes I'd also like to push at some point. Might be worthwhile to keep that version something like 3.16-dev or something to avoid confusion. Or even simply "git" with the download URL set to empty.
Yes, my understanding of the plugin vs userspace mode code is the same as yours, and I can't really argue with the above. I do think what we should do though is instead of hard-coding the plugin name/path is to make the plugin name/path an optional argument to the option for pppoe-server. That way a user can choose which plugin is preferred, and we can even separate the compilation of the plugin from the pppoe-server implementation (the latter should have the support unconditionally in my opinion).
Very happy with the above, appreciate the feedback thank you, marking as closed too.
Hi, Jaco,
Hmm, yes, I like the 3.16-dev version idea. Also agree with making the plugin path a command-line option. I'll work on those tomorrow.
Regards,
Dianne.