Release Meeting: 11 Jan 2016

(08:38:23 AM) gac410: Hi everyone.   My apologies for starting off the new year with a botched schedule.
(08:39:00 AM) CDot [~crawford@foswiki/developer/cdot] entered the room.
(08:39:15 AM) gac410: 2.1 Beta 1 is uploaded to Foswiki.org.   Michael, should we do an announcement to foswiki-announce email list?  or just keep it a quiet beta.
(08:40:17 AM) MichaelDaum: I am for openness
(08:40:30 AM) gac410: We found one bug yesterday.   It can become a security bug if you attempt to reset NameFilter to it's default setting.   It basically breaks the regex and allows anything.  But it's broken on 2.0 as well.
(08:40:49 AM) MichaelDaum: thats probably more pressing than working on the beta?
(08:41:41 AM) gac410: I'll get back to tracing after the meeting.   But more importantly,   unicode topic names allows for some very creative topics 
(08:42:29 AM) MichaelDaum: ay
(08:42:32 AM) gac410: even with a workig filter,   1)  Combining marks can make a real mess of the names,  and 2)   non-alpha graphics can be used as well.
(08:43:12 AM) CDot: who are we to dictate? If it passes the NameFilter, it's valid IMHO
(08:44:08 AM) gac410:   http://trunk.foswiki.org/Sandbox/Jomo.▁▂▃▅▆▇
(08:44:42 AM) CDot: :-)
(08:45:02 AM) gac410: I'm not saying we should dictate,  but that further controls might be nice to provide should the site administrator desire.
(08:45:40 AM) gac410: And with combining marks:    http://trunk.foswiki.org/Sandbox/Jomo/̴%CC%B5̶%CC%B7%CC%B8̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̃̄̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿͂͆͊͋͌̕̚Ι%CD%8F͓͔͕͖͙͚͐͑͒͗͛ͣ͘͜͟͢͝͞͠͡
(08:45:43 AM) CDot: you'll be wanting us to filter out swear words next :-(
(08:46:00 AM) gac410: No.   absolutely not
(08:47:02 AM) gac410: Okay   anyway,  issue raised.   The bug is the doubling of backslashes which I will work on.
(08:48:48 AM) gac410: I didn't do an agenda for today.    with 2.1 beta out,  shall we discuss any pending feature proposals for 2.2 /  3.0 ?
(08:51:36 AM) gac410: Okay,  for proposals where "14 day rule applies"   there are 21 of them.    I propose that if the developer appears to be missing, we "Park" them,  and ask that everyone else set proposals to either Accepted or as desired,  to clean up the list.
(08:51:39 AM) CDot: only interested in the %TMPL: and #{ proposals, both of which have had lively discussion
(08:52:00 AM) CDot: cleaning up is a great idea
(08:54:03 AM) gac410: ones with concern raised,  can everyone look them over to decide if they are either rejected,  withdrawn,  or need to go to community vote.   
(08:54:31 AM) CDot: can you give us a list (or a pointer to a search that generates one)?
(08:54:59 AM) gac410: Lets try to get the "Feature proposals" page to a state where it can be an agenda for these meetings.    http://foswiki.org/Development/FeatureProposals
(08:56:44 AM) gac410: UnderInvestigation category is massive,     and then http://foswiki.org/Development/FeatureProposals#Accepted_Feature_Proposals    really ought to be our "menu" for future releases. 
(08:57:55 AM) gac410: I don't think that page is ready to review in a meeting yet ... waste of time until it's cleaned up.    So let's discuss the active work.   
(08:58:25 AM) gac410: 1)   TMPL:macro    2) Comments    3)   vrurg's   restructuring 
(08:59:31 AM) jomo: vrurg works on the DeprecateErrorPm but only in his own branch - so don't know what to do with the proposal... should i withdraw it?
(09:00:16 AM) CDot: therein lies the path to a fork.....
(09:00:35 AM) gac410: Well it's a branch in the foswiki repo,  not a fork. 
(09:01:27 AM) gac410: So it could be merged.   but is part of a large restructuring.    Right now he is really just experimenting I think.
(09:01:56 AM) gac410: But he's not here to discuss.   I think he realizes that merging should we accept the proposal would be a massive effort.   
(09:02:44 AM) JulianLevens entered the room.
(09:03:44 AM) gac410: For CDot's  http://foswiki.org/Development/SupportAllMacrosInTemplateTopics     That seems to to be a needed and relatively straight forward enhancement.    7 days into the timer.  
(09:04:28 AM) gac410: *much* cleaner than the TWiki hack of  "EOTC__" as a macro prefix to cause expansion.  
(09:04:44 AM) CDot: the only debatable point is whether %TMPL: is the right syntax, since it somewhat conflates the skin template syntax with the macro syntax
(09:04:59 AM) CDot: but it *feels* right....
(09:05:28 AM) gac410: hm   well it does move the macro into the template expansion domain doesn't it?
(09:05:47 AM) CDot: well.... sort of. Template topics are a bit odd.
(09:05:54 AM) gac410: y for sure  :)
(09:06:07 AM) CDot: they are really like a topic that is rendered in two steps; one static, one dynamic
(09:06:35 AM) CDot: but the syntax seems fairly natural to me, so tempted just to go with it.
(09:07:19 AM) gac410: well 7 more days for the concrete to harden. 
(09:07:25 AM) CDot: :-)
(09:07:48 AM) Lynnwood [~Lynnwood@foswiki/developer/lynnwood] entered the room.
(09:08:50 AM) gac410: The topic comments is much more difficult.   http://foswiki.org/Development/ImproveSupportForComments
(09:10:12 AM) gac410: I tried a template comment on foswiki.org,  and it totally broke the rendering of our download topic ... So maybe I don't understand comments  
(09:10:20 AM) jomo: have no concerns... :)
(09:11:24 AM) gac410: http://foswiki.org/Download/FoswikiReleaseViewTemplate    has a verbatim class="foswikiHidden"  (NOT in a comment)   that hides a bunch of transcluded blocks
(09:11:40 AM) CDot: I don't think the comments are all that difficult; we've ironed it out now
(09:11:59 AM) CDot: gac410: so? That's OK
(09:12:19 AM) gac410: I tried converting that to %{     and the /verbatim to   }%       we don't need them in the download topic.
(09:12:31 AM) CDot: that won't work
(09:12:40 AM) gac410: As I said.   I don't undersand.
(09:12:44 AM) CDot: :-)
(09:13:24 AM) CDot: %{...}% is a *real* comment; anything in them plays no further part after the comment is removed
(09:13:50 AM) CDot: %{ verbatim>}% leverages the fact that in a normal topic view, %{...}% is *not* a comment
(09:14:05 AM) CDot: so the %{ verbatim>}% string persists into the renderer
(09:14:08 AM) gac410: Right.   But they are accessed using %INCLUDE section=    which processes the template topic ignoring themplate 
(09:14:58 AM) CDot: but when the topic is used as a skin template, skin template syntax rules apply, and the %{ verbatim>}% gets removed
(09:15:24 AM) CDot: it's basically just a way of making the skin template topic carry it's own documentation
(09:15:40 AM) gac410: if I %INCLUDE  a topic section ... so I'm reading the template topic as a topic,  not as a template,     won't include see the %{  }%   blocks
(09:16:02 AM) CDot: you will see them, yes
(09:16:07 AM) gac410: Just like viewing a template topic displays the %{  }% 
(09:16:15 AM) CDot: because %{ is not a comment delimiter in a normal topic view
(09:17:32 AM) gac410: Right.  That is what I expected.   So I should have been able to convert the (not a comment!)   verbatim class=foswikiHidden>     into a %{ ... hidden from template }%  block,  and still include from it.
(09:17:50 AM) CDot: yes, you should
(09:18:20 AM) gac410: okay.   So maybe it's some other syntax issue.   I'll review and then ask you some other time. rather than hijack the meeting.
(09:18:29 AM) CDot: y
(09:20:33 AM) gac410: So back to your proposal.   *topic* comments.   should 1)  Macros be active within them?    2)  Should * Set blah=   preferences be active in them.
(09:24:15 AM) jomo: comments should stop expensive macro executions... aren't?
(09:25:38 AM) gac410: Right.   But, if the purpose is to hide foswiki internals,   beyond just hiding documentation,   runtime %SET macros might be of some benefit to process from within comment blocks.
(09:26:35 AM) gac410:   * Set  statements are easily hidden in %META,  but runtime %SET have no way to be hidden.   
(09:27:14 AM) gac410: Anyway,  I should probably add that to the discussion topic.   and let it play out there.
(09:28:09 AM) gac410: Okay,  one other proposal http://foswiki.org/Development/AddValidationsToURLPARAMMacro    has really gathered no discussion, beyond an irc discussuion with vrurg a while back.
(09:29:32 AM) CDot: wow, first reaction to that is "urgh!"
(09:30:35 AM) gac410: :)    We have all those wonderful checkers in configure.    And I wondered why we shouldn't have something similar for wiki applications.
(09:30:46 AM) CDot: while I like the idea of validators on URL params, the idea of rewriting them..... stinks
(09:31:38 AM) CDot: %URLPARAM{"xyz" expect="integer"}% - but then what do you do if it in't
(09:31:43 AM) gac410: it was in hindsight after some xss scrubbing.   when I realized.   "We are scrubbing a field that really has only two valid values  "Yes" and "no"  
(09:33:05 AM) gac410: that was where the experiment got fuzzy.     1)   Throw an "oops",   2)  Return an inline  alert,   3)  Collect them and report in a validation report of some sort
(09:33:30 AM) CDot: has to be an inline alert (which is a shaky concept at best. I know)
(09:33:41 AM) gac410: After discussion with vrurg,  it seemed we needed to allow any of those options.
(09:34:11 AM) CDot: why? what other macros report failures through an oops?
(09:34:25 AM) CDot: or a validation report?
(09:34:44 AM) gac410: If the urlparam say was being used to create a topic,   an inline report would just end up in the topic.
(09:35:03 AM) gac410: And oops, means you get one... oops ... error ... oops ... at a time.
(09:35:03 AM) CDot: yuck
(09:35:49 AM) gac410: yeah.   So collecting the errors into a single oops   seems likely to be needed.
(09:35:51 AM) CDot: still think an inline alert would be appropriate
(09:36:06 AM) CDot: anything else is not KISS.
(09:38:10 AM) gac410: yeah,  I was having trouble figuring out where to actually collect them   Probably needed to add something hanging off $session->{urlerrors} or something
(09:38:28 AM) gac410: There is precedence for some other macros that I've found   though it's ugly.
(09:39:35 AM) gac410: Anyway,  it's a proposal that needs more discussion.
(09:40:01 AM) gac410: Any other proposals anyone wants to bring up for discussion?
(09:42:19 AM) gac410: Okay,   For our "Next release" ...    2.2 planned for sometime in the summer?    Does that give everyone enough time to get some interesting work done?
(09:42:20 AM) jomo: would be nice to get some more comments to the QuoVadisPsgiFoswiki... just for brainstorming... not here and now - but would be nice to know what the team want to achieve - in more details...
(09:43:27 AM) MichaelDaum: jomo, I think I made my point clear
(09:43:59 AM) MichaelDaum: I consider psgi + moo the future of foswiki
(09:44:23 AM) MichaelDaum: as well as sass
(09:45:07 AM) gac410: So as the current RM,    a big question is how do we accomplish a change like this without another 4-year black hole of development. 
(09:45:31 AM) gac410: As vrurg said,  merging will be hell if we keep adding incremental work to master.
(09:45:56 AM) CDot: that's the nature of collaborative dev
(09:46:14 AM) MichaelDaum: we need more of us to help vrurg
(09:46:26 AM) MichaelDaum: he is definitely in hero mode atm
(09:46:28 AM) CDot: the rewrite to use psgi is not a complete rewrite of foswiki
(09:46:42 AM) CDot: it's a rewrite of the engine layer (as I understand it)
(09:46:58 AM) gac410: vrurg is doing a rewrite to Moo  with a complete object restructuring.
(09:47:00 AM) CDot: plus a few bits to cushion where cgi has been abused
(09:47:53 AM) MichaelDaum: psgi and moo are two separate undertakings though not independent of each other. 
(09:48:27 AM) CDot: moo produces perl objects; I don't understand why objects can't move to moo incrementally
(09:48:34 AM) gac410: And Lavr raised a concern  ... of course because Centos doesn't have Moo available. 
(09:48:48 AM) CDot: seems fairly straightforward to me (albeit a big job)
(09:48:52 AM) MichaelDaum: Moo is available as pure-perl afaik
(09:49:01 AM) jomo: sry - i have  a pinter here.. ;( was AFK.. - yes, the only who commented nicely is MichaelDaum :)
(09:49:04 AM) CDot: moo is pure perl
(09:49:06 AM) jomo: painter
(09:49:13 AM) MichaelDaum: so Kenneth's concerns are easy to address
(09:49:34 AM) MichaelDaum: he did not re-comment though
(09:50:24 AM) gac410: Anwyay,    for a Summer release.    we could.  1)   Continue with incremental work with all the deferred changes from 2.1.  Michael, a lot of them were yours.
(09:50:38 AM) CDot: anyway, most of the existing foswiki objects could move to moo with barely a blink
(09:50:58 AM) gac410: or 2)  All hands on deck... help vrurg to the Mooification and PSGIfication   and that becomes 3.0 in summer?
(09:51:07 AM) gac410: or 3)   Both in parallel,  
(09:51:08 AM) MichaelDaum: Moo-ification of Foswiki would make an excellent marketing spash as well
(09:51:18 AM) CDot: at least, the ones where I was able to maintain strict encapsulation
(09:51:33 AM) MichaelDaum: yea some stuff is very un-oo-ish
(09:51:53 AM) CDot: i think there has to be some detail decisions about how moo is used before lots of work goes in
(09:52:13 AM) JulianLevens: vrurg agreed with me that the 1st phase of Moo is establishing a good base; not everything in one go
(09:52:21 AM) CDot: for example, so all field accesses have to move to accessors? That would be a hell of a lot of rewriting :-(
(09:52:40 AM) jomo: i don't think than the OO restructulasition (with some architectural changes) is real timing for the summer... just IMHO...
(09:53:20 AM) MichaelDaum: too bad he is not online atm, is he?
(09:53:21 AM) CDot: plus there are places where we do things that are in the spirit of OO, but leverage some of perl's features to do things more efficiently
(09:53:22 AM) JulianLevens: I think a foundation can be established for the summer
(09:53:43 AM) gac410: From a git perspective,   we could continue adding features to master,  and merge them with some pain into his Mooification branch.  
(09:53:58 AM) CDot: so I would expect a move to Moo will slow FW down by quite a bit, until re-optimisation can be performed
(09:54:13 AM) gac410: And then rename the Moo branch to master when we are ready.
(09:54:32 AM) CDot: fine, as long as all the tests pass :-)
(09:54:56 AM) vrurg entered the room.
(09:55:03 AM) CDot: speak of the devil
(09:55:07 AM) jomo: :) :)
(09:55:10 AM) vrurg: Hi there.
(09:55:17 AM) gac410: vrurg appears to be working on the tests as well,  which is excellent.  
(09:55:27 AM) vrurg: Sorry, don't have much time but few minutes.
(09:55:39 AM) CDot: gac410: is there a log for Vadim to read?
(09:55:50 AM) gac410: no not yet. ... this channel isn't logged
(09:56:02 AM) ***gac410 wonders if we ought to hold release meetings in the main channel.
(09:56:04 AM) CDot: c+p to pastebin?
(09:56:11 AM) gac410: one moment. 
(09:56:23 AM) JulianLevens: http://pastebin.com/LyTZ6t9w
(09:58:21 AM) gac410: you beat me  :)
(10:00:44 AM) gac410: So the question vrurg  is  could your mooification effort be a foundation for a July/August  3.0 release,     
(10:01:19 AM) vrurg: I haven't read the discussion all the way down but have a note to CDot : moving to Moo isn't that simple. It's model is pretty much different from Perl's default. Look at Foswiki::Address which I was working on just yesterday. In Moo processing of parameters and object initialization are separate whereas in the Address it's mixed and spread across several subs.
(10:02:56 AM) CDot: ok, but (1) moo and default perl objects can coexist (2) a moo object can subclass a default perl object
(10:03:03 AM) CDot: so a change can be done incrementally
(10:03:05 AM) vrurg: gac410: I hope so. Depending on the time I have it could either be just a solid base for redesign of the core or something more. I hope for more.
(10:03:13 AM) gac410: I think what we want to avoid is a multi-year black hole of develompent.     So can there be a step-wise  migration
(10:03:43 AM) vrurg: CDot: but that's the worst way to do it and it kill the whole point of the job.
(10:04:34 AM) ***CDot puts his hands up and turns away. If it can't be done incrementally, then hero is the only way.
(10:05:09 AM) gac410: CDot passes hero hat to vrurg. ...   He wore it long enough with the Configure redesign  :D
(10:05:39 AM) CDot: gac410: and for many years before that. Since about 2004, I think.
(10:05:47 AM) gac410: y.   :)
(10:05:57 AM) JulianLevens: Hero not necessary? We all seem to be in  favour of this and indeed want to get there; so establish a great base and then quickly move to finish the job soon after
(10:06:11 AM) MichaelDaum: JulianLevens, +1
(10:06:15 AM) vrurg: gac410: If nothing changes I get the whole core+test framework migrated in ~2month. By then we'd better work out a new model for the OO based API, agree on the ways of moving plugins into OO paradigm and exceptions structure.
(10:07:05 AM) CDot: sounds great
(10:07:39 AM) CDot: note that what changes do occur tend to be small, so should not be hard to port
(10:07:46 AM) vrurg: With clear plan I'd say it'll take another 2 month to get 3.0 beta out. For these 2months 2.0 has to be in feature-freeze state.
(10:07:54 AM) vrurg: 2.x, actually...
(10:08:14 AM) CDot: however it's not clear to me why you are not tackling this on a subsystem basis
(10:08:37 AM) CDot: e.g. start by moving the user management over, then the store, then.....
(10:09:02 AM) JulianLevens: y, I was looking at Meta last year and thinking about redesign and dreaming of using Moo
(10:09:13 AM) JulianLevens: Could just start with that
(10:09:28 AM) CDot: meta is a nightmare piece of knitting. Possibly the worst place to start :-(
(10:09:36 AM) JulianLevens: Might not be the best starting point though
(10:09:56 AM) gac410: before we lose you ... vrurg,  is there a time/timezone that would work better for you for discussions on your efforts.
(10:09:56 AM) CDot: it's the place I put things when i couldn't figure out a better place :-(
(10:09:59 AM) JulianLevens: y, it requires some serious untangling as well
(10:10:21 AM) vrurg: CDot: Reason 1: I'm not that familiar with the internals; 2 – I want working tests, so for now I depend on their order; 3 – I learn the core that way too. Not the best reasoning, but it keeps me motivated.
(10:11:06 AM) CDot: ok, fair points. The tests overlap in some places, but are generally per-subsystem
(10:11:25 AM) CDot: the subsystems themselves are in subdirs of Foswiki
(10:12:16 AM) gac410: I'd say we treat vrurg's  branch to be the   "MooMaster" branch  :D    and rather than a feature freeze,  we can try to merge small features into both master an MooMaster?  
(10:12:17 AM) CDot: e.g. Foswiki/Store, Foswiki/Users, Foswiki/Prefs, Foswiki/Search
(10:12:32 AM) vrurg: gac410: I'm in Miami. Considering our Europeans this period would be the best anyway. It's just the time I work with my Ukranian team so might be busy sometimes.
(10:13:38 AM) CDot: FWIW it's essential that other people do work on the Moo branch. if we end up with only Vadim understanding it, we are lost.
(10:13:57 AM) CDot: so merging to both master and moo is the only way
(10:14:02 AM) gac410: +1
(10:14:33 AM) gac410: vrurg,  so the "MooMaster"  is currently  remotes/origin/Item13897 ....  maybe we should rename it to be obvious :)
(10:14:48 AM) ***vrurg though that the branch is just a playground.............
(10:14:58 AM) gac410: They are whatever we want them to be.  
(10:15:00 AM) vrurg: Yes, it is. 
(10:15:21 AM) vrurg: Shall we make it more meaningful name then?
(10:15:56 AM) gac410: If the playground is promising we can merge it,   or we can eventually rename it to be the new master.    Though not sure how that works out when people pull 
(10:19:05 AM) vrurg: gac410: Actually I was always opposed to the model where the master is the main release line. To me it looks more clear when it's more tree-like with, say, major release branching from the master and minors are branching from their respective majors. But that's something from another topic and not a big matter whatsoever.
(10:19:20 AM) gac410: Why don't we leave this that ... dev's should review Item13897 branch,  and vrurg,  you let us know when you want everyone to "pile on"  
(10:20:41 AM) gac410: And when you are ready,  we'll have to figure out a rename that will still work with posting commits to tasks.
(10:21:34 AM) vrurg: What I'd like to have for the moment is the plan I mentioned above. Unfortuntanely, I don't have clear overview of the core to build plans like that. I do want plugins to become objects but this pulls out the question on handling documents/inclusions where me expertise is barely above zero.
(10:21:38 AM) gac410: I have to review FoswikiOrgPlugin ...   currently it expects a branch to be a task ID
(10:23:41 AM) gac410: So what do you need from us.    It seems we want to go in your general direction.  But it's early enough you need to steer for a bit more to flesh things out.
(10:26:01 AM) gac410: Anyway ...   any further business?     Shall we wrap this up?  
(10:26:31 AM) JulianLevens: Nothing from me
(10:26:40 AM) MichaelDaum: good discussion
(10:26:58 AM) gac410: Yes indeed.   2016 will be an interesting year.
(10:27:02 AM) JulianLevens: y, needs to be captured
(10:27:08 AM) vrurg: gac410: I'd get back on this in a week or two. So far I still have questions to myself. 
(10:27:13 AM) vrurg: Gotta go, cu!
(10:27:18 AM) gac410: thanks vrurg
(10:27:22 AM) JulianLevens: Can we get this channel logged in the future?
(10:27:52 AM) jomo: cu vrurg :)
(10:28:02 AM) gac410: JulianLevens:   Yes   it will be captured.   I c/p each meeting into a ReleaseMeeting_YYYYMMDD  topic in development'
(10:28:15 AM) gac410: But I missed the meeting before christmas.  The rest are all there.
(10:28:43 AM) gac410: See http://foswiki.org/Development/ReleaseMeetings
(10:29:15 AM) gac410: Thanks everyone.  great meeting.