Release Meeting: 13 Oct 2014

 
  Conversation with #foswiki-release at Mon 13 Oct 2014 08:29:05 AM EDT on gac410@chat.freenode.net (irc)

   (09:02:08 AM) MichaelDaum: hey there
   (09:02:20 AM) gac410: Hi MichaelDaum, Marcus
   (09:02:28 AM) MichaelDaum: how is it going
   (09:02:41 AM) gac410: Good I guess here. Still on first cuppa
   (09:05:10 AM) Lynnwood [~lynnwood@foswiki/developer/lynnwood] entered the room.
   (09:05:45 AM) gac410: good morning Lynnwood
   (09:05:54 AM) Lynnwood: you also
   (09:11:36 AM) gac410: Well 10 minutes overdue ... Lets get started.
   (09:13:04 AM) gac410: I removed git from the agenda. So lets start with the new configure.
   (09:14:41 AM) gac410: The list in http://foswiki.org/Tasks/Item12952 is looking pretty well under control. 4 open issues
   (09:15:46 AM) JulianLevens  entered the room.
   (09:16:33 AM) gac410: Changes not logged, jsonrpc activity not logged in event log (not really a configure issue), Save pending changes counter doesn't reset to zero (cosmetic) And exension installer doesn' t populate Config.spec defaults.
   (09:17:02 AM) gac410: The latter is probably the most serious. Anyone have anything to add?
   (09:17:41 AM) CDot [~crawford@foswiki/developer/cdot] entered the room.
   (09:17:53 AM) CDot: je suis ici
   (09:17:57 AM) gac410: Ah... cdot heard we were talking about configure :D
   (09:18:11 AM) CDot: no; is there a log?
   (09:18:34 AM) gac410: I'll repeat my comments. Looking under control. 4 "issues" on 12952
   (09:18:35 AM) gac410: Changes not logged, jsonrpc activity not logged in event log (not really a configure issue), Save pending changes counter doesn't reset to zero (cosmetic) And exension installer doesn' t populate Config.spec defaults.
   (09:18:43 AM) gac410: The latter is probably the most serious. Anyone have anything to add?
   (09:18:55 AM) gac410: That's the extent of the discussion so far :)
   (09:19:30 AM) CDot: extension installer isnʼt really configure, though I can see why youʼd try to make it so
   (09:20:28 AM) gac410: Well, it can breaky your system. It enables the extension, but if user saves config with unpopulated Config.spec, it is possible the system will break.
   (09:20:43 AM) gac410: Can't get to config.spec though without reloading configure.
   (09:20:50 AM) gac410: Bit of a catch22
   (09:21:40 AM) gac410: If we can't popoulate config.spec, we should probably also not populate the Enable / module flag, and require a reload to get all the settings.
   (09:21:52 AM) gac410: It's safer
   (09:22:05 AM) CDot: y
   (09:22:20 AM) CDot: we *can* make it populate config.spec
   (09:22:32 AM) CDot: all we need to do is return a set block from the wizard
   (09:22:45 AM) CDot: that will then get reflected in the UI
   (09:23:03 AM) CDot: same as the enable flag
   (09:23:13 AM) CDot: not hard to do
   (09:23:35 AM) gac410: hm. Even ignoring the wizard, there is still a bug then. If you install an extension (unzip, shell, ...) then Config.spec is populated, but *defaults* are not, so all the spec is undef.
   (09:23:50 AM) gac410: which for some extensinos is a crash.
   (09:24:19 AM) CDot: huh?
   (09:24:41 AM) gac410: The Config.spec is loaded, but the settings are all undef.
   (09:24:45 AM) CDot: oic. Well, Iʼd class that as a bug in the extesnion
   (09:24:59 AM) CDot: *no* extension should crash the sys if config.spec is missing
   (09:25:08 AM) CDot: sensible defaults, people!
   (09:25:33 AM) gac410: Sigh... Are you going to review 500+ extensions and figure out which ones can't deal with undef settings?
   (09:25:46 AM) gac410: The values are in the COnfig.spec Configure ignores them.
   (09:26:09 AM) gac410: You even have a subroutine to "Apply the defaults" Can't remember the name, but it's never called.
   (09:26:10 AM) CDot: no; but then we donʼt review extensions for lines reading "die "broken";" either
   (09:26:27 AM) gac410: It is a major operational change from 1.1.
   (09:26:45 AM) CDot: yeah, yeah. The simplest solution is for the shel extension installer to concat Config.spec to LSC
   (09:26:47 AM) gac410: 1.1 applies the default settings from Config.spec. 1.2 throws them away.
   (09:27:11 AM) CDot: does it? I thought it worked the same
   (09:28:17 AM) gac410: sub _addCfgValuesToSpec { is never caled when a new config.spec is loaded.
   (09:28:39 AM) gac410: No definitely not the same
   (09:28:56 AM) CDot: you mean in the wizard?
   (09:29:24 AM) gac410: Ah... no in JSONRPC.
   (09:29:33 AM) CDot: huh?
   (09:30:05 AM) gac410: ConfigurePlugin defines getSpec and getCfg ... two subroutines. When a new Spec file is discovered, getSpec loads the definitions, getCfg is never called to apply the values.
   (09:30:42 AM) CDot: no. th model is that the wizard passes new values back to the UI where they are applied
   (09:31:05 AM) CDot: then, when a check or a save is called, the new values are passed from the UI and added to the saved LSC
   (09:31:15 AM) gac410: So if the Spec was not previously merged into LocalSite.cfg then the defaults are never picked up. You have to click the liittle "default value" clickie to pick up each default, one at a time.
   (09:32:33 AM) CDot: I will have to look at this in the UI. It is supposed to work. A defasult is only defined when there is a .spec to get it from
   (09:32:55 AM) CDot: in the case of a new extension, the .spec has not been read yet, so there is no applicable default
   (09:32:58 AM) gac410: To the right of each spec is two little boxes. Undo change, and Restore "Default"
   (09:33:12 AM) CDot: also, there are no UI elements for the new extension yet
   (09:33:23 AM) gac410: After a new extensino is installed say from the shell, ALL of the fields are empty, "undef"
   (09:33:45 AM) gac410: But all have a [d] apply default clicker. So the UI knows them but has not applied them.
   (09:33:56 AM) CDot: OK, I see what you are getting at
   (09:34:12 AM) CDot: thatʼs because they are missing from LSC
   (09:34:25 AM) CDot: the default is not *automatically* applied, no
   (09:34:33 AM) gac410: So you end up with checker errors for nearly every new spec entry, and have to reveal expert and go clickey the [d] to clear all the errors.
   (09:34:49 AM) CDot: gotcha
   (09:34:52 AM) gac410: This is a huge change from 1.2
   (09:35:11 AM) CDot: from 1.2? This *is* 1.2...
   (09:35:17 AM) gac410: sorry 1.1 typo
   (09:35:24 AM) CDot: k
   (09:35:34 AM) gac410: and even 1.2 pre-rewrite.
   (09:36:11 AM) CDot: y. I changed that behaviour because it is really dangerous
   (09:36:27 AM) CDot: I will take another look at it.
   (09:36:28 AM) gac410: tbh, I'm really happy with both configure and bootstrap. I think it's clearly beta quality. But I'd consider the everything undefed / crash after enable a blocker.
   (09:37:10 AM) CDot: of course. I wasnʼt aware of this issue, so....
   (09:37:35 AM) gac410: :)
   (09:38:05 AM) gac410: Anything else on configure now that I'm finished pummeling cdot
   (09:39:45 AM) gac410: MichaelDaum: I know you were concerned about the look/feel. Can you live with what we have?
   (09:39:55 AM) MichaelDaum: no but I have to
   (09:40:27 AM) MichaelDaum: I will be on vacation the next 2 weeks
   (09:41:00 AM) MichaelDaum: and honestly felt quite desperate working on a code to come to _any_ different look and feel
   (09:41:34 AM) CDot: ?
   (09:42:02 AM) gac410: Configure is a bit of a "necessary evil" I think that trying to make it pretty is unnecessary
   (09:42:31 AM) gac410: As long as it is fast, robust/reliable, not brittle, and leaves you with a running system :)
   (09:43:52 AM) MichaelDaum: there is lots of stuff that Iʼd do differently
   (09:44:00 AM) MichaelDaum: just a few things:
   (09:44:11 AM) MichaelDaum: (1) remove "Study Web Server"
   (09:44:18 AM) gac410: +1
   (09:44:32 AM) MichaelDaum: (2) make show expert options less prominent ... i.e. not next to Save
   (09:44:50 AM) MichaelDaum: (3) convert the top-most tabpane layer to a left-side navigation
   (09:45:13 AM) MichaelDaum: (4) only load the current "tab" ... not all of them at first load
   (09:45:17 AM) CDot: 1 & 2 both template mods. 3 needs some JS, which is why Iʼm reluctant
   (09:45:32 AM) CDot: it already only loads the current tab
   (09:45:44 AM) MichaelDaum: (5) have a "Save" button per section ... not one big "Save" for all changes wherever they occurred
   (09:46:09 AM) gac410: 5) is a really huge change, and will probably break a lot of stuff.
   (09:46:18 AM) CDot: y, the save per section would be easy to do. the model is in the code already.
   (09:46:42 AM) CDot: just requires a bit of care in the JS.
   (09:46:47 AM) MichaelDaum: (6) simplify each nodeʼs UI ... button, label, reset, etc this all does not look "right"
   (09:47:02 AM) CDot: agreed. Just my best guess.
   (09:47:26 AM) MichaelDaum: (7) extensions tab needs to be rendered differently vs the rest of the tabs
   (09:48:13 AM) gac410: y, extensions with the multi-row tabs when lots of extensions installed it probably the most confusing.
   (09:48:14 AM) CDot: now *that* would be tricky.
   (09:48:16 AM) MichaelDaum: add (7) enabling an extension & configuring it should be "close" to each other ... not a separate thing that I need to look up both separately
   (09:48:51 AM) MichaelDaum: (sorry for my denglisch)
   (09:49:32 AM) CDot: all doable, but ..... i am not likely to do any of these things. i bust a gut to get configure done already, and my gut busting needs a bit of a break.
   (09:49:32 AM) MichaelDaum: anyway. these are the top 7 complains that I have
   (09:50:05 AM) MichaelDaum: CDot, you rushed an UI too early. now it seems carved in stone.
   (09:50:11 AM) CDot: so, by all means make a task of "things to do" and we can knock them off as-and-when
   (09:50:43 AM) CDot: carved in stone? far from it
   (09:50:59 AM) CDot: itʼs more a question of time to do these things
   (09:51:00 AM) MichaelDaum: configure fires much too many jsonrpc requests before a tab is actually touched by a user
   (09:51:02 AM) gac410: I don't see it as carved in stone, it was a very simple "first pass" to streamline what now in hindsight, was a nightmare.
   (09:51:06 AM) CDot: Iʼm quite happy to see it imporve
   (09:51:36 AM) CDot: I just did the simplest thing I could think of, to get to "here" from "there".
   (09:51:47 AM) MichaelDaum: i see
   (09:52:21 AM) MichaelDaum: it simply is not a product that Iʼd call finished
   (09:53:02 AM) MichaelDaum: unfortunately , the amount of changes that Iʼd love to see require more in depth changes to the javascript code because there is no proper separation between control and view
   (09:53:04 AM) gac410: Our product is the wiki. Configure would be best if we didn't need it at all. :)
   (09:53:04 AM) CDot: agreed, it isnʼt. I recall asking for help on the UI - and you gave me a lot, thank you
   (09:53:23 AM) CDot: but there remains a lot to be done. Iʼve built the framework.....
   (09:53:57 AM) CDot: I focused very much on the perl side of things, so the services you need for a good JS UI are there (I hope)
   (09:54:32 AM) CDot: I moved all the UI resonsibilities into the template and the UI code itself, to keep the service UI neutral
   (09:54:36 AM) gac410: The really huge effort, and extremely valuable, was the separation of the UI from the configuration. all on the perl side. Configure until CDots work was unmaintainiable going forward.
   (09:54:42 AM) MichaelDaum: there is some herring there too, innate by the way spec files are written: they form the model of what the view is supposed to look like
   (09:54:47 AM) CDot: so you can develop a new UI without touching the exiting one
   (09:55:01 AM) CDot: yeah, thatʼs a problem, I know
   (09:55:15 AM) CDot: itʼs historical, that is
   (09:55:19 AM) MichaelDaum: so there isnʼt even a proper separation of the spec model between both control and view
   (09:55:34 AM) MichaelDaum: I know. I just mention the problems and their roots
   (09:55:36 AM) CDot: you *could* ignore the headlines, and drive it (for example) from the Foswiki::cfg hash structure
   (09:55:45 AM) gac410: There is only so much ocean you can boil in a single pass.
   (09:55:47 AM) CDot: but unfortunately thatʼs even more of a mess :-(
   (09:55:53 AM) MichaelDaum: ya
   (09:56:50 AM) JulianLevens left the room (quit: Quit: JulianLevens).
   (09:57:06 AM) MichaelDaum: maybe Iʼve been exposed to angularjs for too long already. and now my critics are harder than they should be. sorry.
   (09:58:27 AM) CDot: not a problem, I can take it :-) but Iʼm not likely to do anything about it, at least not in the short term
   (09:58:33 AM) MichaelDaum: (8) just tried the new search ... woops
   (09:58:37 AM) gac410: I suggest that sometime in the next week or so, we close 12952, Open tasks for new issues.
   (09:58:42 AM) CDot: I have neglected my plugins, and some of the core code
   (09:59:00 AM) CDot: and really need to balance my workload.
   (09:59:08 AM) MichaelDaum: same same, CDot
   (09:59:34 AM) MichaelDaum: letʼs quickly drop some words on configureʼs search
   (09:59:47 AM) MichaelDaum: could you shed some light what this is going to be in the end?
   (10:00:15 AM) CDot: itʼs currently an experiment, a really crude search of keys and headlines
   (10:00:20 AM) MichaelDaum: for now I simply get some weird blob of text where a hit was found.
   (10:00:38 AM) CDot: so you can find a specific setting without full info
   (10:01:00 AM) CDot: the general idea is to help bad memories and assist linking from documentation
   (10:01:11 AM) MichaelDaum: nice
   (10:01:16 AM) CDot: but if itʼs not useful, it can be dropped easily
   (10:01:36 AM) MichaelDaum: in fact this would be a very welcome feature for configure users
   (10:01:45 AM) gac410: I've found it quite useful esp. vs ckicking tab after tab trying to find something
   (10:01:57 AM) gac410: Then enabling expert and doing it again :)
   (10:01:58 AM) MichaelDaum: ... if only it would lead me to the actual section where the search hit was found ...
   (10:02:20 AM) CDot: good. The UI needs improving to locate the search hits
   (10:02:30 AM) CDot: at the moment itʼs a case of "the simplest thing" again
   (10:02:44 AM) MichaelDaum: some kind of highlighting to indicate a trail to hunt down stuff
   (10:03:03 AM) CDot: something like that
   (10:03:14 AM) MichaelDaum: or just hide anything that does _not_ match
   (10:03:16 AM) CDot: or even opening the tab for a single matched item
   (10:03:34 AM) MichaelDaum: similar to chromeʼs search in its settings
   (10:03:50 AM) CDot: chrome, or chromium?
   (10:04:04 AM) CDot: they may be the same; itʼs just I have both
   (10:04:31 AM) MichaelDaum: they are the same in that respect
   (10:04:54 AM) MichaelDaum: I like their settings ui. this is _really_ the simplest possible thing that could work.
   (10:05:55 AM) gac410: Okay... 1 hour timecheck. I think we've abused CDot enough :) Any tasks to review? There was one new blocker this week Item13051 " in $pattern not escaped.
   (10:06:03 AM) MichaelDaum: I _always_ use their search/filter feature and never follow a menu ... which might indicate another ux prob.
   (10:06:59 AM) CDot: given that itʼs existed since TMwiki "athens" I doubt it qualifies as Urgent, but.... itʼs tacky
   (10:07:11 AM) CDot: (13051 Iʼm talking about)
   (10:07:39 AM) CDot: maybe not athens; maybe beijing. A long time, anyway
   (10:08:06 AM) gac410: Yeah, no problem making it urgent though. Given the noise in tasks, it's the only way to get any visibiility
   (10:08:43 AM) CDot: in a way it *is* utgent, because without a fix JsonReport will not work properly
   (10:08:55 AM) CDot: ^properly^100% reliably
   (10:09:31 AM) ***MichaelDaum looks at JsonReport
   (10:09:41 AM) gac410: Is it safe to always escape, or could there be use cases for $pattern where un-escaped quotes are expected
   (10:09:51 AM) MichaelDaum: http://foswiki.org/Extensions/JsonReport?raw=all
   (10:10:05 AM) MichaelDaum: omg
   (10:10:20 AM) CDot: y, nasty, innit >:-)
   (10:10:34 AM) MichaelDaum: fixing this is pretty simple actually ... only a lot of work
   (10:10:51 AM) MichaelDaum: this is caused by us not storing structured data properly per extension
   (10:11:08 AM) CDot: true
   (10:11:10 AM) MichaelDaum: instead it has to be grepʼed out of raw text
   (10:11:34 AM) MichaelDaum: there are more issues interfering here and each should be addressed separately imho
   (10:11:43 AM) gac410: If SHORTPATTERN contains a ", then this breaks. True?
   (10:11:45 AM) CDot: $formfield also has the same problem
   (10:11:50 AM) CDot: itʼs not just $pattern
   (10:12:05 AM) MichaelDaum: once structured data is stored in a structured way, 13051 isnʼt urgent anymore ... to foswiki.org
   (10:12:31 AM) gac410: er... SHORTDESCRIPTION
   (10:12:36 AM) MichaelDaum: the other option is to use a rest handler to compute a JsonReport
   (10:12:56 AM) MichaelDaum: ... as part of FoswikiOrgPlugin
   (10:13:00 AM) CDot: if thereʼs some other way to get JSON content from a topic then yes, I agree MichaelDaum. But there is no *default* way to do that
   (10:13:39 AM) CDot: y, it could be done in FoswikiorgPlugin - but I specifically designed the code so that other repositories could be added
   (10:13:48 AM) MichaelDaum: probably 100% reliably is only JSON.pmʼs encode() on whatever you throw at it
   (10:14:17 AM) CDot: y, and getting a JSON copy of the topic $meta would be perfect
   (10:14:28 AM) CDot: but we don;t support serving that content
   (10:14:31 AM) gac410: hm... Could $pattern and $formfield and other s behave differently when contenttype = json
   (10:14:45 AM) ***CDot notes the wierd selection of content-typeʼs supported in Foswiki.pm
   (10:14:59 AM) CDot: gac410: yes - but that would be a worse hask
   (10:15:05 AM) MichaelDaum: yet another "minimal" mode?
   (10:15:29 AM) ***gac410 good at ʼworse hacksʼ
   (10:15:39 AM) CDot: y; content-type=application/json recognised and handled differently
   (10:15:40 AM) MichaelDaum: ;)
   (10:15:46 AM) CDot: it *could* be done, but......
   (10:16:00 AM) MichaelDaum: butt ugly
   (10:16:10 AM) CDot: your words, not mine -)
   (10:17:02 AM) CDot: good way to start developing a "live skin"
   (10:17:24 AM) MichaelDaum: jsonrpc is quite fine extracting json from raw data
   (10:17:24 AM) ***CDot shuts up - we donʼt want to go there.
   (10:17:40 AM) CDot: y, and JsonRPCContrib is no a core extension
   (10:17:43 AM) CDot: now
   (10:18:10 AM) MichaelDaum: okay now we have three paths to solve this at least
   (10:18:25 AM) MichaelDaum: (1) fix %SEARCHʼs $pattern and add some sort of escaping
   (10:18:32 AM) CDot: well, i think the $pattern issue needs fixing whatever we do
   (10:18:39 AM) MichaelDaum: (2) convert extension meta to a proper DataForm
   (10:18:40 AM) CDot: $pattern and $formfield
   (10:19:01 AM) CDot: (2) fixes it for old versions of FW too
   (10:19:02 AM) MichaelDaum: (3) write a jsonrpc handler in FoswikiOrgPlugin that delivers the data required
   (10:19:28 AM) CDot: given that fw.o has to run 1.1.9 for now anyway
   (10:20:07 AM) CDot: personally I think (1) is probably the least work, but it doesnʼt fix old fw versions
   (10:20:23 AM) CDot: (2) is a lot of work, but could fix old fwʼs
   (10:20:49 AM) MichaelDaum: (2) would break non-f.o repos
   (10:21:13 AM) MichaelDaum: but Imho, (2) would have been the right thing to do from day 1
   (10:22:57 AM) gac410: So if we do 2), then we'd need to ship a tool to restructure existing repos.
   (10:22:57 AM) gac410: Speaking of hacks, http://foswiki.org/Tasks/Item12477 Spurious entries to .changes. I'm struggling a bit on how to fix this. I'm leaning towards "normalizing" the .changes file, one field per column.
   (10:23:41 AM) gac410: As long as all users of .changes use the eachChange iterator, it's probably safe to change the layout. Iterator has to recognize old vs new format.
   (10:23:48 AM) MichaelDaum: other repos need to install some sort of JsonReport endpoint anyway, doesnʼt it?
   (10:24:36 AM) gac410: good point. yes, we probably should add the new report into the BugsContrib. That's sorely in need of a facelift.
   (10:27:56 AM) ***gac410 is throwing in the towel on http://foswiki.org/Tasks/Item12926 ... someone else needs to fix that one. or we just remove the security checks for subscribe. strikeone / POST
   (10:30:00 AM) gac410: Any other comments? we are at 1.5 hours, time to adjourn?
   (10:31:20 AM) MichaelDaum: guys, I have some other urgent tasks to take care of right now before leaving into vacation
   (10:32:01 AM) gac410: I think we need to wrap up.
   (10:32:03 AM) ***CDot is readinf 12926
   (10:32:34 AM) CDot: I thought Iʼd fixed that, several weeks ago
   (10:33:28 AM) ***CDot will research it.
   (10:33:30 AM) gac410: no checkins against the task.
   (10:33:41 AM) CDot: no, it was in a different context
   (10:33:43 AM) gac410: Thanks MichaelDaum ... Have a good vacation
   (10:33:48 AM) CDot: same issue
   (10:34:02 AM) MichaelDaum: thanks. hopefully there will be some wifi.
   (10:34:15 AM) CDot: MichaelDaum: have a good time, and wherever youʼre going, get your towel down first.
   (10:34:19 AM) gac410: :) Nah... sometimes better to be disconnected.
   (10:34:45 AM) gac410: Though first day back email backlog is a real pain.
   (10:36:27 AM) ***CDot doesnʼt understand why gac410 doesnʼt just fix 12962, as he seems to have a grasp of the problem
   (10:36:38 AM) CDot: 12926, I mean
   (10:37:29 AM) ***gac410 doesnʼt know how to manipulate a simple GET url into a form POST complete with a harvested strikeone that does not then kill some other strikeone
   (10:37:51 AM) gac410: head explodes as he digs into javascript and browser dom.
   (10:37:57 AM) CDot: the whole point of strikeone is that it kills all other strikeones from that page
   (10:38:12 AM) CDot: if it didnʼt, it wouldnʼt work as a security device
   (10:40:13 AM) gac410: It's really ugly though, SubscribePlugin returns JSON, which then clears the browser page into a plaintext json results, or some browsers give you a "file save" dialog after pressing subscribe.
   (10:41:24 AM) gac410: Subscribe used to be a GET that redirected back to the current page. Now it's a POST that returns JSON that nothing handles.
   (10:43:20 AM) gac410: Anyway ... I need to get some other stuff done too. Unless any more items to review, let's adjourn. We can discuss stuff in the main channel as time permits.
   (10:44:51 AM) gac410: Ideally the top bar subscribe link would just render as an appropriately styled button which does the Form POST for it's action. Rather than trying to convert a get url to a post.
   (10:45:32 AM) gac410: I tried to do that as well, and no matter what I did, the post button would not style. Can't change the css style cascade, or the existing styles don't apply.
   (10:46:07 AM) CDot: ok
   (10:49:17 AM) gac410: Thanks everyone ... I'll get the minutes posted this evening. Stuff to get done during the day today.
   (11:12:20 AM) MichaelDaum left the room (quit: ).
   (11:24:38 AM) CDot left the room (quit: Quit: Leaving.).
   (01:52:44 PM) Lynnwood left the room.