Release Meeting: 09 Sep 2015

Conversation with #foswiki-release at Mon 07 Sep 2015 08:13:08 AM EDT on gac410@chat.freenode.net (irc)
(08:52:57 AM) CDot entered the room.
(08:57:56 AM) jast entered the room.
(09:00:52 AM) gac410: Hi everyone ...
(09:01:41 AM) gac410: I didn't put much on the agenda today: http://foswiki.org/Development/ReleaseMeeting02x01_20150907
(09:01:47 AM) CDot: hi george
(09:02:28 AM) gac410: Hi Crawford. Thanks for wrangling out the ERP issues.
(09:02:33 AM) ***CDot can't understand why Florian's test run failed - all the ERP and Tables unit tests pass for me :-(
(09:02:42 AM) gac410: They passed here as well.
(09:02:59 AM) CDot: possibly need Florian to check ....
(09:03:15 AM) andreli entered the room.
(09:03:34 AM) andreli: Hello
(09:03:35 AM) gac410: y. Or it may have just been timing. I have not seen any more failure reports since late yesterday.
(09:03:39 AM) MichaelDaum: Hey guys
(09:04:31 AM) CDot: I think I checked in early yesterday. Was off watching the Tour of Britain in the afternoon.
(09:05:22 AM) CDot: anyway, watch this space. i suspect a git merge failure or summat.
(09:06:04 AM) CDot: hi MichaelDaum. nice work on the f.o landing page, BTW.
(09:06:28 AM) gac410: I agree. I just looked at the last test run, and the SPEC failures clearly have to be a merge issue of some sort.
(09:07:00 AM) CDot: aye
(09:07:46 AM) gac410: I think we can declare Item13570 fixed ... but would be good if Lavr could beat on it a bit. But I'm happy as is for a 2.0.2 release.
(09:07:53 AM) CDot: :-)
(09:08:55 AM) gac410: The other open tasks. http://foswiki.org/Tasks/Item13654 is really an API issue exposed by the uft-8 change. Func::saveFile may or may not need the utf-8 encoding
(09:09:25 AM) CDot: indeed. As I commented, I favour deprecating the function anyway.
(09:09:44 AM) gac410: Any extension that uses it to save topic text, will probably want the utf-8 encoding. But anyone using it for binary data will need bytes.
(09:10:13 AM) gac410: Well to deprecate it we need a feature proposal, and it pushes off the fix until 2.2 iirc
(09:10:25 AM) CDot: sure. Just my 2cents.
(09:10:42 AM) Lavr: Hi all. Yes. The only ERP issues I have right now are not release stoppers. ERP in its current state is working now
(09:10:52 AM) CDot: I think perl provides a perfectly fine API for saving failes.
(09:11:01 AM) gac410: Excellent. Thanks kenneth.
(09:11:28 AM) CDot: I tried to use ERP with disabled JS this morning. Not a happy experience.
(09:11:48 AM) CDot: My inclination is to drop support for non-JS, as it makes the code far too complex.
(09:12:11 AM) gac410: CDot, the addition of locking to saveFile might make sense ... hide some complexity from extensions. I separated out that request into another task
(09:12:42 AM) CDot: no, bollocks to that. Plugin authors are big people, they can use flock.
(09:13:14 AM) Lavr: If Func::saveFile was reverted back to saving raw - would that harm any existing plugins?
(09:13:15 AM) gac410: dropping support for non-JS. ... +1, Foswiki is becoming more and more dependent upon js at this point. It's no surprise
(09:13:27 AM) CDot: don't see why we have to hold their hands this way (esp. since there are plenty other ways they can shoot themselves in the foot)
(09:13:38 AM) Lavr: I have never tested none JS. I assumed nothing would work
(09:14:17 AM) CDot: right now, nothing does :-(
(09:14:39 AM) CDot: question is, can I be bothered trying to fix it, or would the time be better spent elsewhere
(09:14:57 AM) gac410: Lavr, I think saveFile should revert to saving raw. And it's a 2.0 extension requirement to add the conversion to byte strings as part of migration to 2.0
(09:15:02 AM) Lavr: I cannot believe anyone can have a browser with permanently disabled JS. You cannot get far on the internet today'
(09:15:11 AM) CDot: Lavr: +1
(09:15:24 AM) gac410: CDot, I agree. don't bother trying to make non-JS work.
(09:15:41 AM) jast: I use NoScript and similar things extensively, but I do enable script if it's unavoidable
(09:16:19 AM) gac410: I use noscript as well. and am horribly annoyed by sites that show nothing without enabling a dozen or so js sources.
(09:16:29 AM) jast: regarding saveFile, binary is definitely the only sane default. an API change to optionally enable encoding would be nice, I guess.
(09:16:33 AM) jast: yeah, same here
(09:17:52 AM) jast: I've taken to simply closing and not re-visiting news-y sites that are completely broken with JS
(09:19:20 AM) gac410: So do we change saveFile to save in binary for 2.0.2? Plugins in my local checkouts that use saveFile that might be broken:
(09:19:20 AM) gac410: AntiWikiSpamPlugin, SolrPlugin, TreePlugin, DirectedGraphPlugin
(09:19:33 AM) Lavr: My view on JS and Foswiki is that is is nice if you can VIEW without JS. But I would not expect to be able to edit anything including edit buttons from ERP without JS. I assume our issues are related to editing
(09:19:58 AM) gac410: Edit actually works as well if you disable strikeone, and remove the natedit skin
(09:20:22 AM) gac410: I tested it to validate our instructions about using foswiki without javascript.
(09:20:59 AM) MichaelDaum: yes, requiring JS to view is bad for SEO
(09:21:31 AM) gac410: If we change saveFile, then any plugin using it will have to encode to avoid wide character in print errors.
(09:21:56 AM) jast: if we don't change saveFile, any plugin using it to write binary data stays broken
(09:22:14 AM) CDot: gac410: you can't make omelettes without breaking legs....
(09:22:18 AM) gac410: :)
(09:22:26 AM) jast: just make sure you don't break your own legs and you'll be fine
(09:22:47 AM) CDot: we knew utf8 was a major upgrade and a potential issue for plugin authors, and we advertised this
(09:23:04 AM) jast: it had to be done
(09:23:08 AM) CDot: _1
(09:23:16 AM) CDot: +1 I mean
(09:23:28 AM) jast: _1+1=_2
(09:23:29 AM) gac410: okay. So remove the :encoding(utf-8) from saveFile, along with the documentation that it will be uft-8 encoded.
(09:23:32 AM) Lavr: I would change saveFile to how it was, and add a third parameter which enables UTF encoding defaulting to raw.
(09:23:53 AM) gac410: That would probably be helpful
(09:23:58 AM) jast: "how it was" makes sense only compared to 2.0, not compared to 1.1.x
(09:24:21 AM) jast: anyway, I'm all for the extra flag
(09:24:30 AM) Lavr: How it was in 1.1 so that plugins that count on saving raw still work. And 2.0 running ISO should also run
(09:25:12 AM) gac410: Lavr. nope. Even with ISO store, all internal data including topic text is utf-8 regardles of the store encoding.
(09:26:08 AM) gac410: {Site}{CharSet} is hardcoded to utf-8 that's what extensions will see for any foswiki API data. Encoding happens only in store.
(09:27:27 AM) gac410: the issue with the saveFile API is that it is advertised to save any random binary data into a workarea. not just topic text, which is always utf-8 encoded in 2.0.
(09:28:36 AM) gac410: anyway. ... anyone want to tackle the saveFile changes for 2.0.2?
(09:28:48 AM) Lavr: If we add the encoding parameter then we can soon publish some new versions of the popular plugins using it that will work both in 2.0 and 1.1. And those needing binary will also be happy
(09:30:17 AM) gac410: right I agree. so we add a parameter to the API. recommend to authors that they set it to {Store}{Encoding} when saving topic text, otherwise leave it unspecified for binary data.
(09:30:58 AM) MichaelDaum: +1
(09:31:07 AM) jast: so this API change is fine for a patch release? :}
(09:32:38 AM) Lavr: It is a "repair" of the consequences of the 2.0 UTF change. and we maintain compatibility with the API from 1.1
(09:32:39 AM) gac410: well, without it, 2.0 has a major catch-22. Other option is to just leave 2.0 broken
(09:33:06 AM) gac410: and wait for the API change control process to catch up. :(
(09:33:15 AM) jast: yeah, I agree. just wanted to make it 'official'
(09:34:20 AM) gac410: Okay, so the last 'blocker' for 2.0.2 is the NatEdit topic title field. I'm very willing to defer that one.
(09:35:04 AM) MichaelDaum: got a fix for that using a new TOPICTITLE_FIELD ... asked for feedback ... alas none so far
(09:35:26 AM) JulianLevens entered the room.
(09:35:57 AM) gac410: Ah... Task isn
(09:36:04 AM) MichaelDaum: I am fine to defer as well in case somebody comes up with some sensible 2 cent
(09:36:06 AM) gac410: isn't marked waiting for feedback :P
(09:36:36 AM) Lavr: You have a quick link for the TOPICTITLE_FIELD fix?
(09:36:54 AM) gac410: I don't see any issue with the proposal. http://foswiki.org/Tasks/Item13629
(09:37:16 AM) Lavr: http://foswiki.org/Tasks/Item13629
(09:37:26 AM) gac410: what I just said :D
(09:37:59 AM) MichaelDaum: TOPICTITLE_FIELD holds the name of a formfield that stores the TopicTitle and will be editable in the Title area above the natedit text area
(09:38:16 AM) MichaelDaum: if unset, no Title: input will be rendered
(09:38:24 AM) Lavr: I like that solution. I would use that several places
(09:38:28 AM) MichaelDaum: as is the default for 2.0.2 patternskin
(09:38:40 AM) MichaelDaum: here is one problem
(09:38:50 AM) MichaelDaum: just to make things more complicated :)
(09:39:25 AM) MichaelDaum: what if there are multiple DataForms all of which with a different need for a TOPICTITLE_FIELD, e.g. ProjectTitle, TaskTitle, FooBarTitle, ...
(09:39:45 AM) MichaelDaum: setting TOPICTITLE_FIELD in WebPreferences could only specify one.
(09:40:21 AM) Lavr: I would set it in the topic template used to create new topics with the specific form.
(09:40:30 AM) MichaelDaum: y
(09:40:32 AM) MichaelDaum: well
(09:40:55 AM) MichaelDaum: or standardize it on TopicTitle as planned for 2.1.0
(09:41:42 AM) MichaelDaum: the related feature proposal backs off to a TOPICTITLE _preference_ setting in case no TopicTitle _formfield_ exists
(09:42:04 AM) Lavr: I like that
(09:42:11 AM) MichaelDaum: which is kind of a different solution all together
(09:42:33 AM) gac410: Would it be possible to flag the "topic_title" formfield in the form definition, rather than a web-wide setting?
(09:42:54 AM) MichaelDaum: gac410, good idea
(09:43:01 AM) Lavr: Even better, yes
(09:43:22 AM) MichaelDaum: attribute t
(09:43:31 AM) MichaelDaum: argh
(09:43:57 AM) MichaelDaum: TopicInteractionPlugin already uses the "t" attribute to flag the topic "thumbnail"
(09:44:04 AM) gac410: :P
(09:44:26 AM) MichaelDaum: as does SolrPlugin while indexing it
(09:44:27 AM) gac410: S - Summary?
(09:44:37 AM) MichaelDaum: Summary != Title
(09:44:47 AM) MichaelDaum: a summary is more of a tag line
(09:45:40 AM) gac410: caption? headline?
(09:45:49 AM) gac410: http://www.thesaurus.com/browse/title
(09:45:56 AM) Lavr: L for titLe
(09:46:02 AM) Lavr: H is already used for hidden
(09:46:10 AM) MichaelDaum: e.g. Title="American Ultra" Summary="There's nothing more dangerous than a stoned cold killer"
(09:46:17 AM) Lavr: We have Mandatory and Hidden as standard
(09:46:30 AM) gac410: C - Caption?
(09:46:53 AM) MichaelDaum: nother problem with the DataForm attributre solution: standard Foswiki can't access it using a wiki app
(09:47:29 AM) MichaelDaum: you'd need FlexFormPlugin's %RENDERFORMDEF
(09:48:54 AM) gac410: And I'm going to reset us back to saveFile. If we allow a generic encoding field, then we need to deal with encoding errors where the unicode text can't be represented. I'm going suggest that we use a flag and specify unicode.
(09:49:33 AM) gac410: We are either saving topic text related data, which is always unicode on 2.0, or random binary data,
(09:49:54 AM) MichaelDaum: just to close Item13629: my vote -> defer
(09:50:19 AM) MichaelDaum: there is no consensus on it yet. though I have a working solition based on a TOPICTITLE_FIELD pref setting
(09:50:27 AM) gac410: +1 Defer is okay with me.
(09:51:02 AM) gac410: For now it's more an annoyance in the editor window, than a serious breakage.
(09:51:40 AM) Lavr: The field right now is only useful in a certain context. Can you hide it when that context is not there (no plugin available that uses it)
(09:52:19 AM) andreli: 'annoyance' is probably hash. We live perfect with it. Different Forms, Pattern Skin etc.
(09:52:48 AM) MichaelDaum: Lavr, not realy.
(09:52:48 AM) andreli: I would follow Lavr and just disable/hide it if not wanted.
(09:52:58 AM) Lavr: I know it will be a UI problem if I put it in production and it was not used for anything. I would hack the template and remove it
(09:53:06 AM) MichaelDaum: we could just shut it down unconditionally
(09:53:40 AM) Lavr: Michael I thought it was used with one of your plugins
(09:53:42 AM) gac410: Doesn't it currently remove the field from the form edit? eg. Task summary is relocated.
(09:53:46 AM) MichaelDaum: ... and enable it on F.O. again for QuestionForm and Tasks
(09:54:03 AM) MichaelDaum: gac410, custom edit template
(09:54:11 AM) gac410: ah. okay
(09:54:36 AM) Lavr: If it is only really used on f.o then I would remove it and add it again when the feature that uses it appear in 2.1
(09:55:41 AM) MichaelDaum: I'll take appropriate actions then
(09:56:19 AM) gac410: Approaching 1 hour. ... Can I also get feedback on saveFile. Unicode flag, vs. Encoding?
(09:56:30 AM) CDot: flag
(09:56:32 AM) MichaelDaum: securing the current TOPICTITLE_FIELD on a branch of its own....removing "topicmeta" from "firsttab" in edit.natedit.tmpl ... adding back "topicmeta" on F.O in two edit templates
(09:57:36 AM) gac410: okay. I'll address saveFile, Michael will fix the topic title. ... I'll build a 2.0.2 RC either late today or tomorrow.
(09:57:46 AM) Lavr: I think the saveFile can work fine with choice of raw or unicode. If people need something else they can just save directly with good old perl
(09:58:19 AM) MichaelDaum: sidenote: plugins based on WikiWorkbenchContrib (such as BlogPlugin, ClassificationPlugin and a few more) wont be affected by the removal of TOPICTITLE in edit.natedit.tmpl as TopicTitle is standard there already
(09:59:20 AM) gac410: And for next release meeting. Lets change our focus finally over to 2.1 feature review. ... As a minor release, only feature requests that are non-disruptive. Hopefully allowing for in-place upgrade from 2.0 to 2.1
(09:59:26 AM) gac410: Is that a reasonable criteria?
(09:59:47 AM) MichaelDaum: +1
(10:00:31 AM) gac410: If we go 2 weeks after 2.0.2 release with no new urgent tasks, let's take that as a sign to do the Branch so master can start on 2.1. BUT
(10:01:01 AM) gac410: keeping with branch/merge for features. Please only commit releasable work to master. Fair enough?
(10:01:50 AM) Lavr: Fair
(10:01:52 AM) CDot: gac410: BTW Tasks.Item13583 is nothing to do with the Cache; it's whatever it is that compiles the redirect login form that's getting it wrong
(10:02:25 AM) gac410: okay thanks for digging into that CDot
(10:02:52 AM) gac410: I downgraded it because the test case seemed to be somewhat contrived.
(10:03:16 AM) andreli: gac410: the next release meeting is just before http://foswiki.org/Community/FoswikiCamp2015Autumn. Might be good to do some ground work.
(10:04:57 AM) gac410: okay, so homework ... Please review and flag features you want to include in 2.1, with thought toward FoswikiCamp possibly working on some of them?
(10:06:16 AM) gac410: Any other comments / concerns before we close the meeting?
(10:06:19 AM) Lavr: I raised a minor docu update proposal that I hope I can just add to 2.0.2 http://foswiki.org/Development/DocumentAlreadySupportedFuncQueryOptions
(10:06:33 AM) Lavr: Documenting something that is already there
(10:06:33 AM) gac410: yeah that's fine by me.
(10:07:16 AM) gac410: Ah... I know. CDot ....
(10:07:17 AM) Lavr: I will add the two lines of plain text then.
(10:07:33 AM) gac410: The EditRowPlugin fix is not backwards compatible.
(10:07:47 AM) CDot: true
(10:08:00 AM) gac410: how do we deal with that one?
(10:08:11 AM) CDot: we don't
(10:08:16 AM) gac410: For 1.1.9, I assume you need to refresh the TablesContrib?
(10:08:26 AM) CDot: oh, yeah, true
(10:08:39 AM) CDot: well, maybe not. Maybe just leave it as it was.
(10:08:52 AM) CDot: freeze it, and move on
(10:09:14 AM) gac410: If I upload ERP after the 2.0.2 release, and anyone installs it on a 2.0 / 2.0.1 or 1.1.9 system, they are toast.
(10:09:46 AM) CDot: indeed. So we need to sort out compatibility, so that can't happen
(10:09:47 AM) gac410: Generally after each release, we upload all modified extensions
(10:10:04 AM) CDot: we discussed separate Extensions webs for each release
(10:10:24 AM) CDot: that might be the best way to go
(10:10:32 AM) gac410: well that was discussed many times in the past. 2.0 really needed it, but for each patch release?
(10:10:45 AM) CDot: sure. Linux does it, why shouldn't FW?
(10:10:54 AM) Lavr: For the 2.0.X it may not be a big deal since we can expect people to upgrade their core also. Just put a fat note.
(10:11:16 AM) gac410: That seems to be boiling the ocean cdot for one extension.
(10:11:38 AM) CDot: no, this is just the tipping point. this issue keeps coming up
(10:11:42 AM) gac410: I think for 1.1.9, updating TablesContrib. and as Lavr says, for 2.0.x a big fat note.
(10:11:51 AM) CDot: the ocean was already boiling, this is just one more dead fish
(10:12:31 AM) gac410: well there have been multiple proposals. I for one don't want to try to figure how to restructure Extensions, and certainly not as a knee-jerk to one extension.
(10:13:00 AM) CDot: sounds like one to solve at the autumn workshop (good luck with that one!)
(10:13:25 AM) gac410: JulianLevens: were you looking at the extensions web issues as well?
(10:13:45 AM) JulianLevens: y
(10:13:49 AM) CDot: restructuring extensions is not on the table. The idea would be: keep Extensions as it is, for 1.1.9 and earlier
(10:14:00 AM) CDot: and start afresh with Extensions_200
(10:14:15 AM) CDot: or even Extensions_202
(10:14:24 AM) JulianLevens: Hold those thoughts
(10:14:28 AM) gac410: CDot ... we had a compatibiltiy field in the Package form. that would have worked well to flag that ERP is not compatible. But someone changed it to checkboxes :P
(10:14:56 AM) CDot: gac410: the text field couldn't be processed :-(
(10:15:06 AM) CDot: I tried; there were too many abuses
(10:15:24 AM) CDot: anyhoo, that's an aside. Need a more robust solution.
(10:15:27 AM) gac410: Right, but existing extensions had meaningful messages that would display in the configure API. All those messages were LOST
(10:15:41 AM) CDot: :-( so shoot me
(10:15:45 AM) gac410: :)
(10:16:00 AM) CDot: *bang* damn, blood is so hard to get out from between the keys
(10:16:42 AM) Lavr: In old 1.1.9 in configure I see in the "Compatible with" column warnings in plain fat language to not install e.g. EditTablePlugin in 1.0. Did we remove that ability in 2.0?
(10:16:59 AM) CDot: ok, so, Tasks.Item13583 is an issue for *any* login redirect
(10:17:30 AM) gac410: Lavr: yes
(10:17:32 AM) gac410: :(
(10:17:34 AM) CDot: Lavr: apparently I was too abrupt in my attempts at improving automation
(10:17:41 AM) ***CDot has shot himself
(10:18:54 AM) gac410: Also, I think we more need a negative assertion. the vast majortiy of extensions are probably compatible. Its the ones that *don't* work that we need to flag. Checking checkboxes for 1.0.0 1.0.1 1.0.2 ... 1.1.0 ... 2.0.0 2.0.1 ... is madness IMHO
(10:20:34 AM) ***gac410 wonders if the Plugin API version is the thing to test. In theory, unless we bump the API plugins should always work.
(10:21:04 AM) CDot: well, I'll defend the checkboxes by saying it's the only way to block automatic installation of incompatible extension versions. But you still have the problem of, if you need extension A for 1.0.5, but that has become a "non-working" release, how do you refresh your 1.0.5 install?
(10:21:30 AM) CDot: you have to trawl back through the attachment versions to find the one that *was* compatible with 1.0.5
(10:21:52 AM) gac410: The problem as I see it, as as soon as we release 2.0.2, then EVERY extension without a 2.0.2 checkbox is now invalid until re-tested.
(10:21:53 AM) CDot: ..... if you can find out what version that was
(10:22:08 AM) CDot: isn't that the case, though?
(10:22:46 AM) CDot: it certainly is with the likes of a new ubuntu release
(10:22:55 AM) Lavr: Normally 99.9% of all plugins work when upgrading to minor releases. It makes sense to base compatibility on plugin API revision
(10:23:04 AM) gac410: practically? No. The RM is certainly NOT going to try to test 350+ exteions on every new patch release.
(10:23:14 AM) CDot: Lavr: yes, you have a good point there
(10:23:42 AM) CDot: on the assumption that the plugin API is incremented when something thath isn't directly plugin API related changes, anyway
(10:23:43 AM) gac410: And when 2.0.2 comes out, the extension list will now be *empty* until someone goes through and checks the checkbox for 350 extensinos.
(10:24:02 AM) CDot: for example, the interpretation of * Set DENYTOPIC would have to cause an increment
(10:24:39 AM) CDot: because a plugin *might* depend on it
(10:24:55 AM) gac410: The problem with the API is it was designed to detect extensions that need the *new* feature installed on an old release.
(10:25:22 AM) gac410: We need the reverse.
(10:25:23 AM) Lavr: There will also be plugins that depend on a version of another plugin. That we can only write ourselves from in plain language. Or invent a new Foswiki version of a deb or rpm system YUK!
(10:25:39 AM) CDot: the problem with the API is it's not a problem with the API. Bottom line, you *cannot* trust an extension until it's been tested :-(
(10:26:06 AM) CDot: however you can offer people the chance to use an untested extension, *with caveats*
(10:26:08 AM) gac410: And with 350 extensions and only a few active developers, the end result will be releases with NO supported extensinos.
(10:27:35 AM) CDot: there are two interlinked problems here (1) running a new version of an extension on an old FW release and (2) running an old extension on a new FW release
(10:27:46 AM) gac410: It's a trinary. Tested, Untested, BROKEN. It's the broken ones I am most worried about. install ERP on 1.1.9 will break your system.
(10:27:49 AM) Lavr: At least before we could write "Do not install this on releases earlier than 2.0.2". I think the human factor is important when we want to express compatibility.
(10:27:51 AM) CDot: they require slightly different approaches.
(10:28:17 AM) gac410: we need both fields, A "message" about compatibiilty and a machine processable.
(10:28:30 AM) CDot: You can still write that. Put it in the SHORTDESCRIPTION.
(10:28:35 AM) MichaelDaum: in web dev people tend to move away from (browser-) version testing towards feature testing
(10:29:00 AM) CDot: MichaelDaum: true. How does that help here?
(10:29:02 AM) gac410: No no no.... short description goes to the users. InstalledPlugins, etc.
(10:29:18 AM) gac410: We want a message for the admin,
(10:29:23 AM) gac410: about to install.
(10:29:24 AM) MichaelDaum: CDot, testing the plugins api is a catch all or nothing test
(10:29:46 AM) CDot: gac410: I don't have a problem with you reinstating a "long compatibility message"
(10:30:07 AM) CDot: the plugins API is not the problem. FW is a much bigger system than the API reflects
(10:30:18 AM) MichaelDaum: point is that features could either be impled by the core ... or by a plugin. such a convention would supersede the notion of a plugins api
(10:30:19 AM) CDot: for example, a format change in META could banjax a plugin
(10:30:25 AM) CDot: as could a JS change in the core
(10:30:27 AM) ***gac410 doesn't understand what was done to the Extensions web, and is not going to try to get it back. what we need is to find and recover all the existing compatibility messages.
(10:30:55 AM) CDot: gac410: they're all there in the history
(10:31:14 AM) gac410: :P Gac410 didn't break it.
(10:31:27 AM) Lavr: I still see many in 1.1.9 configure so I guess it is only plugins that were re-released that lost them.
(10:31:57 AM) gac410: The formfield definition changed. The FastReport just grabs the text.
(10:32:46 AM) CDot: there were only a handful of plugins that had compatibility messages. I'm sure it won't take long to recover them.
(10:33:07 AM) Lavr: If you change the formfield definition back to text then at least things stay as they are so we do not lose more
(10:33:34 AM) CDot: [off] gac410, how do we ssh to f.o these days?
(10:34:05 AM) gac410: It's on a different port. ... sending you a PM
(10:34:39 AM) gac410: decided on before we renamed 1.2 to 2.0
(10:35:04 AM) CDot: ta
(10:35:31 AM) gac410: Knocked 1000's of ssh attempts out of the logs. we were getting some infra messages too big for the listserver due to the volume of failed login attempts.
(10:35:42 AM) Lavr: Also note in the 2.0 configure - the old messages are displayed with html tags shown encodes and half snipped off
(10:36:38 AM) gac410: CDot What I'd like to do is change the Compatibility formfield back to text and add a new field for automation.
(10:37:13 AM) gac410: otherwise I don't know how to find all the messages and then update every extension with the new field.
(10:37:24 AM) CDot: Would much rather keep the Compatibility field as it is, and add a new field "Comptibility notes"
(10:37:43 AM) Lavr: That will not work in 1.1.9 - then they will not see the warnings
(10:37:52 AM) CDot: grrrr
(10:38:17 AM) Lavr: Life is a bitch
(10:38:38 AM) CDot: so the PackageForm was born on March 1st.
(10:39:00 AM) CDot: all I need it to remember how to recover an RCS revision at a given date...
(10:39:44 AM) gac410: CDot... I'm more concerned about the existing messages. No need to go back to recover the few that have been updated.
(10:39:47 AM) gac410: the data is there.
(10:39:58 AM) CDot: where?
(10:39:59 AM) gac410: It only gets lost when you update the extension.
(10:40:16 AM) CDot: OIC
(10:40:17 AM) gac410: The compatibiltiy field on existing extensions seems to contain the plain text.
(10:41:33 AM) CDot: the PackageForm defines [[Compatibility]] as checkbox | 5
(10:41:36 AM) Lavr: My ExpandTopicContentPlugin has a REVISIONATTIME macro where you give it a date and a topic and it returns the revision that was valid on that date
(10:42:00 AM) CDot: if you view the topic with the PackageForm modifies so that [[Compatibility]] is 'text'......
(10:42:36 AM) gac410: CDot, not sure if you've seen, but I removed that auto-fillin for license and copyright and author. Release process has been clobbering existing text.
(10:43:09 AM) CDot: gac410: whatever works
(10:43:33 AM) gac410: Typos / variations in the old | Author | value |, license and copyright, have been defaulting these, and removing legitimate copyright which is a huge no-no
(10:44:12 AM) ***CDot is intrigued by the idea of picking up different form definitions based on the type of data
(10:47:58 AM) CDot: gac410: happier with http://foswiki.org/Extensions/PackageForm?
(10:48:09 AM) gac410: CDot .. changing hats. For saveFile. Would you suggest binmode ':utf-8'; which just marks the data as utf-8, or binmode ':encoding(UTF-8)'; which checks for valid encoding.
(10:48:09 AM) gac410:
(10:48:32 AM) CDot: the latter
(10:49:26 AM) gac410: okay great thanks. So I'll make saveFile say. if ($unicode-flag ) binmode ':encoding(UTF-8)' else binmode
(10:49:38 AM) CDot: 15:47:59) CDot: gac410: happier with http://foswiki.org/Extensions/PackageForm?
(10:49:49 AM) gac410: Yes I think that will work better.
(10:50:11 AM) gac410: So incompatible by exception .... I think that will be much cleaner.
(10:51:12 AM) gac410: hm. for saveFile, do we need to set binmode when not flagged as $unicode? that would be a change from 1.1.x
(10:51:24 AM) CDot: only problem with that is it requires a change to the JS. A simple "CompatibleWith" field wouldn't.
(10:51:49 AM) gac410: Does configure check that field?
(10:51:52 AM) CDot: binmode is a nop on all the systems we work with.
(10:52:09 AM) gac410: really? windows cr/lf conversion?
(10:52:09 AM) CDot: configure talks to FastReport, and FastReport can map fields as it likes
(10:52:27 AM) ***CDot doesn't count Windows as a system he works with :-(
(10:52:40 AM) gac410: Don't forget JsonReport for UpdatePlugin
(10:53:00 AM) ***CDot has never touched UpdatePlugin
(10:53:25 AM) gac410: for whatever reason, it's now a default extension so we can't break it :(
(10:53:42 AM) gac410: A product of a FoswikICamp
(11:00:30 AM) andreli left the room (quit: Remote host closed the connection).
(11:02:20 AM) CDot: gac410: where is the "Compatibility" reported by the automation?
(11:10:34 AM) gac410: CDot: It used to be highlighted under the extension description
(11:10:48 AM) CDot: where?
(11:11:02 AM) CDot: in configure?
(11:11:06 AM) gac410: When you explore extensions in confiugre ... yes
(11:11:33 AM) gac410: And as lavr reports, on 2.0 it chokes on it a bit.
(11:11:36 AM) CDot: I knew there was a reason I had to get rid. Bugger, more deep delving in configure.
(11:12:30 AM) gac410: It was not used a lot, but when it was, it was pretty critical. DO NOT install blah unless you want to restore from a backup. ...
(11:25:05 AM) CDot: is there a Task? I can't do anything more on it right now (and I haven't finished 13583 either :-( )
(11:25:36 AM) gac410: No. we've just all been living with it and grumbling :D
(11:25:41 AM) gac410: I'll open one if you want.
(11:26:19 AM) gac410: Are these blockers for 2.0.2? (13583 + PackageForm?)
(11:26:52 AM) gac410: I've got the Func::saveFile / readFile changes ready including a unit test that now saves/reads binary, plus another that does the unicode test.
(11:28:20 AM) CDot: I'd say 13583 is a blocker, while it may not affect not-logged-in form it's definitely wrong
(11:28:52 AM) ***CDot hasn't run all the way through the not-logged-in process to check (got diverted onto configure)
(11:28:57 AM) gac410: Item13681
(11:29:18 AM) gac410: Item13681: Extension PackageForm has lost the compatibility notes.
(11:30:00 AM) gac410: the only not-logged-in case I could easily recreate was the upload, and as someone pointed out, because the Session id changes across login now, it was a bogus test.
(11:30:13 AM) CDot: <form action='/g%E3%81%83t/core/bin/login/ŽuŽu/ŽuŽu' name='loginform' method='post' ......
(11:30:17 AM) gac410: Login on 2.0 always creates a new session and deletes the old session.
(11:30:57 AM) gac410: re blockers okay I'll hold off 2.0.2 a bit longer.
(11:31:37 AM) CDot: the login form works ok because the target page is encoded correctly in the foswiki_origin
(11:31:54 AM) CDot: it effectively ignores the 'action' in the form
(11:31:57 AM) gac410: ah...
(11:32:25 AM) CDot: hmmm, so why does it fail during the upload..... will have to research this further.
(11:33:31 AM) gac410: It only fails if you lose your session during the upload. It's somewhat contrived.
(11:33:58 AM) gac410: normally you can't get to the upload page to issue the POST unless you are already logged in.
(11:36:18 AM) gac410: Release meetinfg for 7 Sept 2015 is hereby closed :)
(11:38:01 AM) CDot: losing the session should follow the same code path as not being logged in to start with
(11:38:18 AM) CDot: I can'd find any difference
(11:38:25 AM) ***CDot will have to come back to this
(11:38:42 AM) CDot left the room (quit: Remote host closed the connection).
(11:42:20 AM) Lavr: Thanks for today. I have checked in the small API docu update.