Release Meeting: 20 April 2015

   (08:46:46 AM) Lynnwood  entered the room.
   (09:01:37 AM) gac410: Hi everone. Agenda: http://foswiki.org/Development/ReleaseMeeting01x02_20150420
   (09:01:50 AM) CDot  entered the room.
   (09:02:36 AM) JulianLevens  entered the room.
   (09:03:01 AM) MichaelDaum: welcome on board
   (09:03:26 AM) gac410: yes good day everyone Or is that good night for mtempest ?
   (09:03:53 AM) CDot: gac410: mtempest is in RSA (unless heʼs moved)
   (09:04:00 AM) mtempest: 3om
   (09:04:05 AM) CDot: so roughly a European TZ
   (09:04:17 AM) CDot: mtempest: so where are you now?
   (09:04:17 AM) mtempest: Er, 3pm here in South Africa
   (09:04:21 AM) gac410: Ah... okay so good day everyone :)
   (09:04:32 AM) CDot: ah, I thought so - 3am had me guessing ;-)
   (09:04:58 AM) CDot: gʼday George
   (09:05:19 AM) ***mtempest waves
   (09:05:29 AM) gac410: I was hoping we were getting close to Beta 2 but the recent testing mainly by jomo has opened up a can of worms. :(
   (09:05:55 AM) jast: first things first... translations?
   (09:05:56 AM) gac410: But first on the agenda ... Translators. Any suggestions on getting help for the languages that are being left behind?
   (09:06:53 AM) CDot: gac410: which languages are most pressing?
   (09:07:14 AM) gac410: Spanish is one that was 100%
   (09:07:31 AM) gac410: r Czech, Danish, French, German and Italian are in great shape.
   (09:08:08 AM) ***CDot knows several Spanish speakers, but none who would be able to translate :-(
   (09:08:46 AM) gac410: If you look at http://translate.foswiki.org/projects/foswiki/ release 1.1 had a number of languages at 100%, that are in the 40-60% on master
   (09:10:09 AM) gac410: Korean, Norwegian, Polish, Portuguese (brazil) Russian, Spanish, Swedish, Traditional Chinese .... were all in the high- 80% to 100% range on 1.1, and are not making much headway on 1.2
   (09:12:47 AM) gac410: We can do another plea to foswiki-announce & foswiki-discuss ... I've tried once or twice. Anyone else want to take a stab at it?
   (09:13:29 AM) ***CDot thinks there probably isnʼt much point
   (09:14:08 AM) CDot: we depend on the languages spoken by the people who are engaged at the time
   (09:14:25 AM) CDot: trying to engage someone new just for translations..... I doubt it
   (09:15:17 AM) gac410: So we can drop the languages from the MANIFEST or just release them in incomplete status. Someone suggested releasing a LanguagesContrib Was that you CDot?
   (09:18:07 AM) CDot: y
   (09:18:37 AM) CDot: the issue with that is not being able to strongly like versions of contribs with releases of FW
   (09:18:43 AM) CDot: ^like^link
   (09:19:13 AM) CDot: as in "you need version 6 of GermanContrib for version 1.3.0 of Foswiki"
   (09:19:32 AM) CDot: "but version 2 for 1.1.9" (etc)
   (09:20:06 AM) gac410: Right. I think this is one to sidestep for now :) Especially if we try to release more often with a continuous development stream
   (09:20:33 AM) CDot: for now, yes, but with continuous integration we need something like that.
   (09:20:51 AM) mtempest: Have a separate contrib for each foswiki version?
   (09:21:07 AM) CDot: mtempest: yuck
   (09:21:41 AM) CDot: perhaps a git branch for each FW version.....
   (09:21:42 AM) gac410: We just are not structured to have tight coupling in Extensions. There have been proposals in the past to fix it, but it is *major* surgery I suspect.
   (09:22:21 AM) JulianLevens: I have started looking into this sort of thing and CI but itʼs really early days
   (09:22:40 AM) gac410: If we "always release from master" and branch for features, and merge into master for release, I don't think we need to worry as much about the languages.
   (09:22:59 AM) gac410: Keep the tip of Master in a "ready to release" state.
   (09:24:10 AM) JulianLevens: That suggest that a CI would look for Tasks ʼWaiting for Releaseʼ and automatically merge into a daily_build branch well er daily
   (09:24:29 AM) JulianLevens: Run the tests and report problems
   (09:24:47 AM) JulianLevens: If all tests pass then merge them to master?
   (09:25:24 AM) ***gac410 doesnʼt know if we are big enough to try to tackle full automation of merging.
   (09:25:40 AM) gac410: I think it would be better to make manual decisions on what merges into master.
   (09:26:03 AM) JulianLevens: Neither am I, but Iʼd like to see how far I can get
   (09:26:11 AM) gac410: :)
   (09:26:56 AM) gac410: I think we need a separate meeting / proposal on how we will move forward with git branch/merge strategy. ... lets get 1.2 out first :)
   (09:27:22 AM) gac410: Well let's move on from translations.
   (09:28:01 AM) gac410: Release blockers. First the big one Item13331 ... big issues in Forms with certain codepoints.
   (09:28:39 AM) jast: is this still an issue with CGI 4.15?
   (09:28:43 AM) jast: (the bug report mentions 4.14)
   (09:28:53 AM) jast: there have been changes to how entities are processed
   (09:29:01 AM) gac410: It seems to be a CGI bug. Old versions of CGI work fine if the Language is set. Hm. I didnt' know about 4.15 must have just come out.
   (09:29:11 AM) jast: released today
   (09:30:03 AM) jast: it seems like it now only encodes these: <>&"&#700;
   (09:30:08 AM) jast: and two extra special ones
   (09:30:26 AM) jast: plus you can now configure the entity processing using a global variable in CGI
   (09:31:13 AM) CDot: gotta hate CGI :-(
   (09:31:31 AM) CDot: it has always been a thorn in our sides.
   (09:32:16 AM) MichaelDaum: any html rendering is going to be removed from CGI-5
   (09:32:34 AM) MichaelDaum: so Foswiki::Render::HTML is the RTTD
   (09:32:35 AM) gac410: If someone can test CGI 4.15 on master, There are testcases attached to http://foswiki.org/Tasks/Item13331
   (09:33:16 AM) MichaelDaum: interestingly 4.14 is missing from http://cpansearch.perl.org/src/LEEJO/CGI-4.15/Changes
   (09:34:21 AM) MichaelDaum: CGI::Textareas are still broken on for us using a DataForm field textarea containing Nech&#357; již h&#345;íšné saxofony &#271;ábl&#367; rozezvu&#269;í sí&#328; úd&#283;snými tóny waltzu, tanga a quickstepu.
   (09:34:39 AM) gac410: On Item13331 or on master?
   (09:34:59 AM) MichaelDaum: master
   (09:35:12 AM) gac410: CGI version?
   (09:35:13 AM) MichaelDaum: google translate says: Now let sinful saxophones devils chime hall appalling tones waltz, tango and quickstep.
   (09:35:16 AM) MichaelDaum: 4.15
   (09:35:23 AM) MichaelDaum: just cpamn&#700;ed it out of the net
   (09:36:19 AM) MichaelDaum: it shows "Nech&#357; již h&#345;íšné saxofony &#271;ábl&#367; rozezvu&#269;í sí&#328; úd&#65533;›snými tóny waltzu, tanga a quickstepu." in edit
   (09:36:38 AM) MichaelDaum: &#3848; &#3921;&#3904;&#3938;&#3851;&#3928;&#3931;&#3962;&#3942;&#3851;&#3944;&#3851;&#3937;&#3954;&#3906;&#3851;&#3939;&#3942;&#3851;&#3936;&#3905;&#4018;&#3956;&#3908;&#3942;&#3851;&#3937;&#3962;&#3851;&#3940;&#3962;&#3942;&#3851;&#3906;&#3919;&#3962;&#3938;&#3853; &#3853;&#3925;&#3942;&#3851;&#3938;&#3986;&#3964;&#3939;&#3851;&#3933;&#3851;&#3942;&#3984;&#4017;&#3962;&#3942;&#3851;&#3935;&#3954;&#3939;&#3851;&#3906;&#3923;&#3964;&#3923;&#3851;&#3906;&#3921;&#3964;&#3908;&#3851;&#3939;&#3988;&#3851;&#3926;&#3934;&#3954;&#3923;&#3853; &#3853;&#3910;&#3906;&#3942;&#3851;&#3920;&#3964;&#3906;&#3942;&#3851;&#3904;&#3956;&#3923;&#3851;&#3926;&#4018;&#3939;&#3851;&#3928;&#3930;&#3956;&#3908;&#3942;&#3851;&#3928;&#3962;&#3921;&#3851;&#3936;&#3911;&#3928;&#3851;&#3926;&#4017;&#3908;&#3942;&#3851;&#3928;&#3920;&#3956;&#3942;&#3853; &#3853;&#3928;&#3851;&#3943;&#3953;&#3851;&#3928;&#3905;&#3942;&#3851;&#3924;&#3936;&#3954;&#3851;&#3906;&#3929;&#3964;&#3851;&#3926;&#3964;&#3851;
   (09:36:40 AM) MichaelDaum: &#3913;&#3954;&#3921;&#3851;&#3906;&#4017;&#3956;&#3938;&#3851;&#3909;&#3954;&#3906;&#3853; is even worse
   (09:36:40 AM) gac410: yup That's what happens with Czech e-Caron
   (09:38:23 AM) MichaelDaum: maybe that&#700;s these two extra codepoints that CGI still tries to translate calling HTML::Entities
   (09:39:03 AM) MichaelDaum: we could try to provide a custom CGI::ENCODE_ENTITIES
   (09:39:16 AM) MichaelDaum: defaults to &<>"\x8b\x9b&#700;
   (09:40:50 AM) gac410: Michael, if you and jast could work on master, and try to get this all working with CGI, I'll create a feature proposal to cover Item13331 and will try to work on that branch in parallel.
   (09:41:24 AM) gac410: We need to decide what to do with the rest of the blockers, mainly Wysiwyg now :(
   (09:41:50 AM) gac410: And can make a later decision on whether to accept 13331 into master, or defer it to a post 1.2 release.
   (09:42:24 AM) gac410: I think configure is now in great shape. CDot has done a masterful job :D
   (09:42:50 AM) CDot: I have been looking at the MAKETEXT report you came up with, and at this point in time I&#700;m not sure it&#700;s fixable
   (09:43:01 AM) CDot: at least not without hacking TMCE
   (09:43:48 AM) gac410: There is one lurking bug, in javascript. with extension installer, *sometimes* the args={} hash is empty after selecting one or more extensions to install. But works on second attempt.
   (09:44:11 AM) gac410: CDot: it fails in the ROUNDTRIP Wysiwyg test, is TinyMCE even in the loop?
   (09:44:12 AM) CDot: don&#700;t give me "sometimes". I don&#700;t do "sometimes" :-(
   (09:44:42 AM) CDot: gac410: the ROUNDTRIP test is flawed; I can get that test to pass, but when you put TMCE in the loop, fur flies.
   (09:45:21 AM) CDot: I will keep working on it, but can&#700;t promise a fix.
   (09:46:09 AM) gac410: ah foo. That sucks. I guess best bet for 1.2 is to <sticky> them then. Which I already did.
   (09:46:09 AM) gac410: re "sometimes" ... yeah I know cdot, If you use the Search, select one or two extensions, and click report, or install, on occasion you get just a dialog with the word "Validate" ... nothing else.
   (09:46:36 AM) CDot: when you have details of how to reproduce it, shout.
   (09:46:38 AM) gac410: I traced the POST, and when that happens, the args={} hash is empty, as if nothing was checked. Repeat, and it works.
   (09:46:43 AM) MichaelDaum: $CGI::ENCODE_ENTITIES = q{&<>"&#700;}; fixes it
   (09:47:46 AM) gac410: Ah. great. So lets make that the solution for 1.2! (And you may need to force CGI Charset to utf-8, I found it using iso-8859-1 even when utf-8 configured for foswiki.
   (09:47:57 AM) gac410: That fixes older CGIs setting the right charset
   (09:48:18 AM) gac410: Those details are in the 13331 task
   (09:49:28 AM) ***MichaelDaum not sure where to put $CGI::ENCODE_ENTITIES = q{&<>"&#700;}; strategically
   (09:49:46 AM) MichaelDaum: I&#700;ve added the patch for Foswiki::Form::Textarea to http://foswiki.org/Tasks/Item13331
   (09:49:59 AM) MichaelDaum: I&#700;ll forward our findings to the CGI maintainer
   (09:50:29 AM) jast: in CGI 4.15 the CGI charset is no longer used for HTML escaping
   (09:50:54 AM) gac410: Right, but most sites are running older versions. 3.65, for eg.
   (09:50:59 AM) jast: and even in 3.x it affects only special cases
   (09:51:50 AM) jast: in 3.x we should be safe if we set it to empty string
   (09:52:10 AM) jast: the only values that make a difference for HTML escaping are: ISO-8859-1 and WINDOWS-1252
   (09:52:25 AM) jast: (yes, that makes little sense, but it&#700;s what the code does)
   (09:52:27 AM) gac410: The current state is that I'm getting lost. We have a lot of TranslationTests failing now. I don't think the patches attached to Item13372 are safe for general use.
   (09:52:49 AM) MichaelDaum: https://github.com/leejo/CGI.pm/issues/157
   (09:53:44 AM) jast: anyone else get the impression that the maintainer of CGI.pm changed recently? :}
   (09:54:47 AM) MichaelDaum: no need for impressions. yes Lee took over after CGI being unmaintained for some time.
   (09:55:03 AM) MichaelDaum: he held a talk about CGI&#700;s future direction
   (09:55:19 AM) jast: he&#700;s probably learning a thing or two about the joys of being a maintainer of CGI :}
   (09:55:26 AM) gac410: The things we are struggling with are mostly stuff that is deprecated and will be eliminated.
   (09:55:47 AM) MichaelDaum: Lee is a sharp & nice guy
   (09:56:02 AM) gac410: Okay. Back to blockers and then Beta 2
   (09:56:27 AM) gac410: 13331, 13369, 13371 and 13372 are all Wysiwyg and/or CGI entity related.
   (09:56:30 AM) jast: so, we have an interim solution for 13331?
   (09:57:00 AM) MichaelDaum: jast, see the patch there. it needs to move though to a better place, maybe.
   (09:57:05 AM) gac410: 13331, yes. Set charset in older CGI, and override ENCODE_ENTITIES in newer
   (09:58:19 AM) MichaelDaum: gac410, your work isn&#700;t lost. please keep the branch.
   (09:58:43 AM) MichaelDaum: we will have to follow up on Foswiki-2
   (09:59:07 AM) gac410: Yes I will. I might rename it .. but definitely not discarding it. I'll open a feature request to match for a future release.
   (09:59:17 AM) MichaelDaum: xcellent
   (09:59:45 AM) MichaelDaum: given low-fi approach cures 13331
   (10:00:05 AM) gac410: Yes. We need to get this all into Beta 2, and get jomo and others to beat on it.
   (10:01:44 AM) gac410: So hurdles for Beta 2. Get the TranslatorTests passing and the 13331 fix in. All inter-related with encoding issues.
   (10:03:48 AM) gac410: CDot ... The 13369, 13371 and 13372? For at least MAKETEXT I think it's fine to declare that we use <sticky> to protect. But Item13372 is worrying.
   (10:05:16 AM) gac410: And 13371 as well :(
   (10:05:27 AM) CDot: They are all aspects of the same problem.
   (10:05:37 AM) gac410: Okay ... well that's good I guess :)
   (10:05:49 AM) CDot: no, because it&#700;s a very hard problem to solve
   (10:06:02 AM) MichaelDaum: said Turing
   (10:06:29 AM) CDot: "NP", said Turing, "It&#700;ll only take me 10^28 years to solve that"
   (10:06:42 AM) MichaelDaum: NM
   (10:07:32 AM) jast: some day someone&#700;s going to prove that P = NP
   (10:07:33 AM) CDot: anyway, if anyone wants an explanation of the problem, see me after class :-)
   (10:07:44 AM) MichaelDaum: "divide an conquer" is now "ignore and forget"
   (10:07:46 AM) jast: ... introducing a constant factor of 10^(10^100)
   (10:08:59 AM) MichaelDaum: if fixing WysiwygPlugin is NP-complete then "ignore and forget" is the right solution for Foswiki-1.2.0
   (10:09:42 AM) MichaelDaum: because infinity is very long, especially the last part
   (10:09:43 AM) CDot: no, it&#700;s not that sort of problem. The problem is that neither WysiwygPlugin, nor TMCE, are lossless
   (10:09:59 AM) jast: I think I know about 70% of the problem, and that&#700;s enough for me to not know how to solve it
   (10:10:15 AM) CDot: both lose information, and there&#700;s a delicate tradeoff about how much of a mess you make of the HTML that TMCE edits (to protect it from TMCE)
   (10:10:24 AM) CDot: and the editabilty of the HTML
   (10:11:07 AM) gac410: If we can at least *detect* that the HTML will not be reliably editable, we could just disable wysiwyg ... we do that for some other stuff I think.
   (10:11:16 AM) gac410: That would be okay for 1.2 IMHO.
   (10:11:27 AM) CDot: IIRC there is already a switch to do that
   (10:11:38 AM) gac410: Right, but can we automate this case?
   (10:11:39 AM) jast: if we can do that, I agree it&#700;s enough
   (10:11:49 AM) CDot: it turns off WYSIWYG if the test contains macros
   (10:11:58 AM) CDot: text
   (10:12:12 AM) gac410: Detect that the topic contains text that will not edit cleanly?
   (10:12:24 AM) CDot: yes, that what it does
   (10:13:29 AM) jast: if it contains *any* macros?
   (10:13:50 AM) CDot: can&#700;t remember the details. It&#700;s doccoed in the WysiwygPlugin topic.
   (10:14:06 AM) jast: right
   (10:15:39 AM) gac410: Anyway, CDot, your best judgement, if we can somehow prevent Wysiwyg from corrupting utf8, even if it means disable Wysiwyg if text contains certain entities, that's fine for 1.2
   (10:16:52 AM) gac410: 1.2 was not intended to be our "unicode release" The feature crept in once taint was disabled.
   (10:17:06 AM) CDot: it&#700;s not "corrupting UTF8". That particular problem was solved several days ago. What it&#700;s doing is being overenthusiastic to convert entities to codepoints
   (10:17:13 AM) CDot: and that&#700;s breaking macros.
   (10:17:27 AM) jast: so, add a check that disables WYSIWYG if problematic entities are in the text
   (10:17:35 AM) CDot: it works with iso-8859-1 because it *has* no codepoints outside of ascii (well, not many)
   (10:17:55 AM) gac410: okay.
   (10:18:00 AM) jast: IMO topics shouldn&#700;t be using entities in most cases anyway
   (10:18:19 AM) CDot: yes, you could add such a check, as a band-aid. As I said, I can&#700;t guarantee a fix.
   (10:18:43 AM) gac410: I was a little concerned that Wysiwyg is converting &quot to the numeric equivalent ... that will be confusing to users. But that's a different issue.
   (10:18:48 AM) jast: well, as long as we have something that can get the release out, the blocker is manageable, that&#700;s the main thing now
   (10:19:04 AM) gac410: It doesn't round trip any of the named entities any more ... I don't think.
   (10:19:28 AM) CDot: if you are using UTF8, there are codepoints for all the named entities
   (10:20:36 AM) CDot: anyway, I have a small testcase, but as I said, I can&#700;t guarantee a fix. Not because it isn&#700;t fixable - it is, I&#700;m sure - but because it&#700;s complicated and risky.
   (10:20:42 AM) gac410: Right. So a user editing a topic with &quot saves and then next time they edit (in plain text) they see &#xx; wtf? But again, it sounds like this is something we have to live with with utf8
   (10:20:50 AM) CDot: thank goodness we have a large test set for WYSIWYg.
   (10:21:11 AM) gac410: Where it impacted us was mainly ME ... I was wysiwyging release topics, and converted all the entities to codepoints :(
   (10:21:48 AM) CDot: gac410: please leave that one; it&#700;s really icing on the cake
   (10:22:06 AM) gac410: leave it?
   (10:22:11 AM) CDot: it&#700;s much more important to solve the conversion of entities (named or otherwise) to codepoints
   (10:22:27 AM) gac410: Right. I won't make that a blocker ... if that's what you meant.
   (10:22:28 AM) CDot: which is a completely different problem
   (10:23:03 AM) CDot: BTW, whether it uses named or numbered entities is up to HTML::Entities, so if you want, you can find a way to "explain" your concerns to it.
   (10:23:03 AM) gac410: I should probably open it as a low or normal, just to get it documented, but definitely not for 1.2
   (10:24:14 AM) gac410: So to make sure I understand. If using a site character set that has codepoints for named entities, Wysiwyg will convert the named entity to the equivalent codepoint.
   (10:25:23 AM) gac410: Okay .. .back to release blockers. Anything else? Any new tasks we should escalate?
   (10:26:25 AM) gac410: Lynnwood has a new draft InstallationGuide. http://foswiki.org/Sandbox/InstallationGuide01x02Rewrite if anyone else wants to review?
   (10:26:36 AM) CDot: IIRC TMCE converts *everything* to numbered entities, which is where the problem starts.
   (10:26:36 AM) mtempest: Is that not configurable?
   (10:26:36 AM) CDot: mtempest: possibly; I&#700;ve been avoiding the TMCE JS like the plague
   (10:26:36 AM) mtempest: :-)
   (10:26:36 AM) ***CDot has his hands full with WysiwygPlugin
   (10:26:36 AM) CDot: there&#700;s a new version of TMCE queued, which changes all sorts of APIs, which is one good reason not to invest time on it.
   (10:26:36 AM) gac410 left the room (quit: Ping timeout: 240 seconds).
   (10:26:36 AM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.
   (10:27:48 AM) gac410: Oops. my connection dropped.
   (10:28:14 AM) gac410: Last thing I saw: CDot: there's a new version of TMCE queued, which changes all sorts of APIs, ...
   (10:28:28 AM) CDot: gac410: you didn&#700;t miss anything
   (10:28:33 AM) gac410: okay thanks.
   (10:30:04 AM) gac410: Okay, so Beta 2 ... I'll plan to build it as soon as CDot is comfortable with the Wysiwyg fixes. And jast / jomo / MichaelDaum verify the CGI 4.15 fixes.
   (10:30:55 AM) MichaelDaum: verified and checked in. need somebody to x-check
   (10:31:14 AM) gac410: I'll open tasks on entity -> codepoint conversion as a low priority, and Configure extension installer wizard, as intermittent ... needs documentation and a js expert to figure out why configure.js is occasionally not setting the args hash.
   (10:31:29 AM) gac410: Neither of which will block Beta 2.
   (10:33:29 AM) gac410: Do we know of anyone other than jomo that is really testing the Beta ?
   (10:33:56 AM) gac410: (outside of the core dev's that is :) )
   (10:34:11 AM) Lynnwood: i&#700;ve been doing some testing on it.
   (10:34:34 AM) Lynnwood: got a bit distracted in trying to install plugin which i found out was broken.
   (10:34:38 AM) gac410: Ah yes sorry Lynnwood ... I should have remembered that.
   (10:34:45 AM) Lynnwood: i&#700;ll go back and go through some more basic testing.
   (10:34:56 AM) Lynnwood: no worries
   (10:35:56 AM) Lynnwood: after i found plugin install was broken, i went to see about getting a newer copy from git and discovered that was more involved than first thought.
   (10:36:20 AM) gac410: And one more issue. in yesterday's irc log, user "foswiki_irc8" could not get attach to work. Kept getting unable to write the CGI temp file.
   (10:36:24 AM) Lynnwood: so i&#700;m going to go back and do fresh install of the beta and resume basic testing.
   (10:37:07 AM) gac410: Looking back through the logs, only one other user - 4 years ago - had the same issue. I had him patch in the 1.2.0 fixes to override temp file locations, but still he was unable to get upload to work.
   (10:37:14 AM) gac410: Lynnwood: okay great. Thanks.
   (10:38:52 AM) gac410: Even went as far as to set the various TMP env. variables in setlib.cfg and it still failed with permission denied. I have no idea and user was going to ask his hosting provider, and then planned to move to a different wiki software :(
   (10:40:05 AM) gac410: Anyway, I think we are in pretty good shape for Beta 2.
   (10:40:34 AM) MichaelDaum: in the meantime Lee reopened https://github.com/leejo/CGI.pm/issues/157
   (10:40:39 AM) CDot: oh, crap. i just realised I have already fixed 13369
   (10:40:50 AM) gac410: Any further business. If not Thanks everybody for all the hard work!
   (10:41:02 AM) MichaelDaum: thanks to you gac410.
   (10:41:11 AM) CDot: yes, thanks George
   (10:41:43 AM) Lynnwood: big thanks to you gac410 !
   (10:41:45 AM) ***gac410 is good at shoveling work on CDot and MichaelDaum and others. :D
   (10:41:53 AM) jast: yes, major thanks for filling the unenviable role of making hard calls and running after everyone :)
   (10:42:41 AM) gac410: We'll get this code out eventually. Then we can reset, and figure out our branching / build / release strategy going forward ... and start to prioritize work for the next great release !
   (10:43:24 AM) gac410: After playing with the item branch ... I really think a branch/merge strategy is going to make this all much easier to keep a clean master "ready to release"
   (10:43:33 AM) jast: absolutely
   (10:43:37 AM) JulianLevens: y
   (10:44:27 AM) gac410: Oh... one question. We are releasing FCGI and ModPerl with 1.2. but I never restructured the repositories into distro. I think I still should do that. ?
   (10:48:41 AM) MichaelDaum: y
   (10:49:59 AM) CDot: BTW i keep getting "mod perl not installed" errors from the installer. is that expected>
   (10:50:42 AM) gac410: yes. Since we bundle the extension, it should be an "optional" dependency, only needed if you intend to use it.
   (10:50:46 AM) CDot: maybe they are warnings. perl pseudo-install.pl developer
   (10:51:11 AM) gac410: Ah yeah pseudo-install doesn't do a very good job of dependency management. Everything is an error.
   (10:51:17 AM) CDot: it&#700;s a bit dosconcerting, it has to be said.
   (10:51:30 AM) CDot: disco-certing
   (10:51:46 AM) gac410: Well when I run it I get an error for pretty much every dependency
   (10:52:33 AM) gac410: MichaelDaum: leejo seems to imply with his last message that it's a windows issue???
   (10:54:21 AM) MichaelDaum: he doesnt seem to be 100% sure. promised to find some ol&#700; windows vm for testing as well as remove those hex codes from ENCODE_SHMATITIES in the next release of CGI
   (10:55:53 AM) gac410: MichaelDaum: regarding the ENCODE_ENTITIES ... I think that maybe it, plus setting of the CGI::CHARSET for older CGI should be done in Foswiki.pm, maybe around line 2044, and move $Foswiki::cfg{Site}{CharSet} ||= 'iso-8859-1'; to the same place.
   (10:56:03 AM) gac410: Set them just before creating the new response object.
   (10:56:38 AM) MichaelDaum: whatever fixes the beast
   (10:57:06 AM) MichaelDaum: I&#700;ve put ENCODE_ENTITIES into Foswiki.pm as it seems to be the very first code to "use CGI"
   (10:58:14 AM) gac410: Trying to figure out where to place stuff is painful. Ah... I don't know why, but I thought it was in Configure::Load. I see that now.
   (11:01:48 AM) mtempest: Cdot, I&#700;m now working at Airbus Defence and Space Optronics South Africa.
   (11:02:46 AM) CDot: mtempest: if it wasn&#700;t for the "defence" bit of that, I&#700;d say "sounds a lot safer" ;-)
   (11:03:11 AM) CDot: "Space Optronics" sounds like fun
   (11:03:21 AM) gac410: MichaelDaum: I'll move the CharSet handling around just a bit in Fosiwki.pm and add a call to CGI::charset($Foswiki::cfg{Site}{CharSet}); which should fix older versions of CGI
   (11:03:47 AM) MichaelDaum: yay
   (11:04:08 AM) mtempest: Cdot it has its moments :-)
   (11:04:44 AM) mtempest: But I don&#700;t do space stuff
   (11:05:33 AM) gac410: And will also add $CGI::TMPDIRECTORY = $Foswiki::cfg{TempfileDir}; to the temp file setup... not that it seemed to fix foswiki_irc8's upload issues.
   (11:16:17 AM) gac410: mtempest: Sounds like interesting work.
   (11:17:12 AM) gac410: Okay MichaelDaum jast, ... I've tested jomo's form issues with cgi 3.65, and it seems to be clean.
   (11:17:45 AM) mtempest: gac410 :-)
   (11:20:22 AM) MichaelDaum: yes it is fine now
   (11:21:12 AM) gac410: phew... So I need to update the checker. Do we need to flag any CGI 4.11 -> 4.14?
   (11:31:00 AM) MichaelDaum: 4.14 is okay. frankly I don&#700;t know what the diff between 4.14 and 4.15 is. the change logs even dont mention 4.14. so I assume it is a minor glitch.
   (11:38:17 AM) mtempest left the room (quit: Quit: Bye).
   (11:38:37 AM) jast: 4.11 through 4.13 are bad and unfixable
   (11:38:54 AM) gac410: MichaelDaum: reviewing the changes it seems cosmetic 4.14 to 4.15 https://github.com/leejo/CGI.pm/commits/v4.15
   (11:39:07 AM) JulianLevens left the room.
   (11:39:42 AM) MichaelDaum: okay
   (11:39:44 AM) MichaelDaum: jast, yes.
   (11:40:55 AM) jast: 4.11 was released in December, so there&#700;s a decent chance people are actually affected by one of these versions