Release Meeting: 20 Jan 2020

<JulianLevens>   Hi
<MichaelDaum>   Hi Julian
<JulianLevens>   Did anybody log the last meeting?
<MichaelDaum>   my irc client logged it, as well as slack.
<JulianLevens>   Could you send that too me please?
<MichaelDaum>   or would you like to have it uploaded to a foswiki topic
<JulianLevens>   Uploaded is good
<MichaelDaum>   can you create a topic for the release meeting?
<uebera||>   +1
<MichaelDaum>   only 56 lines
<JulianLevens>   https://foswiki.org/Development/ReleaseMeetingNotesx2x17
<MichaelDaum>   Let's clean up https://foswiki.org/Development/ReleaseMeetingTemplate and use it for further release meeting notes. all previous ones are listed here https://foswiki.org/Development/ReleaseMeetings
<JulianLevens>   Thanks for those links and I agree
<uebera||>   Why "x2x17", btw?
<JulianLevens>   Next release number
<JulianLevens>   Just 1st think I thought of
<MichaelDaum>   I'd rather keep it ReleaseMeeting20200106 etc
<MichaelDaum>   for the prev one
<uebera||>   Ah, just realized it.
<uebera||>   Yes.
<uebera||>   Easier to find.
<JulianLevens>   Keep to existing standards
<JulianLevens>   I have nothing to report today, anybody else?
<MichaelDaum>   how about we review open task items blocking the release
<MichaelDaum>   as well as decide on release dates for 2.1.7 and 2.2.0
<MichaelDaum>   let's collect all action items required to make a 2.1.7
<JulianLevens>   Ok
<MichaelDaum>   meanwhile I created a button to create a new release meeting topic at https://foswiki.org/Development/ReleaseMeetings
<JulianLevens>   Thanks
<MichaelDaum>   https://foswiki.org/Tasks/PatchReleaseBlocker
<MichaelDaum>   we've got lots of unit tests failing 
<MichaelDaum>   we need to fix em all
<MichaelDaum>   any thoughts?
<JulianLevens>   Nothing immediately
<JulianLevens>   I suspect it's just leg work
<JulianLevens>   At least at first, unless I spot any patterns
<uebera||>   I need to read the logs about https://foswiki.org/Tasks/Item14629 -- we've discussed that in the past.
<JulianLevens>   Is there a known common cause for some of these
<MichaelDaum>   wow
<uebera||>   JulianLevens: Not that I'm aware of.
<MichaelDaum>   isn't Item14629 already fully released in 2.1.6?
<JulianLevens>   It looks that way
<uebera||>   Why are Item14629, Item14639 still listed if they contain "Released in 2.1.6"?
<uebera||>   Also, was there a release for Foswiki 1.x?
<uebera||>   If not, we should decide to drop that part.
<MichaelDaum>   do we still support fixes for 1.x?
<uebera||>   I'd say we should stop doing that.
<JulianLevens>   +1
<MichaelDaum>   +1. in that respect we can close both of these tasks
<uebera||>   Item14629 maybe should be tagged for 2.2.0
<JulianLevens>   Agreed
<uebera||>   If there is still a plan to change the way webs are organised.
<uebera||>   Wasn't this related to the performance problem as well?
<MichaelDaum>   Item14629 checkins are only merges
<MichaelDaum>   from 2.1.x to 2.2.x branches
<uebera||>   Ah, no, it was about packaging. Also related to docker images, IIRC.
<uebera||>   Still need to browse through the logs, this must have been proposed elsewhere, but I don't see a reference.
<MichaelDaum>   imho Item14629 can be closed. there even is no use in marking it WaitingForRelease
<uebera||>   +1
<uebera||>   The "alternative solution" related to packaging should be earmarked somehow, but maybe we should re-analyse this--if there is no existing proposal. This is definitively nothing for 2.1.7, though.
<MichaelDaum>   you mean a Systemconfig web?
<uebera||>   Yes. Something which lets packagers modify settings without having to patch/diff everything.
<MichaelDaum>   thats why we have view templates
<MichaelDaum>   those topics should not be customized by includes but by view templates. but that definitely is not a 2.1.x change.
<JulianLevens>   No this needs an FP, I suspect we've all thought about this issue
<MichaelDaum>   ya
<MichaelDaum>   but first things first ... 2.1.7
<MichaelDaum>   I'll take care of the task items waiting for me. sorry for not having thought about them earlier.
<MichaelDaum>   Item14685 is an easy one
<MichaelDaum>   but what are your thoughts on https://foswiki.org/Tasks/Item14689
<JulianLevens>   Ouch
<MichaelDaum>   according to https://metacpan.org/pod/Email::Address#DESCRIPTION the issue seems to have been fixed in the meantime
<uebera||>   We should check the main distributions regarding the availability of https://packages.debian.org/de/sid/libemail-address-perl or the like.
<MichaelDaum>   y
<uebera||>   I can perform these checks within the next 14 days.
<MichaelDaum>   ok thanks
<MichaelDaum>   _maybe_ we are in luck and we can no-action this item
<JulianLevens>   Looks like there is a new version of Email::Address that fixes the problem
<MichaelDaum>   y
<JulianLevens>   Ok, we'll review this again next time
<MichaelDaum>   quick check on ubuntu 18.04: libemail-address-perl 1.908-1
<MichaelDaum>   bummers
<uebera||>   --> https://launchpad.net/ubuntu/+source/libemail-address-perl -- quite the variety
<MichaelDaum>   in general distributions are very late wrt anything perl
<uebera||>   Do we already require external *::XS modules? Because for this, you'd need existing packages or build tools.
<MichaelDaum>   no
<MichaelDaum>   we do however check for existing perl modules, such as the logger impl.
<MichaelDaum>   if a package is not there will the feature be disabled as well.
<MichaelDaum>   search for any eval...require
<uebera||>   But from the page above (and CentOS distributions in the wild which are even older, yet supported), it's easy to deduce that nothing has changed. Your 09 May 2018 proposal seems to be the safest option.
<uebera||>   "Better don't send emails at all than using code known to cause security issues."
<MichaelDaum>   .... was going to say again
<uebera||>   We can still check the logs w.r.t. "The ML mentions that FreeBSD and Debian distributions started removal of Email::Address module." -- given that https://packages.debian.org/de/sid/libemail-address-perl is still available, they must have reverted their decision.
<MichaelDaum>   maybe
<MichaelDaum>   btw there is a typo in Foswiki/Configure/Checker.pm b/core/lib/Foswiki/Configure/Checker.pm that prevents to check the minimumRequired version of a perl package
<uebera||>   But we cannot be sure about other distros/existing installations. So I'll look *at that*. If doubts remain regarding downstream fixes, we can implement your proposal.
<MichaelDaum>   lib/Foswiki/Contrib/core/DEPENDENCIES lists Email::Address,>1.00 ... changing this to 1.910 should generate a warning in bin/configure  ... does it?
<JulianLevens>   I'll have to test that
<JulianLevens>   Ref Item14628, that's connected to 14629 and will need an FP
<uebera||>   Does it as a security task?
<uebera||>   Ah, this part is in line with the "2.2.0 alternative solution" suggestion of 14628, right?
<JulianLevens>   Yes
<MichaelDaum>   I still don't like the %INCLUDE approach of customizing things.
<JulianLevens>   I need to to think about that whole problem
<JulianLevens>   I've not been active with FW for around two years
<uebera||>   Maybe 14628 was the reason that 14629 was not closed.
<JulianLevens>   I need to get back up to speed
<uebera||>   s /that/why/
<JulianLevens>   Why don't you like the %INCLUDE approach of customizing things
<MichaelDaum>   because view templates are much better.
<MichaelDaum>   just think about it: have a UserRegistrationViewTemplate with well organized TMPL:DEFs that any derived view template can override.
<JulianLevens>   I can see that works well
<MichaelDaum>   MySkinUserRegistrationViewTemplate starts with %TMPL:INCLUDE7{"UserRegistrationView"}% and the only redefines those bits in need of customization
<MichaelDaum>   ltnher
<JulianLevens>   I'm wondering if there's other sorts of local customization that is not so good for
<MichaelDaum>   otherwise you'd have to copy&paste UserRegistration
<JulianLevens>   No idea what right now, just wondering
<MichaelDaum>   we could have ChangeEmailAddressViewTemplate, ResetPasswordViewTemplate, UserRegistrationViewTemplate, WikiUsersViewTemplate, WikiGroupsViewTemplate, .... etc
<MichaelDaum>   WebTopicListViewTemplate ... current WebTopicList have an INCLUDE everywhere
<MichaelDaum>   WebSearchViewTemplate
<MichaelDaum>   WebAtomViewTemplate, WebRssViewTemplate, WebNotifyViewTemplate , WebChangesViewTemplate
<uebera||>   The question is: If we introduce this, can this be done w/o breaking *all* existing installations? I.e., will this be transparent unless installations already modified/overrode these? And how many potential cases are there?
<MichaelDaum>   WebRss and the like all need a VIEW_TEMPLATE setting ...
<MichaelDaum>   or we use AutoTemplatePlugin which lets you add a view template from within LocalSite.cfg for a specific topic
<MichaelDaum>   ...a FP not accepted some decades ago
<MichaelDaum>   https://foswiki.org/Development.RulebasedViewTemplates
<uebera||>   Could the latter be a temporary solution unless we revamp everything, then?
<uebera||>   s /unless/UNTIL/
<uebera||>   But I need to read the discussion and think about that first… too much text.
<MichaelDaum>   actually RulebasedViewTemplates let us backport view templates for all of the above guys with ease
<MichaelDaum>   as well as let people decide on their own customized INCLUDE based code
<JulianLevens>   I need to take time on this, need to defer to next meeting
<MichaelDaum>   ok
<JulianLevens>   Item14802?
<MichaelDaum>   working on it
<JulianLevens>   ok
<JulianLevens>   I think we're done reviewing tasks for 2.1.7
<MichaelDaum>   and I am running out of time for 2day
<JulianLevens>   Me too
<MichaelDaum>   let's revisit these tasks next rm
<JulianLevens>   Ok thanks everyone
<MichaelDaum>   I'll upload the logs