Release Meeting: 18 Sep 2017

(09:01:35 AM) gac410: Hi everyone    
(09:02:23 AM) JulianLevens: Ay up
(09:03:14 AM) gac410: Ready to start?
(09:04:05 AM) JulianLevens: y
(09:04:24 AM) gac410: 1)   Urgent Task Review
(09:04:56 AM) MichaelDaum: Hi there
(09:06:49 AM) gac410: There was one - http://foswiki.org/Tasks/Item14445    Excel can't handle the 401 return when authentication required.  Task says we should return 200. 
(09:07:32 AM) MichaelDaum: yes
(09:07:51 AM) MichaelDaum: reading up on the history of this change I think what we did went a little bit over the top
(09:08:13 AM) MichaelDaum: not that I want to excuse excel for its flaws
(09:08:45 AM) MichaelDaum: but we have to live with excel, and people wanting to link to their wiki from within office documents
(09:09:01 AM) gac410: IIRC the rfc's state that you only can return a 401 if you also include the Authentication header to cause authentication to happen.    so i'm not sure we are correct returning a 401 anyway
(09:09:17 AM) MichaelDaum: yes we are 
(09:09:39 AM) MichaelDaum: it has got a basic auth challenge in it
(09:10:05 AM) MichaelDaum: point is we don't _have_ to return a 401
(09:10:31 AM) MichaelDaum: note that initially we only were talking about REST calls needing authentication
(09:10:54 AM) gac410: right,  and UI::Rest does it's own thing anyway. 
(09:11:16 AM) MichaelDaum: hm, where was the feature request ...
(09:11:57 AM) gac410: for the 401 vs 200?  I'll have to dig for it again.  I remember a long discussion over that a long time ago.
(09:12:39 AM) MichaelDaum: https://foswiki.org/Development/Use401ForCookieAuth
(09:13:02 AM) MichaelDaum: is that the right one?
(09:14:19 AM) gac410: y  I think so
(09:16:15 AM) MichaelDaum: the bulk of the changes for this feature is implemented in https://github.com/foswiki/distro/commit/b193c40c72710f8a98586e53992e5df6a2e9215a
(09:16:27 AM) gac410: I hesitate to suggest this but ... as the 401 is "correct"  and we are working around an excel / MS bug,   I thnk that this should be configurable.  :(
(09:17:37 AM) MichaelDaum: my reasoning goes as follows: 401 is only of use for REST calls, but not for any other action, i.e. VIEW
(09:18:14 AM) MichaelDaum: that's the change I'd like to propose: keep 401 for REST but not for the rest
(09:18:41 AM) gac410: well Rest and Jsonrpc  (any mechanized login)   view login does return a normal html page, so it probably should be a 200 anyway.
(09:19:29 AM) gac410: I've seen a similar related bug on some browsers.  Where I would get a "useless" browser login prompt,  which I canncel,  to then get the template login.
(09:19:50 AM) gac410: It was one of the alternative cell phone browsers which I now can't remember
(09:20:26 AM) gac410: Ah... Dolphin browser.   Ages ago when I was using it,  I always got a double-login on trunk 
(09:21:29 AM) gac410: Apache login will still work ... I hope ... because the login mechanism happens due to the auth scripts match, and foswiki never sees it.
(09:21:53 AM) MichaelDaum: makes sense: the basic auth challenge triggers the browser popup ... just to render foswiki's own ui to log in.
(09:22:37 AM) gac410: y.   It was really annoying and I didn't relate it to our 401 response at the time.
(09:23:20 AM) MichaelDaum: note that UI::Rest will trigger its own 401 in case the REST handler requires authentication ... no matter what login manager is configured
(09:23:47 AM) gac410: Right.   I think I looked at that last time we discussed this.
(09:24:55 AM) MichaelDaum: so from what I see setting the 401 in TemplateLogin.pm can simply be dropped.
(09:25:17 AM) gac410: I think it's okay go go ahead with this change.   *Template* login should return 200 when displaying the login page.   Scripts that don't want a html page would continue to return a 401
(09:25:56 AM) MichaelDaum: okay. let's record this decision in the task.
(09:26:07 AM) gac410: Okay.  Sounds good.
(09:26:09 AM) vrurg: Hi!
(09:26:14 AM) gac410: Hi vrurg
(09:26:30 AM) gac410: Any other urgent tasks?   
(09:28:44 AM) gac410: Okay.   New  Feature proposals
(09:29:17 AM) gac410: 1)  https://foswiki.org/Development/AddJsViews      43 days on timer.   Accepted proposal?
(09:29:32 AM) gac410: Michael are you bringing that one forward?
(09:29:59 AM) MichaelDaum: yes I will
(09:30:15 AM) gac410: Okay.   I'll fix up the state of it to reflect that.
(09:31:03 AM) gac410: Okay,  next,  I am considering adding another password hash mechanism   to make our .htpasswd file more resistant to cracking    No proposal yet.
(09:31:34 AM) gac410: https://metacpan.org/pod/Crypt::PBKDF2
(09:31:59 AM) MichaelDaum: +1
(09:32:02 AM) gac410: It would just be another alternative like bcrypt.   Don't know if it needs a proposal or it's a minor enhancement ... if I go ahead
(09:32:46 AM) MichaelDaum: only thing to take under consideration is the extra cpan dependency on Crypt::PBKDF2
(09:33:17 AM) gac410: I'd treat it like bcrypt.   If dep is not installed, then the option isn't selectable.    No new dependency by default.
(09:33:41 AM) MichaelDaum: sounds good 
(09:33:47 AM) JulianLevens: +1
(09:34:11 AM) gac410: I think it's minor enough to make it on a Task rather than a feature proposal.
(09:35:01 AM) gac410: And next..   Really needs CDot.      But he unzipped the TinyMCE "deveopers" code into our git repo  to help with development.    It probably ought to be a git submodule linking to the tinymce repo.
(09:35:06 AM) MichaelDaum: yes please. let's not create red tape just for the sake of it
(09:36:17 AM) gac410: I'll table that one until cdot is online.  Doesn't really effect foswiki at all.
(09:37:05 AM) gac410: It may make for some git pain.   If you've got a repo based on master,   then the pub/TinyMCEPlugin/tinymce_dev    directory will conflict with the same directory name implemented as a submodule.
(09:37:29 AM) gac410: Until the repo is synced with master and the conflict goes away.
(09:37:54 AM) gac410: That's the main reason to bring this up here.
(09:39:39 AM) gac410: and last "new feature"  ... this one probably should have a proposal  :(     Add a "body" zone as a standard zone in the foswiki.tmpl and foswiki.pattern.tmpl   to bring it into alignment with NatSkin. ... Plugins needing body zone fail on pattern skin. 
(09:40:06 AM) gac410: It's a one-line change to the foswiki.pattern.tmpl
(09:40:32 AM) gac410: https://foswiki.org/Tasks/Item14488
(09:41:07 AM) MichaelDaum: ... to inject stuff right before the closing </body> tag ... such as google analytics, or any other 3rd party scripts such as zopim live chat
(09:42:30 AM) gac410: It seems like a very reasonable change.  I'm tempted to just do this one on a task too.  Completely transparent unless you actually add to the body zone.
(09:43:40 AM) MichaelDaum: needs some docu fixes too in VarADDTOZONE, VarRENDERZONE
(09:43:48 AM) gac410: Right.   
(09:44:06 AM) MichaelDaum: can we move on?
(09:44:12 AM) gac410: yes
(09:44:33 AM) gac410: anything else on feature discussions?
(09:44:39 AM) MichaelDaum: UpdatesPlugin and HistoryPlugin are marked as waiting for release 2.1.5 ... as they both have issues
(09:45:20 AM) gac410: Are the commits in Release02x01 too?    I noticed you committed them to master initially :(
(09:45:26 AM) MichaelDaum: y
(09:45:42 AM) MichaelDaum: cherry-picked em after noticing it
(09:46:21 AM) gac410: We *can* release plugins between patch releases.   There are almost no 2.1.5 fixes yet.   So not worth a full release.  
(09:46:22 AM) MichaelDaum: foswiki.org already shows the error in UpdatesPlugin for admins
(09:46:39 AM) MichaelDaum: yes. that's what I wanted to ask.
(09:46:40 AM) gac410: y.   I've noticed that.   That was probably my (lack of) javascript skills.
(09:48:03 AM) MichaelDaum: let's update the plugin on foswiki.org for a test
(09:49:06 AM) gac410: okay.   I'll build them and upload to testing  for now.
(09:49:17 AM) MichaelDaum: excellent
(09:49:54 AM) gac410: Feature propsals discussion ... going once ... going twice ...   
(09:50:37 AM) gac410: Next up .   Release calendar.   Nothing changes here.   We agreed on Dec 1 feature freeze.   This will be the last freeze before 2.2   Train leaves station this time around.
(09:51:01 AM) gac410: Hopefully late Dec. beta,   and release of 2.2 in Jan/Feb timeframe. 
(09:51:35 AM) gac410: Michael .. you added "Community events" to the agenda -  fosdem ?
(09:52:52 AM) MichaelDaum: yes
(09:53:23 AM) MichaelDaum: I was approached by Jean-Marc Libs from TikiWiki
(09:53:35 AM) gac410: y   I was online when he was trying to find you.
(09:53:48 AM) gac410: Where is fosdem?
(09:53:51 AM) MichaelDaum: whether we are interested in participating on their booth at the fosdem 2018
(09:54:18 AM) MichaelDaum: https://fosdem.org/2018/
(09:54:28 AM) MichaelDaum: https://www.fosdem.org/2018/news/2017-09-03-call-for-participation/
(09:54:38 AM) MichaelDaum: https://tiki.org/TikiFestFosdem2018
(09:55:17 AM) MichaelDaum: https://tiki.org/TikiFestFosdem2016
(09:55:22 AM) MichaelDaum: https://tiki.org/TikiFestFosdem2017
(09:56:05 AM) MichaelDaum: so they are on the fosdem pretty regularly and invite other wiki related projects to join ... which I find very kind of them
(09:57:07 AM) MichaelDaum: is anybody else interested in comming?
(09:57:08 AM) gac410: yes  That is really nice.   It's not exactly local for me,  so I probably won't go.   But I do give a +1 to the idea 
(09:57:38 AM) gac410: This one might be better to bring up on the main channel. 
(09:57:47 AM) MichaelDaum: I'll set up a page in the Community web and send around an announcement on the ML
(09:58:06 AM) MichaelDaum: hoping to meet some more fossies
(09:58:59 AM) vrurg: Wish I'd be able to come too...
(09:59:09 AM) gac410: Hopefully we have 2.2 released by next February. 
(09:59:57 AM) gac410: Looks like they combine fosdem with their TikiFest   ... which I assume is like our Foswiki Camps?
(10:00:48 AM) JulianLevens: I could go - it not too far away for me
(10:04:00 AM) gac410: We are at 1 hour.   Any other items for the Release Meeting?   
(10:05:30 AM) JulianLevens: not from me
(10:05:58 AM) vrurg: As I'm now back to the project I'd like to remind people that I'm open for any kind help. And would help in any way too. ;)
(10:06:54 AM) gac410: Ah... I was thinking about an addition to AntiWikiSpamPlugin or maybe just FoswikiOrgPlugin.
(10:07:21 AM) gac410: Force topics posted by New users to have   DENYTOPICVIEW = WikiGuest
(10:07:49 AM) gac410: This would stop topics from being search enging fodder.   and might cut down all the annoying spam registrations.
(10:08:00 AM) uebera||: +1
(10:08:06 AM) JulianLevens: y
(10:08:27 AM) gac410: Once we see useful posts, we could remove the user from the NewUserGroup which would stop the beforeSaveHandler 
(10:09:49 AM) gac410: Anyway.... Thanks everyone!   see you in the main channel and back here in October     
(10:10:12 AM) JulianLevens: Thank You
(10:10:17 AM) uebera||: thx, cu
(10:10:23 AM) vrurg: Thanks!