Release Meeting: 08 Aug 2016

(08:59:47 AM) MichaelDaum_ is now known as MichaelDaum
(09:00:38 AM) uebera||: Maybe we can add this to the channel topic? --> https://foswiki.org/Development/ReleaseMeeting02X02_20160808
(09:01:05 AM) You're not a channel operator
(09:01:17 AM) gac410: We don't have a channel op for #foswiki-release. 
(09:01:44 AM) uebera||: I see.
(09:01:57 AM) gac410: Hi all 
(09:02:33 AM) CDot [~crawford@foswiki/developer/cdot] entered the room.
(09:02:41 AM) MichaelDaum: Hi gac410
(09:02:55 AM) gac410: I did just create and agenda.    1) Urgent tasks,  2) Development discussion,  3) release plan
(09:02:59 AM) gac410: Hi MichaelDaum
(09:03:00 AM) CDot: distressed by the recent flamefest. Thought I'd drop in and offer moral support.
(09:03:47 AM) gac410: ;)    Well let's make sure we take toasted marshmallows  or somemors away from the roast 
(09:04:00 AM) MichaelDaum: I was feeling inclined to rephrase the "ask not what the country can do for you, ..." meme
(09:04:39 AM) gac410: Right now vrurg is wearing the "Hero"   hat.   we need to enlist more support for him 
(09:05:06 AM) MichaelDaum: ... while not forgetting the rest of the gym
(09:05:12 AM) gac410: Anyway ...  lets get started.    I put the current patch & minor blockers into the meeting notes.
(09:05:26 AM) vrurg: Hi everybody!
(09:05:38 AM) MichaelDaum: Hi Vadim
(09:06:18 AM) gac410: Most are not really blockers.  
(09:06:59 AM) gac410: https://foswiki.org/Tasks/Item14126 ...  random tasks being blocked.   I suspect some plugin might be stepping on memory ..  Can't imagine how topics are becoming magically restricted.
(09:07:19 AM) gac410: We've had nothing like that on foswiki.org
(09:08:37 AM) gac410: https://foswiki.org/Tasks/Item14117 ... MichaelDaum did you report that upstream?     I doubt we can get it fixed unless we upgrade to latest tmce.  
(09:08:50 AM) MichaelDaum: 14126 is probably related to one of the plugin in the long list
(09:09:44 AM) MichaelDaum: gac410, no I didn't. the test case is too random and probably only of concern for us sending TML into TinyMCE's sax parser ... which dumps it
(09:10:29 AM) MichaelDaum: I also tried the latest TinyMCE from CDN and verified it still had the same issue
(09:10:38 AM) gac410: 14126   That one will be a beast to figure out,    And no response in 5 days on task.    My thought is to downgrade to normal.   
(09:11:08 AM) MichaelDaum: what happens is that during initialization the sax parser is eating both versions of the text sources: the TML one and later on the HTMLized once again
(09:11:27 AM) MichaelDaum: the first round should be spared somehow but that needs a redesign of its init process I guess
(09:11:36 AM) gac410: Could we entity encode the tml version somehow?
(09:11:53 AM) MichaelDaum: like lipstick on a pig?
(09:12:01 AM) gac410: y.   Guess so.  
(09:12:09 AM) gac410: Document it as a known issue?
(09:13:33 AM) MichaelDaum: the tech is somehow buried under a convoluted init process ... and probably best solved by rewriting it
(09:14:24 AM) MichaelDaum: however at that point I can't provide any additional more substantial findings
(09:14:40 AM) gac410: IMO the rest of the "blockers" are really enhancements that are marked urgent for whatever reason.   14113 I know is my issue - incomplete merge of a feature request and some backwards compat that I have not addressed. 
(09:15:35 AM) MichaelDaum: 13206 is urgent as the jquery-ui version we are shipping suffers from an xss vulnerability
(09:15:41 AM) gac410: Okay MichaelDaum ... I'm of the opinion that TMCE or the whole editing process probably needs a major facelift someday.   But that type of work is utterly beyond me.  
(09:15:52 AM) CDot: FYI I looked at upgrading to latest TMCE some time ago. Technically it's not all that hard, but it requires some template bashing and may well break compatibility.
(09:15:55 AM) MichaelDaum: alas, they changed theming a lot .. which kept me busy 
(09:16:02 AM) gac410: Ah... okay.   
(09:16:45 AM) gac410: There is another xss issue not public.   Maybe we should release both extensions in the interim once the patching is ready.
(09:16:52 AM) MichaelDaum: so all of jquery-ui's css framework, including the markup of widgets changed somewhat, admittedly for the better
(09:17:08 AM) gac410: Although we are on track for a 2.1.3 in August,  so this could push that release.
(09:17:32 AM) MichaelDaum: you mean SlideSow?
(09:18:23 AM) MichaelDaum: https://foswiki.org/Tasks/Item14125
(09:18:29 AM) gac410: y
(09:19:03 AM) gac410: with the jquery-ui changes is there a compat issue with existing installs when extension is updated?
(09:19:25 AM) gac410: (most here will be unable to view 14125)
(09:20:16 AM) MichaelDaum: I am working on smoothing the jquery-ui changes, mostly bringing over the foswiki ui theme, also used by configure
(09:20:30 AM) MichaelDaum: with it configure still looks a bit off
(09:21:32 AM) MichaelDaum: btw Intel payed WhiteHat Security to do the scan and found out this one
(09:22:28 AM) gac410: okay.   When you have that ready,  let's use that to trigger 2.1.3.   not many commits yet,   There are a few other Sev 3 security issues already patched. 
(09:22:51 AM) MichaelDaum: sure 
(09:23:40 AM) gac410: There was a suspicion that BulkCopy was losing information ... was that ever confirmed.   I suppose that would be a really urgent issue if true.
(09:24:14 AM) gac410: I think jast and/or MichaelDaum   maybe saw some issue there?
(09:24:26 AM) gac410: I don't recall seeing a task.
(09:24:28 AM) MichaelDaum: nope not me
(09:24:51 AM) MichaelDaum: frankly I haven't use that script yet 
(09:25:35 AM) ***gac410 was wondering if we should further "soften" the recommendation on bulk copy and emphasize charset converter a bit more. in our upgrade instructions.
(09:26:05 AM) MichaelDaum: yea 
(09:26:19 AM) MichaelDaum: people tend to convert to unicode while they stay on rcs
(09:26:31 AM) gac410: y
(09:30:24 AM) gac410: Okay ... Any more discussion on the urgent tasks:  https://foswiki.org/Development/ReleaseMeeting02X02_20160808
(09:30:45 AM) gac410: Let's move on to the past weeks competing manifestos  ;)
(09:35:48 AM) gac410: Unfortunately there is a lot of truth in both discussions.   
(09:35:48 AM) gac410: 1)  Core is greatly in need of ...  facelift is too gentle a term.    
(09:35:48 AM) gac410: 2)  Compatibility is important,  but IMO *content* compat is much more important than API compat.
(09:35:48 AM) gac410: 3)  UI is in need of a quantum leap forward
(09:37:15 AM) gac410: 4) "Hero" development is okay for short bursts,  but we really need to expand the back court behind the hero's 
(09:37:51 AM) MichaelDaum: I don't see any news here
(09:38:24 AM) MichaelDaum: these issues escorted foswiki and tmwiki since the beginning
(09:38:29 AM) gac410: Right.   I think we've all known a lot of this.   The question is how or even can we address it in a positive way.
(09:39:15 AM) ***gac410 is not the type of developer that can make these leaps.  
(09:39:25 AM) MichaelDaum: it is no doubt a critical transition
(09:39:43 AM) uebera||: Are there some topics/discussions regarding 3)?
(09:40:10 AM) MichaelDaum: the current oo rewrite is juggling eggs and this comes with cracking some
(09:41:37 AM) gac410: uebera||:  I don't recall any specific.  "live editing"  easier attaching / uploading,   pushing more to the client (js,  angular,  etc.)   Lots of room for improvement.
(09:42:33 AM) Lavr: My meeting is over and I can type now. Let is be specific here. Is it reasonable/realistic to deprecate all of Foswiki::Func. That is the big question. And do you even agree with each other? Before vrurg spends 1000s of more hours coding you owe him a clear direction on this
(09:43:11 AM) Lavr: My view is clear. You cannot deprecate the entire API. You need a soft landing - freezing the old for 5 years or so and ADD new
(09:43:44 AM) gac410: TBH Func is a minor nit in the OO rewrite.   Currently there is NO compatibility with existing extensions.   It's not just Func.   
(09:44:30 AM) Lavr: I have no issue with OO rewrite. I have issue with deprecating the entire API
(09:44:53 AM) MichaelDaum: we should not discuss Foswiki::Func right now
(09:44:54 AM) vrurg: And this kind of compatibility cannot be implemented with moo because there is no simple way to map an attribute on an object into a hash key because attributes have triggers, initializers and some other code bound to them.
(09:45:40 AM) gac410: I think the best we can hope for is that Func,  Meta, $Foswiki::cfg{}   and a bunch of other stuff will move into a compatibity layer to *help* existing extensions migrate.   But it's doubtful that it will be perfect.
(09:45:56 AM) vrurg: Lavr: remove the words about deprecation from the commit message and forget this part. Nothing would change.
(09:46:39 AM) gac410: Right.   This is a firestorm about a poor choice of words.  
(09:47:07 AM) Lavr: My concern is not commit message. it is that you continue to say that Foswiki::Func needs to be deprecated. And I need to hear clear signals from George, Michael, Crawford. So you agree to deprecate the entire Foswiki::Func?
(09:47:46 AM) Lynnwood [~Lynnwood@foswiki/developer/lynnwood] entered the room.
(09:48:08 AM) vrurg: BTW, as long as we will rely on global variables we'll have problems with moving towards more advanced JS-based UI. Because usually it requires webpush/websockets – which are implemented using delayed response (in PSGI terms) – and this is where we gonna have two+ application instances in memory.
(09:48:10 AM) gac410: Lavr,   Currently *no* Foswiki 1.x/2.x extensions will work on the OO rewrite without some significant work.   Where this goes is to be figured out.
(09:48:21 AM) Lynnwood left the room ("Textual IRC Client: www.textualapp.com").
(09:48:26 AM) MichaelDaum: Lavr, while I share your shiver down the spinal when somebody wants to deprecate all of Foswiki::Func, I am still open for change and am listening for good reasons why one might feel inclined to do so.
(09:48:48 AM) MichaelDaum: you should too
(09:49:09 AM) Lavr: I am open for change too. But not to deprecate an API that breaks ALL extensions ever written for Foswiki totally and utterly
(09:50:08 AM) MichaelDaum: all well. let's still talk about it and listen to vrurg.
(09:50:33 AM) vrurg: Lavr: It's not Foswiki::Func which breaks compatibility, but non-existant $Foswiki::Plugins::SESSION->{webName}  which is to be replaced with $Foswiki::app->request->web.
(09:51:15 AM) gac410: Right now the status is that 1) Func:: continues to exist, but as a dynamic loaded version of the next generation API.    2) Enough other stuff is broken that there is still some major work needed to migrate extensions. 
(09:51:29 AM) vrurg: No plugin would work without rewrite. Compatibility layer is not possible because of Moo/Moose architecture.
(09:51:36 AM) MichaelDaum: and this finally _is_ an api for webName ... rather than hacking into the session object. means, good reason for change.
(09:52:56 AM) MichaelDaum: vrurg, there are two kinds of compatibility we have to keep in mind. forward and backward.
(09:53:08 AM) Lavr: If no plugin will work without rewrite then you are on the wrong track. Look at how many extensions we have on foswiki.org. Plus all the ones you do not see made in the companies.
(09:53:36 AM) MichaelDaum: once an extension has been converted to OO, is it possible to provide a forward compatibility layer for non-oo foswiki engines?
(09:53:46 AM) vrurg: Lavr: Fixing CommentPlugin took me 30mins with testing.
(09:54:01 AM) Lavr: I am perfectly OK with creating a new API but you need to think in compatibility so that 90% of the extensions work. And those that don't we have to assist getting them to work.
(09:54:12 AM) vrurg: MichaelDaum: yes, it is.
(09:54:35 AM) MichaelDaum: vrurg, right. so then this is much more promising.
(09:55:02 AM) gac410: Lavr,   Think of this as a major fork that will have  *content* compat, but not binary / API compat.     We have to break some eggs to move out from under CGI and a lot of other old obsolete development
(09:55:30 AM) MichaelDaum: I support this kind of internal fork
(09:55:44 AM) vrurg: In addition to this I'm currently working on a new proposal about new plugins model. The old one is the biggest obstacle to drop application-related globals.
(09:56:21 AM) MichaelDaum: vrurg, awesome. looking forward to read it.
(09:56:23 AM) gac410: This may be the point where we keep a Foswiki 2.x  active with maintenance patching as Foswiki-III moves forward.
(09:56:50 AM) Lavr: This is not breaking eggs. This is suiside. You have to think about the question: "How can we provide backwards compatibility with the basic Foswiki::Func API" which is what 90% of the plugins use. Few go deep into Meta objects etc. Most are plain simple extensions that parse the content of topics and implement single function macros.
(09:57:19 AM) vrurg: BTW, a little advise on naming the new subsystem. Foswiki is using every possible option I was thinking about: plugins, extensions, addons...
(09:57:51 AM) MichaelDaum: hehe
(09:59:24 AM) uebera||: --> http://www.thesaurus.com/browse/add-on ("FlavorEnhancer?")
(09:59:48 AM) vrurg: Lavr: This is why I simply mapped the whole Foswiki::Func onto Foswiki::App. Compatibility, ease of access (almost every object has a shortcut to the app object), and the fact that most of the API is working through $Foswiki::app object anyway.
(10:00:42 AM) vrurg: Leave the naming for the proposal comments if there be any reason to even come down to this point. :)
(10:01:05 AM) gac410: vrurg,   correct me if I'm wrong:  Extensions that look at content, and use Func exclusively will continue to work ,... without changes ??? 
(10:01:29 AM) Lavr: If you make the magic that maps the old Func into App - and do not nag people with deprecation messages - you have saved the world. And if you make the App API better. I mean. we could really need better API to parse tables, and other content as objects for extentions - then plugin authors will want to convert over.
(10:01:30 AM) vrurg: gac410: 100% true. 
(10:01:33 AM) gac410: Extensions that use any Foswiki globals,   need changes.
(10:02:05 AM) vrurg: gac410: Except that eventually they may end up delaing with Foswiki::Meta object – and this is where they'd hit the new OO.
(10:02:31 AM) Lavr: But you will have a large number of well working extensions that will NOT be converted unless YOU do it because the author is gone. But that does not make the plugin obsolete for the USERS. Always remember that the users and authors are two different things
(10:03:12 AM) gac410: The globals,  including the old SESSION and $Foswiki::cfg     are the biggest issue.     Meta ... I was hoping that the old calling conventions could be saved with a compat layer.
(10:03:22 AM) vrurg: s/delaing/dealing/
(10:03:28 AM) Lavr: There are not that many globals other than config globals and they are 100% static anyway. never change
(10:04:39 AM) gac410: Some of this will have real benefits that are hard for users to understand.   Consider https://foswiki.org/Tasks/Item14126    Best guess:  Some extension is stepping on something in memory that breaks foswiki with persistent perl  
(10:05:11 AM) gac410: making it so extensions can not touch the internals is a really big step towards a more reliable system.
(10:05:12 AM) vrurg: gac410: SESSION ($Foswiki:app) and $Foswiki::cfg are the only problem. Others are static and there no problem in sharing them across few app instances.
(10:05:45 AM) gac410: $foswiki::cfg is  *supposed* to be static.    It should never ever be changed 
(10:06:37 AM) gac410: Unfortunately there are cases in core and elsewhere  where code temporarily whacks the config,  or the session user,  etc.    Really nasty IMO
(10:06:56 AM) vrurg: gac410: Unless we're in a virtual hosting environment. Or any other reason to have different configs for different app instances.
(10:07:05 AM) MichaelDaum: the idea is more about swapping in a differnet $Foswiki::cfg  which is static during one request of course
(10:07:49 AM) gac410: The only legitimate run-time modifications of the config is in the unit tests where test try to exercise combinations of settings.  
(10:07:55 AM) MichaelDaum: however VH is not yet on the agenda of the next release, afaics
(10:08:17 AM) vrurg: MichaelDaum: This is possible and the only way around. And this is what I do now. It is especially important for tests where they mangle with it a lot. But this is a hack and potential bug generator.
(10:08:48 AM) MichaelDaum: yes, and not really testing a real world scenario either
(10:08:52 AM) gac410: Virtual hosting. ...  Agreed,  it's why I've always been afraid of it.   on-the-fly cfg modification.    But if there was formal "config swapping" in the core design ... they that is a very positive move.
(10:09:42 AM) vrurg: MichaelDaum: Yes, VH is not there. But I wanna be prepared beforehand.
(10:09:43 AM) MichaelDaum: I am more afraid of extensions like HomePagePlugin that mess around with the session obj
(10:10:09 AM) MichaelDaum: ^session obj^foswiki app
(10:10:11 AM) gac410: y.    I agree.    That one had some big unexpected side effects initially.   
(10:10:21 AM) ***vrurg had to switch HomePagePlugin off for some tests because they're broken with it.
(10:10:45 AM) ***MichaelDaum regularly disables HomePagePlugin ... but also PreferencesPlugin ;)
(10:10:51 AM) gac410: Some of the extensions have some horrible hacks in them    Sven has a few of them. ;)
(10:11:41 AM) Lavr: I think it is only a small subset of plugins (that are not core) that hack the Session object. it is so poorly documented that only core code hackers know how to. I am not nervous about that.
(10:11:59 AM) CDot: I'm not at all clear why there is so much fear of deprecating the Func API.
(10:12:15 AM) gac410: Like Vicki insisting on compatibility with the    host.com/Topic     hack where we default a web if given just a topic ...   
(10:12:22 AM) CDot: Look at it this way; anything that can be done in the Func API must be do-able - somehow - from the core
(10:12:44 AM) CDot: it doesn't do anything sinister or scary that can't be emulated - possibly at some cost, but still do-able
(10:13:01 AM) gac410: Right.    And Deprecated in "core"  only means that it could be added back as an optional extension  ... should we ever complete the deprecation process.
(10:13:07 AM) CDot: so, there can always be a Func API - inefficieant, hairy, perhaps, but still "around"
(10:13:25 AM) CDot: and not the r4commended way o do things
(10:14:20 AM) CDot: the place where plugins are likely to fail is in the rendering pipeline (callbacks)
(10:14:30 AM) gac410: I really think this is all a tempest in a teapot right now.   Focus on getting the new core.
(10:14:51 AM) CDot: because any core restructuring will probably change the entry points - some of the existing EmptyPlugin callbacks are just stupid.
(10:15:07 AM) Lavr: It is the "no plugin will work without rewriting" part of it that worries me. It worries me if ALL extensions suddenly will not work or gets flagged as using deprecated API all over the place signalling, this extension will soon stop work
(10:15:31 AM) CDot: Lavr: I don't think anyone has said that (or if they have, they probably shouldn't have)
(10:15:50 AM) CDot: I think *some* will stop working, yes, if the callbacks change
(10:16:02 AM) MichaelDaum: Lavr, we will have a FoswikiNG as well as a FoswikiOG branch being maintained during a non-trivial period of time
(10:16:47 AM) vrurg: I'm running out of time. Too much focus on Fosiki::Func which is still around and not gonna be dead any time soon. So, my questions: 1) Somebody with good knowelge of the standards would be great to step in and help. I have some tests passing which are not expected to do so and I have no idea – why; 2) I would like to have two core killer features be implemented: PSGI (which is almost in place) and new plugins. After that I cons
(10:16:48 AM) vrurg: the project be prepared for stabilisation; 3) I have added support for Plack::Test. But it needs to be reviewed.
(10:16:50 AM) gac410: Right now.   Extensions that *strictly*  use callbacks / passed data,  and Func    should be fine.    Globals and Meta are an issue. 
(10:17:04 AM) CDot: like gac410 I would be far more concerned about data compatibility than about plugins. Personally I'd make a list of the plugins that were important *to me* and use that as a baseline for continuing support.
(10:17:23 AM) CDot: anything outside of that list is .... well .... subject to negotiation
(10:17:50 AM) gac410: vrurg:    What do you mean by "knowledg of the standards"  ... what standards?
(10:18:05 AM) gac410: unit tests ...  let me know which tests and I'll look at them
(10:19:01 AM) gac410: PSGI features.    That one would be good to ask jomo.    IMO  if we can using PSGI/Plack,  kill our Engine contribs and stop Foswik from creating zombies under apache,  that would be killer for me  ;D
(10:19:29 AM) CDot: vrurg: is there a list of the tests that "pass but shouldn't" somewhere?
(10:20:00 AM) Lavr: I can surely make a list of plugins that are important to me. But that is actually my least worry because I can rewrite all my plugins. I am concerned about all the plugins that are not maintained but still work just fine.
(10:20:25 AM) Lavr: Remember how long it took to convert plugins from Twiki::Func space to Foswiki::Func space.
(10:20:30 AM) vrurg: gac410: All Foswiki standards. Unfortunately, I'm soo deep at the low-level things that loosing track of the UI-related staff. Don't know how to explain it. :(
(10:20:54 AM) CDot: I didn't say "belong to me", or even "that I use". I said "are important to me". e.g. SSP, which I don't use, is important because other people use it.
(10:21:13 AM) gac410: Lavr,   That became an issue on 2.0 as well.   We really needed a full review of all extensions.   There are a number that break on 2.x  or are broken on modern perl.
(10:21:17 AM) vrurg: CDot: Not yet. The last week was to busy with personal issues, didn't even got time to write the proposal before this meeting.
(10:21:43 AM) CDot: sure. That list is needed before anyone can offer comment.
(10:22:01 AM) gac410: Anyone running foswiki on distros that keep up to date with perl are probably hitting extensions that break.   qw() deprecation,  escaped braces \{ deprecation,   etc.
(10:22:17 AM) Lavr: when we deprecated 1 Func call or when a perl compatibility issue comes it is a few extensions that need fixing. This time it will be ALL unless we have a compatibility layer. That is why we need to think compatibility
(10:22:57 AM) Lavr: But I must also say: I look forward to a new clean API - especially the Foswiki::Meta and the Session object which is not really true API today.
(10:23:42 AM) gac410: Lavr,   Foswiki is so terribly out of date,    we really needed a "clean sheet" look without anyone saying NO NO NO ... Compat Compat Compat.     Let's see where a fresh new core takes us and then deal with the compat monstor.
(10:23:44 AM) gac410: monster
(10:24:08 AM) vrurg: And one thing I agree with Lavr upon – I really need the direction from about a month ago. When I dove into all this I had the clear view of what must be done to the core. Now, as it is getting above that level I'm loosing the track.
(10:24:35 AM) gac410: vrurg ... I don't understand.
(10:26:18 AM) gac410: Jomo actually started an effort to test every extension with unicode.  IIRC there is a task that lists the test status.   But there has been little/no fixing.
(10:26:19 AM) vrurg: gac410: Priorities. I have a running Foswiki in front of me – i.e. it displays pages and so on. What's next? 
(10:26:53 AM) vrurg: I mean, in currect situation I'm lost in details and there must be somebody with clear overview.
(10:27:11 AM) MichaelDaum: how about fixing rcs store
(10:27:27 AM) MichaelDaum: last time i tried it broke
(10:27:32 AM) gac410: Ah..    okay.  So you are happy with the mooification    and now it's either the Plugin rewrite,  or just stablization.
(10:27:57 AM) Lavr: I am using rcs store in my production site all the time.
(10:28:07 AM) gac410: On OO branch
(10:28:09 AM) vrurg: Ok, for the moment I wanna have the new plugins in place – this is the last thing where I clearly know what to do. 
(10:29:05 AM) gac410: Actually what we don't have is "Extensions"    That's the umbrella of Plugin, AddOn, Contrib ...    How about if Foswiki OO just calls them Extensions.
(10:29:05 AM) vrurg: Plus, anyway, somebody would need to be brave enough as to migrate changes from the master.
(10:29:41 AM) vrurg: gac410: This term is used elsewhere and would be confusing to the end-user, I'm afraid.
(10:29:43 AM) gac410: vrurg:    I've tried.   and am prepared to try again,  but it's a fairly major effort,  and I was afraid that there was too much other stuff going on.
(10:30:11 AM) vrurg: But let me have the proposal done – there will be more important things to discuss than the name.
(10:30:45 AM) gac410: I was tempted to branch your Item* branch into  OOmaster    And then merge master -> OOmaster    and see where that goes.
(10:30:58 AM) vrurg: Yes, I know you're overload with other issues. 
(10:31:49 AM) Lavr: vrurg. If you look at two of my plugins. And I am a hardware idiot with little software knowledge. The two most complex extensions I ever wrote and that took me months to write are MultiSearchPlugin and MultiTopicSavePlugin. What would it take to add a compatibility layer to support those. Don't do it. Just look at it as example. If those two will work - then I think that 90% of all extensions will work
(10:32:25 AM) vrurg: Ok, for the moment it seems like I have some time till the next meeting with finalizing Plack::Test support and working on the new plugins model.
(10:32:34 AM) Lavr: I know that Michael has made much more complex extensions that go much deeper but he is also in a different league than most extension devs
(10:32:37 AM) vrurg: And two plugins from Lavr too.
(10:32:57 AM) vrurg: Fine, that's enough for the next two weeks, for sure. :)
(10:33:02 AM) gac410: So maybe all core devs,   before our next release meeting ... 2 weeks,   Commit to checking out the Item13897 branch,   and make a list ... or fix some stuff.
(10:33:17 AM) Lavr: No need to rewrite my plugins. I just meant for you to look at what kind of API I use.
(10:33:29 AM) gac410: I'll commit to working on a merge from master   
(10:33:44 AM) gac410: And investigating any unit tests that you identify as problems. 
(10:34:05 AM) vrurg: Lavr: I would be interested to see how much time would it take me to convert one of them. But only if I get time for this.
(10:35:25 AM) Lavr: The MultiSearchPlugin dig deep in using search API and stuff. And the MultiTopicSave uses the rest interface and also digs deep. I spent a lot of time hacking those together. And I would not have been able to without help from many of the devs here on IRC
(10:35:26 AM) gac410: Do we need a new topic in Development:     WhippingOOFoswikiIntoShape?
(10:35:34 AM) vrurg: Ok, have to run. Thanks everybody! I hope to have more comments on the related proposal pages.
(10:35:58 AM) gac410: Also ... Everyone   https://foswiki.org/Development/Foswiki3CodeChanges    has notes on what's changed in the new Foswiki
(10:36:06 AM) vrurg: gac410: Yes, I'd like to have it.
(10:36:55 AM) ***vrurg will be back later today.
(10:36:59 AM) vrurg: cu!
(10:37:04 AM) gac410: cu vrurg
(10:37:38 AM) gac410: So everyone else. ... Foswiki 2.1.3     Should we shoot for a September 1st patch release with the identified security fixes
(10:37:55 AM) gac410: And Defer Foswiki 2.2   until December ...   As no features have been forthcoming  
(10:38:12 AM) uebera||: sounds reasonable to me.
(10:39:56 AM) MichaelDaum: +1
(10:40:03 AM) Lavr: Good plan. My 2.1.2 runs rock solid here at Moto - seen from a core point of view.
(10:40:07 AM) CDot: MichaelDaum: re: rcs store. It broke when you fixed it? Or you fixed it when it broke?
(10:40:30 AM) CDot: or you tried it and it broke, but you didn't fix it?
(10:40:35 AM) MichaelDaum: it is broken on the oo branch last time i tried it vanilla
(10:40:49 AM) CDot: ok. Is PFS OK?
(10:41:00 AM) gac410: oo branch seems to work fine with pfs
(10:41:03 AM) MichaelDaum: pfs is the only way I can run the oo branch
(10:41:35 AM) MichaelDaum: rcs is broken for some strange reason as I still dont understand modern perl well enuf
(10:41:37 AM) CDot: ok. Sounds like a metadata problem.
(10:41:52 AM) Lavr: I also thought you talked about rcs broken in the current version, Michael so ignore my comment about it running.
(10:44:00 AM) MichaelDaum: I've got two checkout areas here. one for my every day wiki based on master. the other one for a vanilla branch such as vrurg's or any other 
(10:44:54 AM) MichaelDaum: I tried to configure an oo foswiki similar to my current production settings (rcs, page cache, what not, ...) and failed at using rcs
(10:45:44 AM) MichaelDaum: it basically seems to be left behind the rest of the store layer advancing in one or the other direction during development ... something understandable given the low devs bandwidth
(10:48:03 AM) gac410: One more question... back to the original two "manifestos" ... Do we need a "FutureUserExperience" topic where we gather ideas on directions the user interface needs to go.
(10:50:21 AM) MichaelDaum: this is a wide field
(10:51:19 AM) Lavr: On the user experience side. The main issue is that our Wyswyg editor is lagging behind in comparison what people are used to in Browser based applications. Not 1 specific issue. More a generic - looks tired and old - and lacks basic features type of problem
(10:51:33 AM) MichaelDaum: a much more concrete task improving user experience is configure: installing and maintaining extensions is a ux mess atm.
(10:51:49 AM) Lavr: The new NatEdit has been well received by my users. it is the Wysiwyg editor that people complain about
(10:52:54 AM) gac410: MichaelDaum:   Have you been experimenting with a Nat Edit 2.0,  with updated TMCE, etc?
(10:53:19 AM) MichaelDaum: have to quit the meeting now. I think the ongoing discussion should better be continued on #foswiki ... with this release meeting ending at some point.
(10:53:32 AM) MichaelDaum: gac410, yes, but it is not ready for prime time
(10:53:58 AM) gac410: Okay....  Let's adjourn the release meeting.   I'll get minutes updated.  
(10:54:12 AM) MichaelDaum: I know I still owe you a feature proposal describing the scope of the work I am doing here
(10:54:22 AM) gac410: Thank you everyone.   Good discussion.   No name calling ...  Successful day  :D
(10:54:47 AM) uebera||: Regarding A.O.B.: I intend to upgrade the Foswiki server this Sunday (around 0300Z when there should not be much traffic) unless this is considered bad timing. If we're lucky, the new HTTP/2 capable Apache2 will perform ... better than the current one (amongst other things). Creating a full backup beforehand allows us to revert if the upgrade (i.e., the then-upgraded services) won't work correctly.
(10:55:10 AM) gac410: A.O.B ???
(10:55:16 AM) uebera||: any other business
(10:55:19 AM) Lavr: Good luck with that
(10:55:24 AM) uebera||: thx ;)
(10:55:25 AM) gac410: Ah...    Okay ... y,  good luck.
(10:55:37 AM) gac410: Sounds good to me. 
(10:55:44 AM) MichaelDaum: thanks everybody. was a good meeting.
(10:55:59 AM) Lavr: Bye everyone.
(10:56:04 AM) uebera||: cu!
(10:56:26 AM) gac410: See you all....   August 22nd   1300Z   Same bat time   Same bat channel
(10:57:02 AM) Lavr: I will try. May join again in the middle. Depends on meetings with US
(10:57:43 AM) gac410: https://foswiki.org/Development/WhippingOOFoswikiIntoShape     Brainstorming for "finishing up"  3.x