On 12/23/19 6:23 AM, Roberto C. Sánchez wrote: > On Sun, Dec 22, 2019 at 08:20:47PM -0800, Tom Eastep wrote: >> >> >> On 12/22/19 4:23 PM, Roberto C. Sánchez wrote: >>> On Fri, Dec 20, 2019 at 10:05:04AM +0200, Tuomo Soini wrote: >>>> On Thu, 21 Nov 2019 14:00:31 -0500 Bill Shirley >>>> <b...@ultrapoly.polymerindustries.biz> wrote: >>>> >>>>> 2) For the SNAT ACTION on the snat man page, there is an >>>>> example using IPv4 addresses: Example: >>>>> 206.124.146.177-206.124.146.180 This example should probably >>>>> use IPv6 addresses. >>>>> >>>>> I was comparing the above with the documentation for Shorewall >>>>> 4.6, which is what I use (shorewall6-4.6.11.1-2.fc22.noarch), >>>>> to implement masquerading: >>>>> http://www.shorewall.net/manpages6/shorewall6-masq.html 3) >>>>> Under the ADDRESS directive, it has an error: Example: >>>>> [2001:470:a:227::2]-[2001:470:a:227::10]:1000-1010 Which >>>>> generates: ERROR: Correct address range syntax is >>>>> '[<addr1>-<addr2>]' /etc/shorewall6/masq (line 115) >>>>> >>>>> What actually works is: >>>>> [2001:470:a:227::2-2001:470:a:227::10]:1000-1010 Note: the >>>>> internal ']-[' should be just a dash '-'. >>>> >>>> Ok. That is really a bug in shorewall ipv6 range parser. >>>> >>> I have created an issue in GitLab to capture this: >>> https://gitlab.com/shorewall/code/issues/3 >>> >> >> And I have coded and tested a fix. From this point forward, I think >> that I would like to submit fixes to gitlab, but let it be the new >> team who decides when to release either point releases or new >> minor/major releases. I will keep the fix in my local repository until >> the direction is clear. >> > Tom, > > I'd like to see if we can exercise the merge request process. Would you > be willing to submit your proposed change as a merge request? >
Roberto, I certainly can -- I have several 5.2.3 patches queued up which I can push to the 5.2.3 branch on Gitlab. They will then show up there as merge requests (I've done that before). Going forward, how do we want to handle updates to the known problems, change log and release notes? Traditionally, I have updated known problems when I have identified a problem then I update that document again when I am preparing a release (to indicate which release the defect is corrected in). I typically update the change log and release notes periodically during the release cycle for both features and bug fixes. If we are going to submit changes as merge requests, then maybe updates to the release documents should be submitted along with the code change itself. That could be done by including the text in the commit message body or by submitting a companion update the the release repository. I don't have a strong opinion either way, but the latter approach would result in less work for whoever ends up doing the final release work. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
