Today, we hit 50% closed bugs for the v1.4 release cycle. My congratulations to everyone for pitching in, coding, testing, and breaking things, as things are looking a great deal more stable *and robust* than they were only a week or two ago. I am always amazed at herbert's productivity, and interduo's ability to break things, and at the NZ teams´ willingness to test in production stuff that merely compiles.
Tomorrow (thursday) at 1PM PST we have a meeting to discuss the state of the project. Presently we have not picked a technology (most of our work has moved to our #libreqos:matrix.org chat room) to have that in, I used to use my public galene server. So the cup is half full now. Or as I in general, tend to channel eyore, half empty. Of the remaining 28 bugs, many are in states of completion in the 80-99.99% range. Some are kind of complex and ideally the non-done bit, could get pulled out, and re-bugged (is that a word?). Others are overly vague. Others can just be punted to the next release. The schedule for the next release has already been slipped to march 31st, rather than March 7th. There seems to be some architectural rework needed as well, which is something that often happens at this stage of the project, where going forward, requires a step or two back. If half the folk on this list could review the bottom half up, and the other half, top half down, of what remains, we could meet in the middle: https://github.com/LibreQoE/LibreQoS/milestone/1 And for those of you that have not been tracking progress so far, please see: https://github.com/LibreQoE/LibreQoS/milestone/1?closed=1 And for those of you here that had a grand dream of THE KILLER FEATURE that will bring all ISPs more sleep and profits, and the devteam a paycheck... we have punted a great deal of stuff already to the v1.5 release: https://github.com/LibreQoE/LibreQoS/milestone/3 or a complete blocker for their adoption of v1.4... and have not communicated what it is - More suggestions for that or future milestones welcomed on this list, or on the github, or via the chat room. I would love a definition of the killer feature(s) for this release that works. Herbert´s new bifrost bridge in particular is benching out at 30% or more faster than the original code. Donations are being accepted on our github sponsors page, if you or some org you know of, is willing to pitch in, as we slog forward. We are in need of a decent javascript programmer in particular, and at least one more python and rust programmer as well, if you know anyone. We are also on a quest to find someone(s) that can help move some high speed routines to c and rtnetlink. -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
