Release Meeting: 06 Jan 2020

<JulianLevens>  Hi
<MichaelDaum>   Hi Julian
<MichaelDaum>   Happy New Year
<JulianLevens>  Happy new year to you too
<uebera||>      Happy New Year from me as well; I'm in a conf call, so will likely have to look through the log later tonight…
<JulianLevens>  Ok, IIRC we're targeting a 2.2 release
<JulianLevens>  And/Or 2.1.7
<MichaelDaum>   yes. we first need a 2.1.7 release with fixes piling up. 
<MichaelDaum>   before we can do so we need to fix unit tests. 
<JulianLevens>  Ok
<JulianLevens>  From my point of view I also need to start building a 2.1.7 release, just to get the hang of it
<JulianLevens>  And then do it all again once test cases etc completed
<JulianLevens>  Does anybody have anything else to add?
<uebera||>      \o/ survived the conf call
<uebera||>      In the course of the year, we should ensure that all supported versions of foswiki support updates via https; that was the dealbreaker a few years(?) ago when we originally wanted to prevent http access on f.o
<uebera||>      IIRC, George (gac410) -- or was that Lavr? -- pointed out that a number of Linux distributions (CentOS) require additional/newer libraries for this.
<uebera||>      OTOH, remember that http is now considered "bad" by a lot of major players… so the necessary requirements should be reasonable.
<MichaelDaum>   not sure what the reasoning behind keeping http was
<MichaelDaum>   as I remember it is related to the extension updater part of ConfigurePlugin
<uebera||>      Yes, George mentioned that he could not download extensions with the redirect in place.
<MichaelDaum>   the argument how bad updating over http is was not strong enuf those days.
<MichaelDaum>   Imho, we should enforce https even if it breaks installation for some. This for the better for those that have a working tls setup in place ... as is the case with most distros nowadays.
<uebera||>      Which versions of Foswiki/Perl are "officially" supported at them moment, btw?
<uebera||>      s /them/the/
<MichaelDaum>   https://foswiki.org/System/SystemRequirements says 5.8.8 or higher ... which is far too old as a perl release
<MichaelDaum>   the last 5.8.x release is 14 years ago
<MichaelDaum>   correction, 12
<uebera||>      Given that it should be possible to install extensions manually (and download them manually using https), maybe it's good enough if we give a warning (blog post, mailing list posting, XING group reference) and tell users that we're going "https only" in Q2/2020 or so…
<MichaelDaum>   we could couple this with the 2.1.7er release
<MichaelDaum>   and we should up the min perl version required
<uebera||>      good idea. Do we have a "how to install extensions from local archives" topic with an explanation?
<uebera||>      This we should overhaul, if needed.
<uebera||>      http->https proxies should not be a huge problem, either (if someone does not want to upgrade).
<uebera||>      Is the installer hard-wired to only access f.o? If we document how to change that (at the user's own risk), it should be good enough.
<uebera||>      But even this is not needed if the admin knows about "split horizon dns" and just assigns a temporary IP address for f.o -- as long as it's http, this should be rather straightforward.
<MichaelDaum>   not much different to the typical man in the middle attack that we want https to prevent in the first place
<uebera||>      exactly.
<MichaelDaum>   :D
<uebera||>      Given the new machine, maybe not for the 2.1.7 release, maybe we can run multiple instances of t.f.o with different perl versions as well (from within a container). Current kernels are good ad re-using libraries anyways, so it should not be a RAM issue.
<MichaelDaum>   why would you want to run different perl versions?
<MichaelDaum>   for testing purposes only?
<uebera||>      Yes.
<MichaelDaum>   that can be achieved much easier using perlbrew or plenv
<uebera||>      Maybe not 26 flavors like I have on my NUC (5.8.9 .. 5.30.1 w/ and w/o thread-multi), but maybe with the newest available version.
<uebera||>      We're using plenv on f.o already, but with a single version of perl atm.
<MichaelDaum>   so easy then: plenv install 5.24.1; plenv migrate-modules <cur-version> 5.24.1; and then switch between versions running unit tests
<uebera||>      Speaking of plenv itself--IIRC, I was unable to update it on f.o. Need to look at the logs I kept.
<MichaelDaum>   cd <foswiki-dir>/test/bin; plenv local 5.xxx; ./TestRunner...
<MichaelDaum>   btw I am running on 5.30.1 on a daily base
<uebera||>      Me too. I was just too lazy to update f.o as well (because I was unsure, too, whether the "old" plenv on f.o would support it).
<uebera||>      Personally, I prefer perlbrew.
<uebera||>      Should not differ much, but the latter works for me and I found that first.
<MichaelDaum>   you might need to pull inside .plenv , as well as .plenv/plugins/perl-build/
<MichaelDaum>   to get the latest build scripts
<uebera||>      Ok… dinner time… see you soon. (We used to have protocols for release meetings as well in the past, right? Will need to locate those so that we can summarize the above (-) infrastructure related topics which go elsewhere.)