Release Meeting: 27 Jun 2016

(08:54:00 AM) jast: I can't participate in the release meeting, have another meeting at the same time. :(
(09:00:59 AM) MichaelDaum: hi everybody 
(09:01:15 AM) gac410: Hi all.
(09:02:17 AM) ***uebera|| follows the log with one eye
(09:02:25 AM) gac410: We didn't really have much of a meeting two weeks ago - A few people showed, but nothing really discussed.
(09:03:03 AM) gac410: Currently no urgent tasks open for patch release.  
(09:04:21 AM) ***gac410 wonders if Item14091 should be urgent.    A couple of sites are saying the cache breaks utf-8 topics.
(09:04:46 AM) gac410: But I've never seen it happen,  have no idea at all why it might be breaking some sites.
(09:05:33 AM) MichaelDaum: nor did I
(09:06:18 AM) gac410: Thought it might be mod_perl vs. fcgi,  but now there are reports against both of them.
(09:06:27 AM) MichaelDaum: I could easily picture the two perls being configured differently wrt unicode. the one running foswiki vs the one inside apache.
(09:06:47 AM) MichaelDaum: even for fastcgi? how can I repro these?
(09:06:52 AM) MichaelDaum: cus I tried 
(09:07:08 AM) gac410: No idea.  I'd think we would have seen it on foswiki.org 
(09:07:19 AM) MichaelDaum: def
(09:07:59 AM) uebera||: Yes, f.o is proof that it's possible to get it to work. ;)
(09:08:07 AM) gac410: So I'm quite concerned about that task, but have no idea how to proceed.   If we ever get a diagnosis, it probably should trigger 2.1.3 
(09:09:03 AM) uebera||: gac410: Didn't you try to switch the default DB encoding of your test instance to UTF-8 once?
(09:09:29 AM) gac410: MichaelDaum:  a month ago you mentioned that you had another urgent performance fix for release branch,  but no task yet.
(09:09:50 AM) gac410: uebera||:  yeah i tried,  but really that's totally unrelated, as we don't store the pages in the database.
(09:11:18 AM) uebera||: Did the reporter check whether the cached pages on disk were affected?
(09:12:51 AM) gac410: I don't recall now.    need to reread the task.
(09:12:57 AM) uebera||: If so (what I understand), the question is whether this problem goes away once another place to store the files is being used--there are not details about the latter.
(09:13:13 AM) uebera||: 'In both instances the string "äöüč" appears as "äöü" in the cache file.'
(09:14:26 AM) vrurg: Hi all
(09:15:32 AM) gac410: hi vrurg
(09:16:03 AM) gac410: Any other tasks anyone sees that ought to be blockers?
(09:17:32 AM) gac410: There is one support question: https://foswiki.org/Support/Question1792    that is probably on-point though a bit rough on the community.
(09:18:09 AM) MichaelDaum: I am currently restructuring NatEditPlugin
(09:18:16 AM) MichaelDaum: to plug in different engines
(09:18:28 AM) gac410: y   I recall you commenting about that a while ago.
(09:18:44 AM) MichaelDaum: right now I've got raw (the current wiki mode), codemirror, tinymce4
(09:19:05 AM) MichaelDaum: tinymce4 not yet ready, just loading tinymce4 from cdn and loading the wiki content
(09:19:37 AM) gac410: That will be nice.   I suspect the hard part will be the Wysiwyg conversion from HTML to TML   which needs to be tuned for the particular html editor idiosyncrasies 
(09:19:44 AM) MichaelDaum: codemirror comes with a new foswiki mode for hiliting and auto-indenting
(09:19:49 AM) MichaelDaum: as you edit
(09:19:56 AM) MichaelDaum: as well as folding at headings
(09:20:40 AM) MichaelDaum: I've been using the codemirror engine inside natedit for over a month now and it is rock solid
(09:20:51 AM) MichaelDaum: can't say the same for tinymce as I am no wysiwyg lover
(09:21:28 AM) gac410: Has anyone else made any progress on 2.2 features?   So far most everything including my own work appears to have stagnated.   CDot has a bunch but he is also pretty scarce lately.
(09:21:36 AM) MichaelDaum: plan is to have prosemirror as another engine and a separate plugin ... like codemirror
(09:22:09 AM) MichaelDaum: there are a couple of smaller updates to JQueryPlugin coming in next
(09:22:36 AM) gac410: MichaelDaum:  does this need a feature proposal?  Or will the basic natedit features remain compatible,  just pluggable?
(09:23:15 AM) MichaelDaum: It needs a feature proposal
(09:23:30 AM) MichaelDaum: besides the tech underneath there are two things to discuss:
(09:23:48 AM) MichaelDaum: (1) new preference setting EDITOR ... in addition to NOWYSIWYG 
(09:24:08 AM) MichaelDaum: (2) same menu bar for all engines yes-no
(09:24:38 AM) gac410: y,  the old preferences editor hidden under more topic actions pretty much sucks   
(09:24:40 AM) MichaelDaum: on (2)  ... all engines plug in to the same menu bar
(09:25:06 AM) gac410: I think that seems nice. ...  getting a more consistent interface.
(09:25:19 AM) MichaelDaum: that was my thinking too
(09:26:06 AM) gac410: Though there are things that a wysiwyg editor needs in the menu bar that don't really apply to wikitext editors.
(09:26:11 AM) MichaelDaum: the rest of the code change is more related how to deal with the old integration part of TinyMCEPlugin
(09:26:39 AM) gac410: Y,  and that all had to be reworked a bit to deal with the 4.x api changes.
(09:27:01 AM) MichaelDaum: the idea is to have a tinymce and a timynce3 engine sitting next to each other
(09:27:09 AM) MichaelDaum: or tinymce_legacy
(09:27:31 AM) ***gac410 likes the idea of pulling tmce (or other editors) from a CDN.   But we still need local storage for sites behind draconian firewalls.
(09:27:54 AM) MichaelDaum: most javascript code in the current impl can be faded out / aka yanked
(09:28:07 AM) gac410: y.   multiple engines.   I tried that once ...   wasn't successful and you were not too happy iirc  ;D
(09:28:36 AM) MichaelDaum: CDN, that is another idea we should muse about in more detail for all javascript plugins ... like: switch them into CDN mode
(09:29:02 AM) gac410: y.   though that limits our local patching,  which you do quite a bit of don't you?
(09:29:58 AM) MichaelDaum: most of the 3rd party stuff in JQueryPlugin is available via one or the other CDN. so they should get some {JQueryPlugin}{SomeModule}{CDNUrl} and {JQueryPlugin}{SomeModule}{Enabled} pair of config vars
(09:30:31 AM) MichaelDaum: or {CDN}{Url}, {CDN}{Enabled}
(09:30:41 AM) MichaelDaum: whatever prefix they have inside $Foswiki::cfg
(09:31:07 AM) gac410: hm   So specific to jquery or    or have a CDN baked into store somehow?   I think there have been both discussed on occasion.
(09:31:35 AM) MichaelDaum: is it a store property? hum...
(09:31:47 AM) MichaelDaum: more about the "assets"
(09:31:58 AM) gac410: map  pub/path => cdn location  ???
(09:32:13 AM) MichaelDaum: oh
(09:32:38 AM) gac410: which also was part of the effort to change all concatenated style pub URLs   to a {macro argument} format
(09:32:54 AM) MichaelDaum: at the end of the day we need to end up with <script src="//cdn.foo.bar.com"></script>
(09:33:14 AM) MichaelDaum: <link rel=stylesheet href="//cdn.foo.bar.com" />
(09:33:21 AM) gac410: inline concatenation breaks any cdn mappings done by store.
(09:33:34 AM) gac410: right.  
(09:34:04 AM) gac410: And probably auto-insert the cdn locations into the appropriate CSP
(09:34:29 AM) MichaelDaum: I'd rather configure CDNs for a resource explicitly
(09:35:34 AM) MichaelDaum: auto-yadda magic ... sounds like getting out of control too easily ... even more given CDNs are external already and urls tend to break over the years regularly
(09:38:45 AM) gac410: Just saying at the store level.   if you map  pub location -> CDN,  then that CDN needs to be listed in a security policy.   or rather moot.
(09:39:26 AM) gac410: Maybe a checker is enough.  
(09:42:27 AM) MichaelDaum: for the jquery plugin structure the change seems almost obvious to conditionally output one or the other uri
(09:42:40 AM) MichaelDaum: almost too obvious of a code improvement
(09:45:33 AM) gac410: As long as it doesn't undercut / break the efforts to move to %PUBURL{}% links and a possible future store linked CDN.  
(09:50:56 AM) MichaelDaum: ah now I see what you mean
(09:51:04 AM) MichaelDaum: %PUBURL{}% expanding to some CDN
(09:51:08 AM) gac410: Yes
(09:51:51 AM) MichaelDaum: I see. well current jquery plugins don't follow this alley at all. they re not part of the store actually.
(09:52:48 AM) gac410: It's a big tedious edit, and has compatibility issues,  but getting all pub links into canonical form is underway.   But plugins that implement on 1.x  can't be changed  :(
(09:53:33 AM) gac410: Foswiki 3.0 will probably be the discontinuity that allows us to throw away past.    Since it's already totally incompatible.
(09:54:48 AM) gac410: Maybe we should have a quick discussion about 3.0   especially extensions.
(09:55:19 AM) vrurg: If anybody interested now.
(09:56:04 AM) gac410: hi vrurg
(09:56:06 AM) vrurg: Because on my side it's only routine conversion of tests. Though it's almost finished.
(09:56:11 AM) vrurg: hi again. :)
(09:56:34 AM) gac410: So big question, is what do we do about https://foswiki.org/Extensions   
(09:57:21 AM) vrurg: Most of them would be converted.
(09:57:28 AM) vrurg: It's not that hard after all.
(09:57:37 AM) gac410: Right but they won't be backwards compatible, right?
(09:57:57 AM) gac410: So we need to decide how to "version"  Extensions web for Foswiki 3     
(09:57:58 AM) vrurg: Ah, this point... Yes, you're right.
(09:58:25 AM) gac410: Make an Extensions3 web which is used for next generation extensions?   
(09:59:22 AM) vrurg: The decision is depending on whether we want to encourage developers to create compatible extensions.
(10:00:11 AM) gac410: Before you were saying you did not think that extensions could be made compatible.
(10:01:15 AM) vrurg: Not that way compatilble. Do you remember the last time we discussed this there was a proposal that an extension could be bundled both 2.x and 3.x in a single zip? Just different subdirs in the archive.
(10:01:42 AM) vrurg: This is a size bloat but let's keep the current Extensions web as is.
(10:01:56 AM) gac410: Ah... that level..    hm.  There are still challenges to that.  
(10:02:07 AM) vrurg: Few, right.
(10:02:26 AM) vrurg: A developer would have to maintain two branches of the same extension. 
(10:02:35 AM) vrurg: Some would do, but only few.
(10:03:08 AM) gac410: The fact that we allow "simple unzip to install"   makes this more difficult.   
(10:03:25 AM) vrurg: Plus consider the fact that I still wanna develop a new OO plugins/addon subsystem which would be completely different from the current approach.
(10:03:34 AM) MichaelDaum: and pseudo installed envs
(10:04:59 AM) vrurg: 'unzip to install' isn't that bad after all. To my view.
(10:05:15 AM) gac410: the whole installer system has a lot of legacy that makes this soooo much more complicated. 
(10:05:35 AM) gac410: hm    cd  var/www/foswiki;   unzip MyExtension.zip     FTW      
(10:06:08 AM) MichaelDaum: or cd var/www/foswiki/core; ./pseudo-install.pl
(10:06:13 AM) gac410: Extensions unzip directly into lib, pub, and data    
(10:06:15 AM) vrurg: run a installed script for some fixups perhaps.
(10:06:40 AM) vrurg: s/installed/installer/
(10:06:48 AM) MichaelDaum: extensions do come with an xxx_installer.pl
(10:07:09 AM) MichaelDaum: though for now you are not required to run it after unzipping
(10:07:14 AM) gac410: right,  but currently we don't require its use.    right
(10:07:30 AM) MichaelDaum: what would it do on a foswiki3?
(10:08:00 AM) gac410: with Foswiki3,  we need two different  Plugins/MyPlugin.pm   versions ... I think.   
(10:08:32 AM) gac410: er...   a 2nd version,  one is Foswiki 1.x/2.x compat,  and a different one is Foswiki 3.x compat.
(10:09:20 AM) MichaelDaum: maybe we should only ship the installer
(10:09:39 AM) gac410: I wondier if it might be cleaner to create a   lib/Foswiki/Contrib3  and lib/Foswiki/Plugins3 directories for the 3.0 stuff,  so old extensions don't cause issues, and new extensions can't bust an olde foswiki.
(10:09:40 AM) MichaelDaum: or one installer
(10:10:09 AM) MichaelDaum: and one day there will be Foswiki4
(10:10:25 AM) gac410: Well,  the installer actually downloads and unzips the tarball to a /tmp location, then copies or 'checks in"  the code and topics
(10:10:50 AM) MichaelDaum: does bin/configure allow me to install an extension from the cmdline?
(10:10:54 AM) gac410: So the installer on any platform is safe in that it does not unzip in place.    
(10:10:57 AM) gac410: MichaelDaum:   yes
(10:11:04 AM) MichaelDaum: bang
(10:11:43 AM) gac410: On Foswiki2,  running the CLI extensions installer actucally runs bin/configure with the installer wizard.
(10:11:51 AM) gac410: On Foswiki3,  CLI is broken
(10:12:46 AM) vrurg: gac410: I would be fixed.
(10:12:53 AM) vrurg: I just don't have time for this.
(10:13:31 AM) gac410: tools/configure -save -wizard InstallExtensions -args AntiWikiSpamPlugin=Foswiki.org -method add -args ENABLE=1     
(10:13:58 AM) gac410: Right,  not complaining vrurg   just commenting  ;)
(10:14:01 AM) vrurg: Actually, subdirs could be versioned in perl's manner. Something like Contrib/3/
(10:14:37 AM) gac410: That actually might be a good idea.  
(10:14:41 AM) MichaelDaum: gac410, thats aweful
(10:15:04 AM) MichaelDaum: npm install Yadda ... cpanm Yadda ... thats what the others do
(10:15:39 AM) gac410: MichaelDaum:  ... that's "internal" ...   tools/extension_installer  AntiWikiSpamPlugin install ....  is the "public" face
(10:16:38 AM) gac410: The tools/configure CLI is basically the Web UI ...   that's what gets submitted when you press submit on the install an extension page.   The CLI brute force is more for testing.
(10:17:10 AM) gac410: But the extensions_installer  does "report" what the tools/configure command is,  so you could automate it
(10:18:11 AM) ***gac410 stepping away .. back in a couple of minutes
(10:18:16 AM) ***MichaelDaum learned something new today
(10:19:33 AM) gac410: Bottom line is on Foswiki 2.x  we have only one extension installer via configure.   And the other paths all use it.    *Except for pseudo_install!*    :(
(10:20:07 AM) gac410: would be nice if extension installer could also pseudo-install to drop all the duplicate code.
(10:21:54 AM) vrurg: Basically, there must be an API to install things. And everything must be done through it.
(10:23:54 AM) gac410: I'm not sure if it is an API,  but the configure Wizard is the "one way"  
(10:24:54 AM) gac410: vrurg:   the issue i've been struggling with in  tools/configure is that it needs to load up the config and figure out whether or not to do a "prompted" bootstrap.  
(10:25:21 AM) gac410: I've dug into it a couple of times but I've been unable to figure out the new $Foswiki::cfg load methods.
(10:25:35 AM) vrurg: Foswiki::Config class.
(10:26:14 AM) gac410: Right,    But the methods have moved around.    tools/configure is somewhat a special case in that it tries to snoop into the bootstrapping
(10:27:04 AM) vrurg: Bootstrapping is still controlled from outside, by Foswiki::App.
(10:27:10 AM) gac410: Anyway all ... we've been 1.5 hours into the release meeting.    Thanks everyone 
(10:27:15 AM) vrurg: What kind of snooping does configure need?
(10:27:15 AM) MichaelDaum: have to leave. upcomming telco.
(10:27:26 AM) gac410: Thanks MichaelDaum
(10:27:32 AM) vrurg: gac410: let's discuss it later today then.
(10:27:37 AM) vrurg: Thanks everybody!
(10:27:49 AM) gac410: vrurg:    okay.    when you get a chance ping me in #foswiki
(10:27:54 AM) vrurg: Config is the matter I did want to talk about.
(10:28:20 AM) vrurg: gac410: sure, thanks!
(10:28:23 AM) MichaelDaum is now known as MichaelDaum_
(10:28:34 AM) gac410: What I did was changed the classes to Foswiki::Config,   then discovered that Foswiki::App had some of them,  and got rather confused. 
(10:29:04 AM) vrurg: Moving to #foswiki