ReleaseMeeting01x02_20140707

(09:02:40 AM) gac410: Hi all, should we get started or give everyone a few more minutes
(09:06:37 AM) gac410: 1305 Lets get started. Agenda is here: http://foswiki.org/Development/ReleaseMeeting01x02_20140707
(09:06:55 AM) MichaelDaum: Hi George. Hey everybody.
(09:07:18 AM) ModAcOst: Hello everyone
(09:07:48 AM) CDot: hadnʼt noticed the time; sorry
(09:10:19 AM) CDot: yoo-hoo?
(09:10:32 AM) gac410: hi all...
(09:10:37 AM) MichaelDaum: gac410, letʼs get started.
(09:10:41 AM) CDot: aha!
(09:11:09 AM) CDot: good morning/afternoon/evening (delete as applicable)
(09:11:17 AM) gac410: Okay. I added a bunch of tasks to the minutes topic to serve as an agenda. Lots of "waiting for feedback" tasks that had checkins.
(09:11:35 AM) CDot: we went through a load at the last RM
(09:12:36 AM) gac410: yes I saw that .. thanks. Those were all "Being worked on"
(09:13:17 AM) gac410: Other items not on agenda. We need help with weblate (freebsd installation) and git migration
(09:13:55 AM) gac410: Actually except for the small number of release blockers, I think things are looking quite good\
(09:14:16 AM) ***CDot knows nothing useful about either of those, and probably needs to spend his limited time on things more applicable to his skills
(09:14:47 AM) gac410: I'm hoping that gmc, pharvey and babar can free a block of time sometime soon. :)
(09:15:27 AM) CDot: yes, I agree gac410, itʼs not looking bad. But we really need some minshare on getting the last few done - especially those people who have "Waiting For"s]
(09:15:39 AM) MichaelDaum: my apologies for any open tasks I didnt find time to work on since the last RM. :(
(09:16:27 AM) gac410: yes CDot, and no worried MichaelDaum ... Just getting a "i'll do it" is much better state than languishing without any direction.
(09:16:38 AM) MichaelDaum: I am stuffed with work for hire atm ... which basically is a good thing ... but bad for the open source activities planned ahead. 
(09:17:04 AM) MichaelDaum: gac410, of course.  
(09:17:43 AM) gac410: Well lets make a pass through the list on the agenda. I suspect a lot of these can be just set waiting for release.
(09:18:10 AM) CDot: go for it 
(09:18:21 AM) gac410: Ah... first, CPAN Contrib. The only remaining issue is we have two deps that require native compile.
(09:18:41 AM) gac410: So I think the bottom line is we ship without them in the contrib. Which means no wysiwyg.
(09:18:47 AM) CDot: ʼrequireʼ or ʼappear to requireʼ
(09:19:04 AM) CDot: cos they would never have been added if weʼd had a native require
(09:19:24 AM) gac410: I've tried to build several times with pureperl flag, etc. They always compile c code.
(09:19:39 AM) CDot: the HTML parser was chosen specifically because it had no compilation deps
(09:19:43 AM) MichaelDaum: which deps are these?
(09:20:03 AM) CDot: possible LibXML, I canʼt remember the detail
(09:20:15 AM) gac410: The HTML parser was one. And now I'm kicking myself Can't find the list.
(09:20:51 AM) MichaelDaum: no wysiwyg by default? thatʼs bad.
(09:21:22 AM) gac410: Okay. it's in the svn CpanContrib topic.
(09:21:41 AM) MichaelDaum: there are so many wiki markup haters out there ... (while there is a growing number of wiki markdown lovers)
(09:22:06 AM) gac410: HTML::Parser and Net::SSLeay
(09:22:55 AM) ***CDot is researching HTML::Parser
(09:22:57 AM) gac410: SSLeay means no SSL email (gmail support for ex.) It has external dependencies for OpenSSL
(09:23:31 AM) gac410: There is a lite HTML::Parser as I recall that has no native code, but uses a different API from what I recall seeing.
(09:23:39 AM) MichaelDaum: makes sense. well, no ssl, means no ssl email either.
(09:24:03 AM) CDot: yes, HTML::Parser has a pure perl version
(09:24:28 AM) gac410: Really? Okay lets' table. and I'll talk with you later. I could not get it to install with cpanm
(09:25:26 AM) gac410: The SSL just says that on a "fully / correctly installed linux box" we just default to sendmail. But for the non-linux newbies, the perl mail implementation is an issue
(09:25:45 AM) jast: thereʼs only so much we can do, isnʼt there
(09:25:56 AM) gac410: Right. That one we just document.
(09:26:21 AM) gac410: It was more the HTML::Parser I was concerned with. And CDot and I will resolve
(09:26:52 AM) CDot: itʼs grown a dependency on XSLLoader that wasnʼt there before :-(
(09:27:11 AM) gac410: ugh. That was fast.
(09:27:45 AM) gac410: So we could install an old version ... with possible risk of perl syntax deprecations qw() etc.
(09:29:22 AM) gac410: Regarding the Logging. I've implemented flock based locking. And also implemented a new rotation strategy for plainfile (rename the logfile) But with comments about flock cross-platform issues, Is this acceptable?
(09:30:29 AM) gac410: So http://foswiki.org/Tasks/Item12712 needs a code review. To make sure I have not made a hash of the logger. (It rotated okay on trunk.foswiki.org on 1 Jul, but that's not a very active system.
(09:31:33 AM) CDot: are there no unit tests?
(09:31:44 AM) gac410: Maybe if cdot or anyone else with file locking experiences could review 12712 ... the unit tests pass.
(09:31:59 AM) gac410: But they don't really have any concurrency,
(09:32:57 AM) gac410: And the tests do rotate the logs. So what's there works, and is *probably* better on a busy system than it was.
(09:34:03 AM) MichaelDaum: perlʼs flock is x-platform as far as I know
(09:34:28 AM) gac410: Everything I've read says so too, but cdot and jast iirc have concerns, right"
(09:34:30 AM) gac410: right?
(09:34:31 AM) CDot: I donʼt think so; flock is a stub on some platforms, and behaves oddly on others
(09:34:53 AM) CDot: I had a lot of problems with it in the past
(09:35:36 AM) gac410: Well the question is. with NO locking, it's 100% wrong on all platforms. foswiki.org crashes at midnight every first of month. And I manually rotate the logs. Is flocking better than no flocking?
(09:36:01 AM) MichaelDaum: gac410, yes I have seen this in the logs regularly.
(09:36:34 AM) MichaelDaum: CDot, do you remember which systems had problems with traditional flock semantics?
(09:36:44 AM) CDot: Winblows
(09:37:00 AM) MichaelDaum: which perl?
(09:37:08 AM) MichaelDaum: distrowise I mean
(09:37:17 AM) CDot: god knows. Quite a while ago now; probably 5.10 or earlier
(09:37:32 AM) CDot: it might have been active
(09:37:38 AM) gac410: Well another option is a checker that forces CompatibilityLogger on platforms where we know locking is a possible issue.
(09:37:47 AM) CDot: Iʼve been using stawberry for a few years now
(09:37:49 AM) gac410: Or at least warns.
(09:38:29 AM) CDot: I think the best strategy is to use flock, and just kow that if there are problems, thatʼs likely the source
(09:38:42 AM) MichaelDaum: +1
(09:38:53 AM) CDot: cos otherwise we end up trying to protect against every cockamamie distro/OS
(09:39:05 AM) gac410: Anyway, the 1.1.x PlainFile does no locking. Even during rotation. So I think what I have is an improvement. But would appreciate a review due to it's critical placement. :)
(09:39:52 AM) MichaelDaum: if we have some platforms known to cause problems we can docu that at some point. but only if we really are sure that these platforms do have a flock problem. otherwise it is a "wings are _not_ on fire" message by the captain
(09:39:53 AM) gac410: I do rename an open file though. I know that's safe on linux. not sure about other platforms.
(09:41:45 AM) gac410: okay. lets leave it as is. If someone could take the action to give the code a quick review that would be greatly appreciated.
(09:42:12 AM) CDot: depends who has the file open, duzznt it?
(09:42:13 AM) gac410: I'll gladly defer to those with more experience / wounds / bandages :)
(09:42:33 AM) jast: all platforms have an flock problem if common networking filesystems are used btw :)
(09:43:12 AM) jast: I donʼt have much experience with flock, though, so I donʼt think I can do any helpful reviewing
(09:43:56 AM) gac410: right. So we can document / release note that as well. Logging to network file system, use compatibility, or better yet, Log::Dispatch with the PID in the filename to prevent collisions.
(09:44:10 AM) MichaelDaum: the code looks c&p right from the man pages ... seems fine.
(09:44:18 AM) CDot: a review tells you nothing; flock errors are ignored anyway, so even if itʼs SNAFU itʼs going to fail silently
(09:44:34 AM) CDot: so, fine. Go for it.
(09:44:44 AM) gac410: which puts us right where we are today without flock. Okay. I'll close the task.
(09:44:48 AM) gac410: yay.
(09:44:51 AM) jast: a review can tell whether there are obvious deficiencies. weʼve already established that there are non-obvious ones. ;)
(09:45:50 AM) gac410: Okay. moving on. Item10344 metacache. Waiting for feedback from sven / pharvey for 3 years now.
(09:47:42 AM) MichaelDaum: never looked at this piece of work
(09:49:00 AM) jast: me neither
(09:49:31 AM) CDot: nor me
(09:50:16 AM) gac410: Just because it's been in the code for so long, I think it's safe to keep. It is not a configurable cache like the others. the 12xxx revs are all perlcritic / perltidy commits
(09:51:01 AM) CDot: right
(09:51:36 AM) CDot: pharvey has a history of not closing completed tasks; it may still be open because of that
(09:52:22 AM) gac410: I think we can set waiting for release.
(09:52:52 AM) gac410: Item10689 seems to be related to excessive rcs calls. MichaelDaum?
(09:55:42 AM) MichaelDaum: sec
(09:56:45 AM) MichaelDaum: let me check the check-in
(10:00:26 AM) MichaelDaum: well the discussion on the task and in the code still argues for code correctness wrt getting a "trusted" revision number
(10:00:50 AM) MichaelDaum: my findings during this dev cycle were different
(10:01:25 AM) MichaelDaum: while researching those excessive rcs calls
(10:01:47 AM) MichaelDaum: might be CDot, Sven and I am still not on the same line here
(10:02:45 AM) MichaelDaum: from what I see in 10689, the bulk is related to mongodb allowing it to establish multiple revision listeners within the code. nothing I am comfortable with.
(10:02:47 AM) CDot: Iʼm quite happy with the current code behavior. Mind you, I no longer use RCS.....
(10:03:57 AM) CDot: itʼs absolutely certain, however, that the core has to delegate the revision finding to the store. It must never modify version numbers on the fly because it thinks it knows best - it doesnʼt.
(10:04:11 AM) gac410: IIRC sven was going to deprecated the concept of listeners.
(10:04:18 AM) CDot: which - as far s Iʼm aware - is where we are at.
(10:04:52 AM) MichaelDaum: this changeset however speaks a different language http://trac.foswiki.org/changeset/11575
(10:05:37 AM) MichaelDaum: it iterates over all event_listeners and picks the first (random) one able to deliver a history
(10:06:46 AM) CDot: it depends on where that code is....
(10:07:14 AM) MichaelDaum: my first innocent question would be: why _search_ for a listener instead of _knowing_ which listener to use ... whatever is going on anyway
(10:07:42 AM) CDot: where are you looking?
(10:07:43 AM) MichaelDaum: as for the listener pattern in programming ... "ask a listener" is pretty odd
(10:07:59 AM) ***CDot is reading the changes to Meta.pm, whcih so far look totally innocent
(10:08:08 AM) MichaelDaum: a listener listens ... and so is passive. all listeners are notified.
(10:08:17 AM) MichaelDaum: otherwise youʼd call it a handler or impl or whatever.
(10:09:03 AM) gac410: I'm pretty sure a while back that Sven was lamenting the listener code and wanted to remove it. I started investigating a store to use amazon or other network store for attachment mirroring, and sven told me the listeners were deprecated.
(10:09:05 AM) CDot: it looks like a work in progress :-(
(10:09:07 AM) MichaelDaum: but thats pretty much all of my 2cent I am able to spent on the code so far ...
(10:09:08 AM) gac410: So I drpped it.
(10:10:13 AM) gac410: I think the question on these tasks is do we need to revert the code, or just leave it in 1.2. If it's safe to leave it's probably lower risk to not remove it than to start making changes.
(10:10:19 AM) CDot: y, Sven tried to overload the listeners for an external store provider. But right now, the listeners are the only game in town - he never finished the impl of the alternative
(10:10:33 AM) CDot: we cannot revert - you will kill PFS completely.
(10:11:09 AM) ***MichaelDaum grepping for more "ask listener" patterns in lib/
(10:11:43 AM) CDot: sorry, I take that back - PFS wonʼt break
(10:12:07 AM) CDot: the listener stuff, IIRC, was intended for caches only
(10:12:19 AM) JulianLevens: No, it wonʼt, looks to me like all these changes have been superceded
(10:12:24 AM) CDot: Sven was trying to massage it into something useful for a full store
(10:12:38 AM) gac410: Yeah I searched the irc logs and sven commented that MetaCache was dependent on the listeners.
(10:12:56 AM) JulianLevens: He replaced it with ImplementationClasses inheritance iirc
(10:13:17 AM) CDot: ok, there may be other things that depend on it. Not sure about DBIStoreContrib
(10:14:00 AM) JulianLevens: I remember removing listeners from Versatile and a chat with Sven on irc when he removed them
(10:14:12 AM) MichaelDaum: http://trac.foswiki.org/changeset/15838
(10:14:20 AM) CDot: seems I didnʼt use them in DBIStoreContrib either
(10:14:56 AM) MichaelDaum: JulianLevens, right. the listener api is no more. see CS 15838.
(10:15:14 AM) CDot: oh shit, yes, that dynamic class hierarchy. Totally obscure.
(10:15:38 AM) gac410: Ah 15838 The cause of all the .changes file corruption :(
(10:15:52 AM) CDot: y, we need to do that
(10:16:06 AM) MichaelDaum: so both http://foswiki.org/Tasks/Item10689 and http://foswiki.org/Tasks/Item9715 overlap in intention
(10:16:32 AM) MichaelDaum: with the latter reverting changes from the former
(10:18:13 AM) gac410: Okay So looks like 10689 can be closed, and 9715 waiting for release.
(10:18:17 AM) CDot: thatʼs OK, I never liked the listeners anyway. They never got released, at least not to the common man.
(10:19:26 AM) gac410: Good. http://foswiki.org/Tasks/Item2232 is 5+ years old. Added unit tests to 1.1.0, I think we can just NoAction this one, unless someone wants to defer to 2.0 Proposed deprecation of the search limit paramter
(10:20:16 AM) CDot: I think we should defer
(10:20:25 AM) CDot: itʼs still a laudable aim
(10:20:27 AM) gac410: Ah I Skipped Item12019. That's jquery changes. and MichaelDaum already commented that some were wrong and needed to be reverted.
(10:20:39 AM) gac410: Oky. 2232 defer. Sounds reasonable.
(10:21:13 AM) MichaelDaum: yes, and I am pretty sure deprecating a limit param ... no matter how bad it is wrt semantics on webs ... isnʼt the right approach
(10:21:50 AM) gac410: I made 2232 a "Proposal Required" task and pushed out to 2.0
(10:22:00 AM) MichaelDaum: okay. anyway. the root cause of the problem goes much deeper.
(10:22:09 AM) MichaelDaum: poor 2.0 developers
(10:22:12 AM) gac410: :)
(10:22:31 AM) gac410: Well proposal required is sort of a wasteland
(10:23:16 AM) MichaelDaum: Iʼlll flag Item12019 being worked on for me
(10:23:26 AM) gac410: Thanks MichaelDaum
(10:24:03 AM) MichaelDaum: it basically means: check which code is using this api and if none does, revert.
(10:24:54 AM) MichaelDaum: next is Item10484, right?
(10:24:57 AM) gac410: Okay. http://foswiki.org/Tasks/Item10484 CDot said "It's a limitation of the language, and a usage that needs to be dropped, urgently. "
(10:26:58 AM) CDot: there are no code changes required, though perhaps dropping it from doc would be a good idea
(10:27:18 AM) gac410: The checkins add unit tests that all pass.
(10:27:51 AM) gac410: CDot can you take the action to update the docs. I don't fully follow the issue.
(10:28:22 AM) jast: +1 for de-doc-ing it
(10:28:24 AM) CDot: I can try - though Iʼm concerned that any explanation is going to be dangerously complex
(10:28:31 AM) gac410: If we are dropping a documented usage, probably ought to add it to the release notes as well.
(10:31:21 AM) gac410: How are we doing ... 1.5 hours into the meeting. Everyone still have a bit of time?
(10:31:53 AM) ***CDot is working and listening, so no problem
(10:32:46 AM) gac410: Okay. Next: http://foswiki.org/Tasks/Item10203 ajax on the registration page.
(10:33:49 AM) gac410: I'll set 10203 to me. And test the registration form a bit more. It's seemed to be working okay for me.
(10:34:12 AM) gac410: If anyone has an IE environment they can verify registration with, that would be helpful.
(10:36:28 AM) gac410: jast: http://foswiki.org/Tasks/Item11482 was your task. Can you review and set waiting for release if you are satisified with the fixes?
(10:36:40 AM) gac410: No NO... sorry
(10:36:43 AM) gac410: Not jast.
(10:37:04 AM) ***MichaelDaum checking user registration
(10:38:09 AM) gac410: I think Item11482 might be a "pharvey neglected to close" His last comment was fix looks good enough. So unless objections, lets close.
(10:39:58 AM) CDot: yes, close
(10:41:04 AM) gac410: done
(10:41:09 AM) MichaelDaum: gotta leave in 20 mins
(10:42:13 AM) gac410: Okay. item12181 TMCE 3.5.11 Micha, you had concern that I reverted the template from default back to x3p0 or whatever it is.
(10:42:34 AM) gac410: But that fixes a 404 issue on a missing file in the default template.
(10:43:14 AM) MichaelDaum: Iʼve been testing the editor on trunk with no problems so far. Iʼve set the skin to default in Main.SitePreferences ... works without probs so far.
(10:43:24 AM) MichaelDaum: I havenʼt seen your 4o4 though
(10:44:13 AM) gac410: hm. On trunk.foswiki.org, or in your local install
(10:44:19 AM) MichaelDaum: on my install
(10:45:28 AM) gac410: I was seeing the 404's on t.f.o as well IIRC, and had dismissed it that was quite a while ago. If you want, go ahead and switch the template and we can see if it comes back.
(10:47:12 AM) MichaelDaum: Iʼll try
(10:47:54 AM) gac410: http://foswiki.org/Tasks/Item11624 Sven's comment was he didn't mean to commit, and I reverted all of it. It was all 1.1.x commits, Unless someone wants to tackle I think we can defer to 2.0
(10:48:17 AM) gac410: (which it already is. ...)
(10:48:33 AM) jast: +1 defer. hardly urgent.
(10:49:26 AM) gac410: http://foswiki.org/Tasks/Item10129 seems to be complete, so unless concerns, I'll make waiting for release. (Adds operators to quesries. performance issue with query across revisions)
(10:50:16 AM) jast: I donʼt know enough about any of that to raise concerns
(10:50:26 AM) CDot: yeah, thatʼs insoluble
(10:50:46 AM) CDot: itʼs down to the old RCS recreating every old rev problem
(10:51:01 AM) CDot: and then doing that each time a rev is referenced
(10:51:06 AM) CDot: verrrrrrry slow
(10:51:27 AM) ***CDot thinks he documented it
(10:52:03 AM) gac410: Yes I recall seeing comments in docs about slow cross-rev queries.
(10:52:03 AM) gac410: http://foswiki.org/Tasks/Item10376 is experimental code. Maybe I'll try to push pharvey to address. Foswiki::Address is used, so we cannot revert.
(10:54:28 AM) gac410: http://foswiki.org/Tasks/Item12115 crash related to UseLocale. I'm wondering if we should had a config checker that flags UseLocale as an error if enabled? And release note the known issues with UseLocale
(10:56:20 AM) gac410: We are 5 minutes off from 2 hours. Any closing comments? next meeting July 21st same bat-time same bat-channel?
(10:57:04 AM) CDot: we obviously need to check UseLocale
(10:57:25 AM) CDot: itʼs horrible to test, because it depends on so much in the environment :-(
(10:58:29 AM) CDot: just a heads up that I have nearly finished decoupling Configure core and ConfigureContrib. It was a lot harder than anticipated, due to code being added in random - and inapproproate - places
(10:58:41 AM) CDot: and some stunningly obscure code, too :-(
(10:59:10 AM) gac410: The checker currently only warns for Windows, or Perl < 5.8.8 I think we should just flag UseLocale as experimental and be done with it until dev's tackle an i18n release.
(11:00:14 AM) gac410: CDot: Excellent. Thanks for the good work on a rather painful effort.
(11:01:07 AM) gac410: Okay everyone. Excellent meeting. Thanks. I'll update any tasks to reflect our discussion and post the irc log to the release notes.
(11:01:15 AM) CDot: thanks George et al
(11:01:51 AM) JulianLevens: + more thanks
(11:01:57 AM) MichaelDaum is now known as MichaelDaum_
(11:02:46 AM) gac410: Next meeting Monday July 21. 1300z And maybe we can focus on release blockers. There are not all that many ... In meantime I'll try to push gmc, pharvey and babar to have a push at weblate and git
(11:03:48 AM) gac410: My only issue with weblate is there are pieces that don't have freebsd packages available. I'm not familiar enough with bsd to attempt to install them manually
(11:06:25 AM) jast: from what I&#700;ve heard from our IT infrastructure guy, it can&#700;t be worse than setting up pootle anywhere ;)
(11:07:17 AM) gac410: :) pootle and weblate are very similar in their requirements :( Same django backend, same dependencies :P )
(11:11:26 AM) MichaelDaum_ is now known as MichaelDaum
(11:11:29 AM) MichaelDaum: thanks guys.
(11:11:56 AM) MichaelDaum: let&#700;s update the facebook page for the next meeting and beat the drums a bit more, hopefully.
(11:12:39 AM) ***gac410 doesn&#700;t use facebook
(11:13:38 AM) MichaelDaum: I&#700;ll do
(11:16:42 AM) gac410: Thanks MichaelDaum
(11:17:03 AM) gac410: The other thing I didn't do was an email reminder. Probably should do that to foswiki developer list.
(11:18:11 AM) MichaelDaum: I&#700;ll update the FB link as soon as http://foswiki.org/Development/ReleaseMeeting01x02_20140721 materializes
(11:18:53 AM) gac410: okay. I'll get this all polished off tonight while you are all sleeping. Hopefully nice shiny pages tomorrow morning for you. :)
(11:23:19 AM) MichaelDaum: yay