Moving libkqueue forward #40
Comments
|
Thanks @arr2036 for making me aware of the outstanding items that need to be addressed with libkqueue. I apologize for the long delay in responding to PRs, and would like to offer a quick explanation of what happened and what I plan to do going forward. Some of the reasons for the lack of attention to libkqueue include:
Here's what I plan to do going forward:
|
|
@mheily thanks for the response. I absolutely understand what it's like having legacy projects hanging around. You've moved on but there's still a community that find it useful and bug you for things. If you ever want assistance in dealing with pull requests (maybe after there have been a few more PRs that you're happy with) then let me know and I'd be glad to step up.
That sounds great, thanks! Out of the PRs that we've contributed #33 is the most contentious. I'm honestly not sure if this is correct fix or not. We have worked around it internally, but it'd be good to get a proper fix into libkqueue, as libkqueue in its current state is non-functional with libpcap (unless you work the issue specifically). We needed a fix because it affects our DHCP module and packet analysis utilities. Regarding cutting a new release, I don't know what the cmake packaging state is for Debian, if you find it's unusable and don't want to deal with the horrors of cmake packaging, ping me, and i'll find some time next week to sort it out. We run support both, but the immediate need was to generate sane RPMs on RedHat/Centos so that got the fixups (#34) first. |
|
@arr2036 I've merged all the pull requests and tagged a v2.2.0 release. I've also sent you an invitation to become a committer to this project. Thanks for offering to help o ut. |
Accepted, thanks!
Yep absolutely. There were a few maintenance things I was going to crack on with but wanted to check with you. Currently, the project doesn't seem to have any kind of CIT integration. Mind if I set it up with Travis? That way the existing test suite gets run on new PRs and whenever anyone pushes to the repo. Formatting is not always consistent especially with the windows code. I can try and come up with some rules based on the general style of the code and run it through an automated formatter? Are you adverse to Doxygen (code documentation tool)? We tend to use this style of function headers https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/src/lib/ldap/connection.c#L196. One of the nice things about Doxygen is clang can perform validation of the Doxygen headers, and warn you when they don't match the observed arguments. |
|
On Nov 27, 2017 09:31, "Arran Cudbard-Bell" <[email protected]> wrote:
@arr2036 <https://github.com/arr2036> I've merged all the pull requests and
tagged a v2.2.0 release. I've also sent you an invitation to become a
committer to this project. Thanks for offering to help o ut.
Accepted, thanks!
Regarding the CMake packaging question, would you mind working on that? I
don't care to learn CPack at this time. I'll submit an updated Debian
package upstream, and see about submitting something to Fedora/EPEL. I'm
considering using the opensuse build/packacking system to publish
semi-official packages.
Yep absolutely.
There were a few maintenance things I was going to crack on with but wanted
to check with you.
Currently, the project doesn't seem to have any kind of CIT integration.
Mind if I set it up with Travis? That way the existing test suite gets run
on new PRs and whenever anyone pushes to the repo.
+1 go for it
Formatting is not always consistent especially with the windows code. I can
try and come up with some rules based on the general style of the code and
run it through an automated formatter?
I've read that it's risky to do bulk formatting changes, but have never
tried it personally. I'm okay with it as long as there are no other changes
mixed in with the style changes.
Are you adverse to Doxygen (code documentation tool)? We tend to use this
style of function headers https://github.com/FreeRADIUS/
freeradius-server/blob/v4.0.x/src/lib/ldap/connection.c#L196. One of the
nice things about Doxygen is clang can perform validation of the Doxygen
headers, and warn you when they don't match the observed arguments.
Neat, I didn't know that. I'm fine with using Doxygen comments.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#40 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGUw4GTjXWt8qECZDh1GPeUbp27VLE1Mks5s6se9gaJpZM4QpHuz>
.
|
|
OK, there's now a |
|
Thanks! I turned on Travis CI integration and verified that it is working.
https://travis-ci.org/mheily/libkqueue
…On Tue, Nov 28, 2017 at 7:02 AM, Arran Cudbard-Bell < ***@***.***> wrote:
OK, there's now a .travis.yml file in the repo (tested on my repo:
https://travis-ci.org/arr2036/libkqueue/builds/308392873). You just need
to turn on Travis builds for this repo at https://travis-ci.org/. You
should be able to login with your GitHub credentials.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#40 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGUw4B5GdHk4WULMoApHWW9BI_KD-qp1ks5s6_ZYgaJpZM4QpHuz>
.
|
arr2036
changed the title
|
Debian packaging for libkqueue updated: mheily/debian-packages#1 |
The FreeRADIUS project has adopted libkqueue as the primary eventing system on Linux and Solaris.
We now have four outstanding pull requests for various issues, but haven't see any response from the maintainer (@mheily). He does not appear to have been active since January this year.
We would rather not have to fork this project to continue development, but as the number of unpatched issues increases, the difficulty on maintaining multiple pull requests in parallel will force us to do so.
In the mean time, our temporary fork is available here: https://github.com/FreeRADIUS/libkqueue
It contains fixes for outstanding issues we've identified. If users/developers also working with/submitting patches to libkqueue, they may also wish to open a pull request against our repository.
If our temporary fork becomes permanent (six months from now if no response from @mheily is received), then we'll also pull in any outstanding fixes from this repository.
FreeRADIUS was founded in June 1999 by Miquel van Smoorenburg and Alan DeKok. The first public "alpha" release of the code was in August 1999, with 0.1 being released in May 2001. Since then, new versions have been released every few months.
FreeRADIUS is used daily by 100 million people to access the Internet.
The project has grown to include support for more authentication types than any other open source server. It is used daily by 100 million people to access the Internet. There are over 50 thousand sites using FreeRADIUS, ranging in size from 10 users to over 10 million users.
The text was updated successfully, but these errors were encountered: