time to tag/release 2.20? #185
Comments
|
Same. Also I'd like AdvCaptivePortalAPI to get into distros. |
|
@robbat2, @stappersg: I think it is needed before Debian 12 freeze. |
|
I believe a new release is needed since the last one was more than two years ago. Pref64 being one of the lastest additions and some bug fixes. |
|
+1 😋 |
|
Is there a roadmap to be satisfied before the tagging of a new release? Seems like there's been a lot of development in the main branch since the last release 2 years ago. Or is it the expectation that downstream distributions should start building from git rather than tagged releases at this point? |
|
+1 |
|
Yes, I'd like to get RemoveAdvOnExit into freebsd ports |
|
Ping. Is there anything we could help with getting a released version with all new features? |
|
@robbat2: More and more people request a new build, the latest current build is 2.19 (2020-09-20). The current changes, 114 commits: Contributors since 2.19 (in more you) :) Thanks in advance. cc @reubenhwk (old maintainer) |
|
It's been a few years since I've been active on this project, but no, there
was no formal roadmap to be satisfied before cutting a release. I cut
releases when it had been long enough and there had been enough changes.
It's clearly been long enough, and there have been plenty of changes.
I'll poke around a bit...seems like I left some docs somewhere describing
the process of building the archives and updating the website.
…On Sat, Nov 11, 2023 at 8:50 PM Reuben Hawkins ***@***.***> wrote:
Is anybody on this? 2.20? I didn't see a "yes" in the thread.
On Sun, Nov 5, 2023 at 8:19 AM Neustradamus ***@***.***>
wrote:
> @robbat2 <https://github.com/robbat2>: More and more people request a
> new build, the latest current build is 2.19 (2020-09-20).
> I think it is good to do a 2.20, can you do it?
>
> The current changes, 114 commits:
>
> - v2.19...master
> <v2.19...master>
>
> Contributors since 2.19 (in more you) :)
> @nomis <https://github.com/nomis>, @stappersg
> <https://github.com/stappersg>, @robbat2 <https://github.com/robbat2>,
> @RICCIARDI-Adrien <https://github.com/RICCIARDI-Adrien>, @haegar
> <https://github.com/haegar>, @samboyles1 <https://github.com/samboyles1>,
> @steglicd <https://github.com/steglicd>, @jpds <https://github.com/jpds>,
> @andrew-sayers <https://github.com/andrew-sayers>, @juhamatk
> <https://github.com/juhamatk>, @manonfgoo <https://github.com/manonfgoo>,
> @gaoxingwang <https://github.com/gaoxingwang>, @yas-nyan
> <https://github.com/yas-nyan>, @zajdee <https://github.com/zajdee>,
> @initramfs <https://github.com/initramfs>, @kepstin
> <https://github.com/kepstin>, @prometheanfire
> <https://github.com/prometheanfire>, @thesamesam
> <https://github.com/thesamesam>, @mpontillo
> <https://github.com/mpontillo>, @jetomit <https://github.com/jetomit>
>
> Thanks in advance.
>
> cc @reubenhwk <https://github.com/reubenhwk> (old maintainer)
>
> —
> Reply to this email directly, view it on GitHub
> <#185 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABRG62BPKDNPKLBCHIWBSDYC6N5LAVCNFSM56SIXISKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGM3TKMBYGA4Q>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Ok if nobody disagrees, I'll push a 2.20 tag, but I think I will skip
updating the old website and uploading packages.
…On Sat, Nov 11, 2023 at 8:57 PM Reuben Hawkins ***@***.***> wrote:
It's been a few years since I've been active on this project, but no,
there was no formal roadmap to be satisfied before cutting a release. I
cut releases when it had been long enough and there had been enough
changes. It's clearly been long enough, and there have been plenty of
changes.
I'll poke around a bit...seems like I left some docs somewhere describing
the process of building the archives and updating the website.
On Sat, Nov 11, 2023 at 8:50 PM Reuben Hawkins ***@***.***>
wrote:
> Is anybody on this? 2.20? I didn't see a "yes" in the thread.
>
> On Sun, Nov 5, 2023 at 8:19 AM Neustradamus ***@***.***>
> wrote:
>
>> @robbat2 <https://github.com/robbat2>: More and more people request a
>> new build, the latest current build is 2.19 (2020-09-20).
>> I think it is good to do a 2.20, can you do it?
>>
>> The current changes, 114 commits:
>>
>> - v2.19...master
>> <v2.19...master>
>>
>> Contributors since 2.19 (in more you) :)
>> @nomis <https://github.com/nomis>, @stappersg
>> <https://github.com/stappersg>, @robbat2 <https://github.com/robbat2>,
>> @RICCIARDI-Adrien <https://github.com/RICCIARDI-Adrien>, @haegar
>> <https://github.com/haegar>, @samboyles1 <https://github.com/samboyles1>,
>> @steglicd <https://github.com/steglicd>, @jpds <https://github.com/jpds>,
>> @andrew-sayers <https://github.com/andrew-sayers>, @juhamatk
>> <https://github.com/juhamatk>, @manonfgoo <https://github.com/manonfgoo>,
>> @gaoxingwang <https://github.com/gaoxingwang>, @yas-nyan
>> <https://github.com/yas-nyan>, @zajdee <https://github.com/zajdee>,
>> @initramfs <https://github.com/initramfs>, @kepstin
>> <https://github.com/kepstin>, @prometheanfire
>> <https://github.com/prometheanfire>, @thesamesam
>> <https://github.com/thesamesam>, @mpontillo
>> <https://github.com/mpontillo>, @jetomit <https://github.com/jetomit>
>>
>> Thanks in advance.
>>
>> cc @reubenhwk <https://github.com/reubenhwk> (old maintainer)
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#185 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AABRG62BPKDNPKLBCHIWBSDYC6N5LAVCNFSM56SIXISKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGM3TKMBYGA4Q>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***>
>>
>
|
|
On Sat, Nov 11, 2023 at 07:19:09PM -0800, reubenhwk wrote:
On Sat, Nov 11, 2023 at 8:57 PM Reuben Hawkins wrote:
> It's been a few years since I've been active on this project,
> but no, there was no formal roadmap to be satisfied before cutting
> a release. I cut releases when it had been long enough and there
> had been enough changes. It's clearly been long enough, and there
> have been plenty of changes.
>
> I'll poke around a bit...seems like I left some docs somewhere
> describing the process of building the archives and updating the
> website.
Ok if nobody disagrees, I'll push a 2.20 tag,
Not any disagreement, but a very strong wish: Sign the release
but I think I will skip updating the old website and uploading packages.
Fully agreed.
Groeten
Geert Stappers
--
Silence is hard to parse
|
|
Yes Please! Thanks alot for this
From: Geert Stappers ***@***.***>
Reply to: radvd-project/radvd ***@***.***>
Date: Sunday, 12. November 2023 at 09:54
To: radvd-project/radvd ***@***.***>
Cc: manonfgoo ***@***.***>, Mention ***@***.***>
Subject: Re: [radvd-project/radvd] time to tag/release 2.20? (Issue #185)
On Sat, Nov 11, 2023 at 07:19:09PM -0800, reubenhwk wrote:
On Sat, Nov 11, 2023 at 8:57 PM Reuben Hawkins wrote:
> It's been a few years since I've been active on this project,
> but no, there was no formal roadmap to be satisfied before cutting
> a release. I cut releases when it had been long enough and there
> had been enough changes. It's clearly been long enough, and there
> have been plenty of changes.
>
> I'll poke around a bit...seems like I left some docs somewhere
> describing the process of building the archives and updating the
> website.
Ok if nobody disagrees, I'll push a 2.20 tag,
Not any disagreement, but a very strong wish: Sign the release
but I think I will skip updating the old website and uploading packages.
Fully agreed.
Groeten
Geert Stappers
--
Silence is hard to parse
—
Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABTP25FC3QIWECAXLJFCFSLYECFEJAVCNFSM56SIXISKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQG4YDMMBXGEZA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I'll tag a release candidate version after #210 is approved & merged. I heard a non-public report that newer kernels might have an interaction, so I want to force more testing rather than saying "this is a good public release" - plus we have outstanding issues where we have asked users to test, and they never got back to us. |
|
@robbat2 has done a 2.20 RC1 release tag: Can you try and please do a feedback? |
I've flagged this as out-of-date in Alpine Linux edge in the hope it can be brought into edge, or into the testing repo so I can do some testing in my production environment that's based around Alpine Edge. If not, I'll try and build this manually at some point soon and do some testing, though I'd need to find more time for that. |
Please change versioning convention. |
|
@kloczek why has GNOME moved away from decades of using -/_ for the Gentoo for example codified common upstream practices to have the underscore separating the core version number. |
|
Separately, we need to improve the automation to upload proper dist tarballs, since the GitHub release system automatically used the tip of the tree, rather than the files I wanted to upload. |
FWIW, I'm fine with Less subtle: Don't bother about release candidates. |
Because:
Both reasons are to make versioning packaging friendly. |
That is why better is use sequence |
|
My initial testing suggests this builds and is stable on Alpine Linux edge, and I've been able to test and validate that PREF64 extensions are working, as a particular feature which was added between 2.19 and 2.20_RC1
I'm pleased to note that this also builds without needing fix-alpine-plz.patch which Alpine was shipping as a backport of a fix (06689f8) which was added after 2.19 was tagged. I'll continue to run this for a while and report back if anything turns up. |
|
Where are we at on testing for this one? Is there anything to be satisfied before bringing 2.20 out of RC status? I notice #227 and #222 are open and were opened after the RC was tagged, but #227 is explicitly marked as needing to wait until after the current release, and I can't see #222 as a showstopper that would block release. |
|
Any luck in getting this released? My impression is that its stable and getting an official release would be necessary for integrating RFC 8781 into VyOS nightly builds. |
|
I've been doing some testing of this as I am quite keen on the PREF64 support and it all seems happy under Linux (Debian 12), but FreeBSD 14 still needs the patches discussed in #145 from their ports repo or RADVD doesn't consistently respond to RA solicitations. Not much is needed and it all seems happy on FreeBSD 14. |
|
@robbat2: It is a good time to do it? cc: @reubenhwk. |
|
Thank you for your work on radvd! We're now past the one year anniversary of 2.20-rc1. Any news here? Any way folks can help? |
|
@robbat2, @stappersg, @reubenhwk: It important to have improvements before Debian 13 freeze. |
|
@Neustradamus i'm not seeing any announced freeze from Debian Release Management? https://release.debian.org/ |
|
Like every time, it will begin in January, it will be in January 2025, in few weeks: |
|
Latest release tag is from 2021, so I'm ready for a new release :) |
|
Help with "github.com actions", #236, is appreciated. |
|
Hi ! Let's have a look ! |
|
Dear all, Before 2.20, it will be nice if you can help to solve some Issues/PRs: Recall, some weeks ago, I have done a comment here: @agowa, @AdSchellevis, @fichtner, @marjohn56, @bmeirellesRJ, @mhanor, @stu-gott, @wcbonner, @the-j0k3r, @WenChao1Hou, @BrainSlayer, @Mile-Lile, @bnutzer, @stu-gott, @MarioVerbelen, @ruben-herold, @ipilcher, @pyk1998, @romanrm, @corvus1, @ihipop If you know some IPv6 specialists, please come here, there are several tickets, thanks in advance. |
|
Dear all, What do you think about the changes from RFC8319: Support for Adjustable Maximum Router Lifetimes per Link: Updates to RFC 4861 In source: |
|
https://datatracker.ietf.org/doc/html/rfc8319#section-3 This section makes unrealistic assumptions about multicast packet loss. Due to a desire for power savings many (most?) battery powered devices (like phones, tablets) have a wifi dtim multiplier > 1 (possibly even as high as 9) which results in multicast/broadcast loss being as high as 90% (though such devices basically just cannot be made to work well with ipv6). [Note: the dtim multiplier usually also depends on the wifi AP dtim interval, but far too many APs use a value of 1 for the interval, instead of using 3 or even 6 - likely due to bad defaults in hostapd] More reasonable devices top out at a dtim multiplier of just m=2, and suffer from 'only' (m-1) / m = 50% multicast (and thus unsolicited RA) loss. As such K needs to be not 3, but more like 15+. All lifetimes in the RA should be at least K times the MaxRtrAdvInterval. For power savings reasons you also don't want (any) lifetimes to be below 30 minutes, and ideally closer to 2-3 hours (or more). As such wrt. https://datatracker.ietf.org/doc/html/rfc8319#section-4:
sure.
doesn't hurt, but not at all useful.
sure. But the real changes should be to the K=3 multipliers, ie. MinRtrAdvInterval AdvDefaultLifetime |
I'm not sure it does make unreasonable assumptions at all, given modern networking practices. Multicast on 802.11 networks happens at the minimum data rate of the network, which can potentially be set to sub 10 Mbps. This means it's usually faster to do multicast-to-unicast conversion for WiFi, and many access points do this by default. Whether they do this for IPv6 RAs or not is very much down to implementation... RFC9119 has some discussion on the topic. |
In my view they asked to just tag 2.20 to solidify the current state and have already implemented features get into distros (as there has not been a release in 3 years). It is not feasible to expect to "quickly" solve all the outstanding issues collected over all that time before making the release. Else this can take another 3 years easily. |
I actually agree here. Normally, it's better to take the more "Agile" approach, by releasing more often with smaller releases, and thus smaller iterations. Instead of trying to release one big release every 5 year. This also ensures that you receive timely feedback, which you could include in the new release. |
|
I know, I prefer to have several release builds... but currently some are "easy" to fix:
Maybe some can help about:
What do you think about this one: |
|
FWIW, did a bit of testing in OPNsense/FreeBSD and the current development state seems fine. Found just a small thing in the form of a warning during compile #242 |
|
On Mon, Dec 09, 2024 at 04:30:26AM -0800, Franco Fichtner wrote:
FWIW, did a bit of testing in OPNsense/FreeBSD and the current
development state seems fine. Found just a small thing in the form of
a warning during compile #242
Nice.
And yes, I hope to see more "works for me" to this issue
(insteadof opinions, feature requests and "there should be ...").
Groeten
Geert Stappers
--
Silence is hard to parse
|
in particular I'm interested in getting pref64 into fedora...
The text was updated successfully, but these errors were encountered: