Release Meeting: 12 Jan 2015

(08:00:25 AM) andreli entered the room.
(08:02:09 AM) MichaelDaum: hi everybody
(08:02:14 AM) gac410: good morning /  good day all
(08:02:17 AM) jast entered the room.
(08:02:47 AM) andreli: Hello to all
(08:02:53 AM) jast: well that's a new record. 28 windows open in IRC client...
(08:02:54 AM) MichaelDaum: new release blocker: http://foswiki.org/Tasks/Item13207
(08:03:23 AM) jast: unfortunately I probably won't be able to be involved much today, the urgent tickets keep on coming in...
(08:07:40 AM) gac410: okay all ...   want to get started? 
(08:07:45 AM) gac410: Happy New Year!
(08:09:09 AM) MichaelDaum: did you all have a good start into '15?
(08:09:30 AM) gac410: good for me so far.  thanks.
(08:10:23 AM) MichaelDaum: some people still seem to be in the entrance section while warming up
(08:10:36 AM) andreli: Thanks. Same wishes to you all.
(08:11:18 AM) gac410: Agenda Item 1.    We need to make sense of our pile of  "stuck" tasks.   ReleaseNormals    780 last count.   I've been trying to triage.  assign a component  And move them off of "New" status to Confirmed,  or NeedDeveloper 
(08:11:38 AM) gac410: Found a bunch we've actually fixed ... and duplicates as well. 
(08:13:14 AM) MichaelDaum: Agenda Item 2. review current release blockers
(08:13:35 AM) MichaelDaum: Agenda Item 3. state of translation (infrastructure)
(08:14:02 AM) gac410: er.   Item 3.  Cleanup   
(08:14:07 AM) gac410: ?
(08:14:22 AM) MichaelDaum: do we have weblate in place already?
(08:14:53 AM) gac410: No.   Been waiting on gmc.      Neither pootle or weblate are installed.   and the whole configuration for pootle was lost.
(08:15:28 AM) gac410: gmc keeps getting delayed by real life.  Promised he'd get to it soon.
(08:15:41 AM) MichaelDaum: are there alternatives hosting weblate for foswiki translations
(08:16:38 AM) gac410: not that I'm aware of, but I've not looked.   Our server is capable.  just need an admin to deal with installing.   Ports are not available for all the pieces.
(08:17:20 AM) MichaelDaum: so it will be a make configure / make / make install -ish job?
(08:17:42 AM) gac410: yeah.   for a couple of the pieces.   It's python / wsgi.  
(08:18:04 AM) gac410: as was pootle.   so not a big difference.
(08:18:13 AM) MichaelDaum: I can imagine.
(08:19:18 AM) MichaelDaum: so we can't say much without gmc's feedback on the remaining issues ... or how to help him out admin'ing the server
(08:19:31 AM) MichaelDaum: nor do we have much other resources doign bsd 
(08:19:32 AM) gac410: Okay release blockers.       I'm on http://foswiki.org/Development/ReleaseMeeting01x02_20150112
(08:19:51 AM) gac410: and back to bsd.     Babar was the only other who seemed to know the server
(08:20:18 AM) gac410: last summer though was when some update attempts meant gmc had to rebuild the server iirc.   
(08:20:18 AM) MichaelDaum: both have been next to n/a for quite some time now
(08:20:33 AM) gac410: gmc is willing,  just busy.
(08:21:07 AM) gac410: it's 5:20 am where Babar is, and he's pretty tied up with his new job 
(08:21:24 AM) MichaelDaum: understood. how can we help him or release the burden from his shoulders?
(08:21:44 AM) gac410: gmc is hosting the server in his data center.  and he said he's willing to do it.   just to keep after him.
(08:22:01 AM) andreli: What kind of release blocker is the missing translation infrastructure?
(08:22:26 AM) gac410: If we can't translate,   ...   not much of a release for the non-english world.
(08:22:41 AM) andreli: I guess, the missing translations should neither delay an alpha nor a beta release, no?
(08:22:50 AM) MichaelDaum: true
(08:22:50 AM) gac410: I'd like us to have the Translations' done at least for the Beta.       but not delay Alpha.
(08:23:25 AM) MichaelDaum: put in other words: part of the project's infrastructure has broken down
(08:23:26 AM) gac410: Or at least the translations started for Beta.   I have no idea the condition ofo our language files.    Trunk was never running on pootle, only release branch.
(08:25:26 AM) MichaelDaum: okay lets move on
(08:26:27 AM) gac410: Okay   blockers are looking pretty good.   Still a bunch but a lot imo are there for visibility ... to get them out of the useless "Normal" queue.
(08:26:31 AM) MichaelDaum: we covered Agenda Item 4 so far with no resolution of problems so far
(08:27:07 AM) gac410: We really need gmc.    Or need to restart a infrastructure & translation team to work on it.
(08:27:51 AM) ***MichaelDaum added 13207 to the list of items to discuss
(08:28:24 AM) MichaelDaum: http://foswiki.org/Tasks/Item12097: "NatEdit in foswiki trunk allows a user to see and edit the AUTOINC topic name - can we conditionally hide that?"
(08:28:50 AM) MichaelDaum: I tried to repro the bug report this morning but wasn't able to do so right away.
(08:29:02 AM) gac410: Create a task, any task, on trunk.foswiki.org
(08:29:21 AM) ***MichaelDaum tries
(08:29:25 AM) gac410: Any task on trunk acquires a Title of AUTOINC
(08:30:22 AM) gac410: ie  http://trunk.foswiki.org/Tasks/Item13201?raw=all     
(08:30:48 AM) gac410: %META:PREFERENCE{name="TOPICTITLE" title="TOPICTITLE" type="Local" value="ItemAUTOINC1"}%
(08:32:07 AM) MichaelDaum: I need a simpler test case
(08:32:44 AM) gac410: Simpler than creating a task on trunk?
(08:32:59 AM) jast: maybe something easier to transplant to a local dev env?
(08:35:31 AM) MichaelDaum: ah got it now
(08:37:51 AM) MichaelDaum: being worked on
(08:38:10 AM) gac410: Jast...  I've posted a couple of tasks waiting for you.   Could you review?    (One was a continuation of your BEGIN blocks   added to TablePlugin/Core.pm   to make it sort correctly.
(08:40:04 AM) gac410: And also, http://foswiki.org/Tasks/Item11953 ...   which seems to be ready to release, given we'll build 1.2.0 without -T taint flags.
(08:40:50 AM) gac410: the first was  Item12569: add use locale for table sorting
(08:42:46 AM) gac410: Back to blockers.   http://foswiki.org/Tasks/Item13040    nginx issues.    Needs some more testing of bootstrap process on nginx.   And are we ready to incorporate FastCGIEngine into our release package.
(08:45:39 AM) gac410: Is MichaelDaum the only regular nginx user?    I've got a test vm I can play with but I don't use it regularly
(08:46:49 AM) MichaelDaum: FCGI should get a flag to enable/disable LSC checking to improve stability under certain circumstances
(08:47:17 AM) MichaelDaum: Item13010 did not get any feedback from others at all
(08:48:13 AM) gac410: Crawford just closed Item13141    with a fix. 
(08:48:37 AM) MichaelDaum: ... earlier today
(08:48:51 AM) gac410: Item13010 ..  I'm not sure how many devs run nginx day to day.   I'm happy to go with your fixes. 
(08:49:10 AM) MichaelDaum: most of my clients do using the Item13010 branch of FastCGIEngineContrib
(08:49:28 AM) MichaelDaum: however none of them bootstraps a LocalSite.cfg anymore
(08:49:39 AM) MichaelDaum: and will never do so any time soon
(08:50:35 AM) MichaelDaum: gac410, please try the Item13010 branch and see what happens.
(08:50:47 AM) gac410: I could probably get my test vm with nginx running an updated.     
(08:51:14 AM) gac410: MichaelDaum:  Did you release it to Extensions/Testing?    We could install it on Foswiki.org to make sure it's stable on Apache.
(08:51:31 AM) MichaelDaum: this needs testing on nginx though
(08:52:30 AM) MichaelDaum: I did a release in last August at http://trunk.foswiki.org/Extensions/Testing/FastCGIEngineContrib
(08:52:32 AM) gac410: Right.   I can try it with a test vm on qemu on my laptop,  but I really don't know much about nginx.    So might not be all that valuable, and certainly won't get much of a workout.
(08:53:06 AM) gac410: Okay ... and that's up to date with the Item13010 branch?      I'll bang on it a bit.
(08:53:19 AM) gac410: And try it on apache on foswiki.org
(08:53:31 AM) MichaelDaum: thanks
(08:54:14 AM) MichaelDaum: btw setting up Foswiki on Nginx is well documented imho 
(08:54:36 AM) gac410: Item13177 ... I was waiting for Tarbox to test my proposed fix.  I'd like to take it off the list of blockers.   I don't have an ldap setup avaiable. 
(08:55:13 AM) gac410: Right,   nginx well documented.   But a test vm on qemu from my laptop doesn't give it much of a practical workout.
(08:56:18 AM) gac410: And as you said on http://foswiki.org/Tasks/Item13177 ...   the real fix is a restructuring of a Foswiki "user object"     so I think the fix is probably too high a risk  and refactoring User code is completely off the table.
(08:56:55 AM) MichaelDaum: thats my gut's feeling as well
(08:57:40 AM) gac410: What do you want to do about Item13184 and Item13190      Load times of CompleteDocumentation and SiteChanges.       Just remove the topics from the release?
(08:58:11 AM) gac410: pre-publish CompleteDocumentation as a PDF attachment? 
(08:58:13 AM) MichaelDaum: CompleteDocumentation loading slow has been raised by Crawford 
(08:58:44 AM) gac410: yeah.    sorry,   the "you" was to the team.   
(08:58:47 AM) MichaelDaum: in some way CompleteDocu is an expanded version of ReferenceManual
(08:59:21 AM) MichaelDaum: I've added some javascript driven button to _really_ load all of the reference manual
(08:59:35 AM) MichaelDaum: so at least bots won't hurt us anymore crawling CompleteDocu
(09:00:10 AM) gac410: The performance issues on those two topics have been with us for a long time.     I don't see that they should block 1.2 unless they've been made significantly worse on 1.2
(09:00:19 AM) MichaelDaum: imho we could leave it like it is from a pov that when people really want it they have to pay for it wrt server cpu cycles
(09:00:40 AM) MichaelDaum: SiteChanges ... that one is a different issue
(09:01:06 AM) MichaelDaum: I like your suggestion to implement it in a more intelligent way using eachChangeSince
(09:02:07 AM) gac410: It's just at this point do we want to do that for 1.2 ... 
(09:02:23 AM) ***MichaelDaum wonders why the idea didnt pop up earlyier
(09:03:07 AM) gac410: the good news is that eachChangeSince should be better.   It missed stuff on 1.0, and was broken on 1.1 with misleading information.
(09:03:23 AM) MichaelDaum: yea it is a significant piece of code. not difficult but at least thre would be a new macro
(09:03:41 AM) gac410: Crawford rewrote it as part of the store refactor & fixes for MailerContrib sending bogus change reports.
(09:04:41 AM) MichaelDaum: I receiveed Corrupt /.../data/Blog/.changes: Can't locate Win32/Locale.pm from my server for a couple of days now ... 
(09:05:24 AM) gac410: Any volunteers to write a %WEBCHANGES% macro?      Hm.    That doesn't sound good.
(09:05:28 AM) MichaelDaum: I tried to find out where Win32::Locale would have been loaded on a linux server down in JSON.pm somewhere but wasn'
(09:05:31 AM) MichaelDaum: t successfull
(09:05:44 AM) CDot  entered the room.
(09:05:51 AM) CDot: oops
(09:05:53 AM) gac410: Crawford made .changes file auto-switch between JSON and plain text.
(09:06:35 AM) gac410: Seems to be successful since we are successfully sharing .changes between 1.2 and 1.1  on trunk.f.o & foswiki.org
(09:06:41 AM) gac410: Howdy CDot
(09:07:03 AM) CDot: sorry I'm late, got delayed
(09:07:06 AM) gac410: We were just discussing the two performance blockers.   SiteChanges and CompleteDocumentation.
(09:07:12 AM) gac410: np
(09:07:21 AM) CDot: y, completedocumentation is a bear
(09:07:44 AM) MichaelDaum: not as much of a problem as SiteChanges
(09:07:45 AM) gac410: Michael added a js button to delay   so crawlers don't fetch it.
(09:07:53 AM) CDot: at least, it is on my diddy little 4GB machine
(09:08:21 AM) CDot: I thought sitechanges was driven from .changes?
(09:08:37 AM) gac410: For SiteChanges.    What's your (CDot) thought on %WEBCHANGES% macro driven off of .changes file.    No... It uses SEARCH   I'm pretty sure.
(09:08:48 AM) MichaelDaum: there is a sufficient message at Complete Docu saying "Caution the content is very large and loading it will put a high load on your browser. Only load the content if you are going to print it - otherwise use the online reference manual."
(09:09:12 AM) CDot: MichaelDaum: y, I wrote that to at least document this problem
(09:09:55 AM) MichaelDaum: this should suffice in the sense of "if you click here you deserve it"
(09:11:08 AM) MichaelDaum: SiteChanges is based on %SEARCH 
(09:11:20 AM) MichaelDaum: note that there is at least one other task wrt its javascript
(09:11:45 AM) gac410: SiteChanges   is SEARCH  reverse=on order=modified pagesize=25 
(09:12:28 AM) CDot: nasty. probly been that way since .... oohhhh... 1999?
(09:12:50 AM) gac410: I think a %WEBCHANGES{  web= webfilter based,    since= date,  }%    default to current web,  and 24 hours.
(09:13:32 AM) CDot: I was thinking while I was working on it that .changes is data, same as any other data, and probably ought to be searchable using %SEARCH. I did nothing about it because of the security constraints, though.
(09:14:39 AM) gac410: Yeah,   I was wondering about integration with search.   But I think that's too risky for 1.2.   But a simple macro to list eachChangeSince.   And check viewAuth for each topic (maybe cache the results) would be good
(09:18:03 AM) CDot: hmmm. I thought there *was* a WEBCHANGES. Guess not.
(09:18:23 AM) ***CDot would prefer %CHANGES. Restricting to a single web is just nasty,
(09:19:07 AM) gac410: Well I was proposing WEBCHANGES   default of current web,  or allow web= ... same as webfilter     web=all   web=public .. etc.
(09:20:11 AM) gac410: Basically copy WEBLIST  but expanded to list eachChange.
(09:20:23 AM) CDot: I know. I just don't like %WEB* macros. They are too restrictive, old thinking.
(09:21:02 AM) gac410: Do we have a higher risk of collision with existing wiki apps?    That was the main reason I figured WEB* would be better.
(09:22:29 AM) gac410: Also it's consistent  with the name of the WebChanges topic,  and would be used there as well.
(09:22:36 AM) CDot: possibly, but that's no a reason for going the WEB% route. The core has first dibs on macro names.
(09:22:46 AM) gac410: Old thinking... ya    but I'm old   :D
(09:25:47 AM) gac410: http://foswiki.org/Tasks/Item13199     I'm seeing Javascript errors when Subscribe links are active.     And cursor navigation of SlideShow's   don't work.   Disable Subscribe links and slidshows return. 
(09:27:43 AM) gac410: Anyone want to tackle a  *changes macro?     I could give it a try.      I can copy/paste WEBLIST and MailerContrib's eachChangeSince code together I suspect :)
(09:28:41 AM) CDot: the subscribe macro think is a result of the changes I made to add %NONCE%. It also is making me think how the best way to pass nonces is.
(09:28:53 AM) gac410: And whats the opinion for name.   +1 for CHANGES, and +1 for WEBCHANGES     we need some tiebreakers  
(09:29:14 AM) CDot: I think a CHANGES macro should be failry easy per web - it's harder for multiple webs, but worth doing right.
(09:29:55 AM) CDot: consider the applications; not just SiteChanges, but "all user web changes" etc.
(09:30:17 AM) gac410: The core code in WEBLIST woudl be pretty simple.   The hard part is merging to one list of changes across webs,  instead of a per-web list.
(09:30:19 AM) CDot: just need a list of webs to include (or a regex) and a list of webs to exclude (or a regex)
(09:30:32 AM) CDot: y, the merge is what makes it interesting
(09:30:45 AM) CDot: mergesort is the way to go :-)
(09:31:33 AM) gac410: I figured use the existing WebFilter  will do a list of candidate webs with a well tested auth checking and filtering.    From theere,   it's forEach   (web returned from webFilter )...  
(09:32:46 AM) gac410: Nice idea on the user sort.    For spam checking   I revert to shell and use   find . -name .changes | xargs grep "Thespammer"       A CHANGES user=""  would be really nice
(09:32:50 AM) CDot: hmmm. personally I'd create an iterator for each web and then merge the iterators.
(09:33:14 AM) CDot: oh yes, that would be cool
(09:33:25 AM) CDot: "all my changes, everywhere"
(09:34:05 AM) gac410: The only downside is that it's time limited by the life of events in .changes.
(09:34:33 AM) CDot: ah, that's just because of the crappy impl of .changes. If you use a DB store, it isn't time limited
(09:34:50 AM) CDot: a better impl of .changes in the text stores could deliver the same thing
(09:34:56 AM) gac410: y
(09:35:13 AM) CDot: I never intended the monolithic json file as a long term solution
(09:35:45 AM) MichaelDaum: we should consider using DBI more
(09:35:58 AM) gac410: One more task that's yours CDot ... The changes to the TMCE attach dialog seems to have broken the "Insert a link" function   http://foswiki.org/Tasks/Item13200
(09:36:09 AM) CDot: whoah! Micha just woke up and smelled the coffee!
(09:36:12 AM) CDot: ;-)
(09:36:34 AM) gac410: When Micha gets quiet, expect a checkin shortly  :)
(09:36:44 AM) CDot: really? Odd, I didn't touch that function. Possibly shrapnel from the explosion cut a wire somewhere.
(09:36:55 AM) MichaelDaum: DBI with a low level driver that runs everywhere
(09:37:39 AM) gac410: TBH I think we are in very good shape ... 
(09:37:40 AM) MichaelDaum: rewriting the user api could benefit from it as well
(09:37:47 AM) CDot: y, I considered rewiring the store to do that. Decided against it in the end - too much work managing current data
(09:38:06 AM) gac410: let's not start any rewriting   at this stage ...    
(09:38:09 AM) MichaelDaum: did you get a chance to digest http://foswiki.org/Tasks/Item13207
(09:38:18 AM) MichaelDaum: rewrite means 2.0.0
(09:38:26 AM) CDot: many things would benefit (e.g. FilesysVirtualPlugin)
(09:38:52 AM) ***gac410 is going to start wearing RM hat and reverting any major changes that are not due to a blocker. 
(09:39:07 AM) gac410: Call me LavrJr
(09:39:15 AM) gac410: :)
(09:39:51 AM) MichaelDaum: 13207 needs a fix for Wysiwyg I guess. Foswiki::Renderer ... that I understand
(09:40:52 AM) CDot: MichaelDaum: your patch should work for WysiwygPlugin too
(09:41:02 AM) ***MichaelDaum not sure where to apply it
(09:41:13 AM) CDot: in the WysiwygPlugin TML parser
(09:41:28 AM) CDot: erm, TML2HTML.pm (or below)
(09:42:03 AM) CDot: the code should look familiar, since it's based on Render.pm
(09:42:20 AM) gac410: Need to be careful about inserting spaces.   Tends to cause topics to grow one-space-per-save
(09:42:54 AM) MichaelDaum: this is only during render ... not during save
(09:42:57 AM) CDot: I *think* it should manage that space correctly
(09:43:48 AM) ***gac410 has holes in foot dealing with whitespace in wysiwyg  :D
(09:43:55 AM) CDot: MichaelDaum: you have to think about the whole cycle; TML2HTML->save->HTML2TML->view->TML2HTML..... etc
(09:44:07 AM) CDot: y, it's a bugger
(09:44:23 AM) MichaelDaum: thats why I expressed my concerns on my own patch
(09:44:43 AM) gac410: First thing is to try to recreate by adding a testcase to the WysiwygPlugin/TranslateTests ... Fairly easy to do.    
(09:44:45 AM) MichaelDaum: i.e. why does the table parser consume the previous linefeed
(09:45:50 AM) gac410: ah... good point.  
(09:47:35 AM) MichaelDaum: I guess the problem is that the line parser spits by \n but then joins using an empty string
(09:47:49 AM) CDot: exactly
(09:48:09 AM) CDot: historical, probably
(09:48:15 AM) MichaelDaum: histerical
(09:48:21 AM) CDot: and no doubt something horrible happens if you change it
(09:48:43 AM) gac410: MichaelDaum:  we need a tiebreaker.    Should list of changes be %WEBCHANGES% or %CHANGES%  or something else entirely ... just to make things interesing.
(09:48:58 AM) MichaelDaum: ... when nesting lists and tables and tml
(09:49:21 AM) gac410: That's probably where the mines do lie.
(09:49:59 AM) MichaelDaum: %CHANGES is better.
(09:50:08 AM) MichaelDaum: but not much
(09:50:17 AM) CDot: %ALTERATIONS%
(09:50:21 AM) MichaelDaum: argh
(09:50:23 AM) CDot: %MODIFICATIONS%
(09:50:25 AM) MichaelDaum: argh
(09:50:26 AM) CDot: %EDITS%
(09:50:31 AM) MichaelDaum: CHANGES is the right term
(09:50:47 AM) MichaelDaum: but the name of a macro is not the problem
(09:50:52 AM) gac410: put fingers in ears,  tap cautiously with left toe ...   see if parser explodes.  ... pick up pieces.
(09:51:07 AM) gac410: what's the problem?
(09:51:19 AM) CDot: %METAMORPHOSES%
(09:51:36 AM) MichaelDaum: see, it needs paging, filtering, whatever replicating list processing and formating results yet again ... worms you need more worms?
(09:52:22 AM) CDot: all of which is why I wanted to use %SEARCH. But, chicken and egg.....
(09:53:02 AM) CDot: %SEARCH{type="changes"
(09:53:21 AM) gac410: hm.   for opening up a really large can of worms ...     I do agree that would be nice though.
(09:54:02 AM) MichaelDaum: SEARCH type changes only makes sense for the standard grep based search algo ... not capable to sort rev by change date on its own
(09:54:26 AM) CDot: huh?
(09:54:29 AM) MichaelDaum: any other SEARCH impl probably wont need it
(09:54:37 AM) CDot: oic, yes, u r right
(09:54:46 AM) CDot: the changes ought to be in the schema
(09:55:07 AM) MichaelDaum: as most scaling database backends are excellent sorter+filter+pager+juggle-in-the-air ...
(09:55:12 AM) CDot: that way the perms problems are easy (for a DBI store at least)
(09:56:01 AM) MichaelDaum: what about calling it %ACTIVITIES
(09:56:14 AM) CDot: in fact n the DBI store, the changes *are* in the schema. Just no accessible though the SEARCH query language :-(
(09:56:30 AM) CDot: %ACTIVITIES%? I prefer %REVOLUTIONS%
(09:56:31 AM) MichaelDaum: and base it on events.log
(09:56:49 AM) MichaelDaum: any change activities are in the event logs anyway
(09:57:07 AM) MichaelDaum: as well as uploads, login and outs, you name it
(09:57:18 AM) CDot: indeed, but the event logs are a lot more fragile than the changes held in the store
(09:57:25 AM) gac410: Logger already has merge iterators,  
(09:57:34 AM) MichaelDaum: gac410, yay
(09:57:54 AM) MichaelDaum: iterating events wont need a merge either
(09:58:13 AM) MichaelDaum: %ACTIVITIES{type="save" ...}%
(09:58:38 AM) CDot: I see events as different to what is stored in .changes
(09:58:38 AM) gac410: y.   That's another thing I do in the hunt for spam.      Also search by IP address
(09:58:40 AM) jast: %TRANSMUTATIONS*
(09:58:42 AM) CDot: .changes is part of the change log
(09:59:14 AM) gac410: Okay.   So we really need both.   an improved %CHANGES%   and an %ACTIVITIES%   
(09:59:19 AM) CDot: %EVENTS is fine for the WebChanges application, it just doesn't work from a traceability perspective
(09:59:25 AM) MichaelDaum: the problem with .changes files is that they split over multiple directories first ... and then are merged back into one stream of changes ...
(09:59:28 AM) CDot: which is where I saw .changes as headed
(10:00:10 AM) gac410: Timothe created an event log viewer that implemented eachEventSince.    It got reverted, and I made an RM decision to defer it for 2.0 
(10:00:17 AM) MichaelDaum: so instead of trackign changes per web ... tracking them for all of the site makes more sense in the first place ... which is more or less the data you get out of events.log
(10:00:32 AM) CDot: though *in theory* you can reconstruct .changes from the meta store with each topic
(10:01:13 AM) gac410: hm.   good point.   So eachChangeSince   is web specific,   and eachEventSince is site specific.     And don't try to merge together.
(10:01:40 AM) ***CDot sees a big confusion looming on the horizon
(10:01:57 AM) gac410: y.   I was just thinking after I typed that    never mind.
(10:02:26 AM) jast: eachWebChangeSince... names just keep getting longer and longer
(10:02:48 AM) gac410: So much of this is clearly 2.0 scope.   What can we do *safely* for 1.2  to deal with the SiteChanges page.   
(10:02:50 AM) CDot: gotta go. On more important topics, does anyone know how to test the centrifugal switch on a washing machine?
(10:03:10 AM) MichaelDaum: safe action would be to remove it
(10:03:23 AM) MichaelDaum: as simple as can be ... very RM-ish
(10:03:38 AM) gac410: Is it *worse* than what's in 1.1.9?
(10:04:15 AM) MichaelDaum: bad enuf. I managed to DoS foswiki.org
(10:04:34 AM) MichaelDaum: with a single requrest
(10:04:38 AM) gac410: If performance is the same,  then removing it is probably not necessary.    Maybe the Javascript "Do you really want to do this" 
(10:05:04 AM) gac410: Well it doesn't really DoS it.    The fcgi timers kill it off.   
(10:05:13 AM) gac410: It does create a heck of a load though.
(10:05:53 AM) MichaelDaum: as a consequence of calling SiteChanges I failed to save another topic for a couple of times
(10:06:06 AM) MichaelDaum: ... which I'd call a DoS in my book
(10:07:45 AM) MichaelDaum: people simply are expecting too much from %SEARCH
(10:09:23 AM) gac410: The problem is., is it truly cause/effect.    The Bot's hit this stuff constantly.   You could have just hit it at the same time that google, yahoo, bing, etc. were all hitting nasty stuff.
(10:10:10 AM) gac410: I think what it comes down to...  On a small site with a small number of webs,   SiteChanges is probably safe.   On a large site,   and as an admin, it's deadly.
(10:10:28 AM) MichaelDaum: y
(10:10:38 AM) gac410: Also if you are an admin it's worse,  because it searches all the webs  that are not public as well.
(10:10:44 AM) jast: on a large site with all topics being public...
(10:12:17 AM) gac410: public/private topics is probably not as bad as public webs.   Since if web is private,  topics are not checked.   If web is public,  then each topic has to be auth checked as well.    Running as admin,  every web is considered   but topic checks are skipped.
(10:12:53 AM) jast: by which I meant, all topic being public by way of all webs being public
(10:13:10 AM) jast: from what I can see as a normal user, foswiki.org is a good example of that... LOTs of topics, all in public webs
(10:13:28 AM) gac410: Anyway,   I don't believe it's worth removing SiteChanges.    I think using the "do you want to do this"  javascript button,  like with CompleteDocumentation.  is sufficient to block the bots from the topic.
(10:14:02 AM) andreli: Isn't fair to assume, that on large installations of foswiki, you have search be managed by a plugin like Solr?
(10:14:10 AM) gac410: And maybe add a note "For large sites, we recommend disabling SiteChanges altogether.
(10:14:16 AM) gac410: True.    good point. andreli
(10:14:37 AM) gac410: What's the impact of SiteChanges on a site with Solr in use?  
(10:14:46 AM) jast: true enough, a big wiki without something like Solr is very painful
(10:15:01 AM) gac410: foswiki.org is getting to that point.   esp. Tasks web.
(10:15:05 AM) jast: rendering site-wide changes with Solr has negligible performance impact
(10:15:22 AM) jast: it basically feels instant
(10:15:30 AM) gac410: Does the topic  SiteChanges  "just work" when Solr is installed ... (Does it capture %SEARCH macros?)
(10:15:34 AM) MichaelDaum: gac410, SolrPluin comes with view templates for SiteChanges, WebChanges and WebSearch that all map it onto a solr wiki app
(10:16:07 AM) andreli: A place where we are still struggling with the limits of search is topic Rename/Delete.
(10:16:08 AM) jast: you can use AutoTemplatePlugin to override the view templates for SiteChanges and friends
(10:16:09 AM) MichaelDaum: SolrPlugin does not implement a %SEARCH algo
(10:16:25 AM) gac410: cool.    In that case,  I feel better about adding a "Do you want to do this"    along with some admin documentation recommending Solr 
(10:16:52 AM) MichaelDaum: as there are too many performance problems in the %SEARCH facade itself 
(10:16:56 AM) jast: andreli: yeah, that's a tricky one. I thought about this some and came up with a concept of storing the links separately from the rest of the content, making the big search&replace unnecessary, but it's not exactly something you could trick in in a minor release
(10:17:58 AM) MichaelDaum: jast, you could do that as a plugin probably
(10:18:29 AM) andreli: jast: yeah, we helped ourselves with a nosql store. Since then, we can use backlinks wiki wide again.
(10:18:46 AM) MichaelDaum: btw SolrPlugin indexes backlins as well
(10:19:35 AM) gac410: BTW   does anyone know if MongoDB  plugin is still usable with 1.2   or have we broken that?   
(10:19:46 AM) jast: I know about _indexing_ backlinks
(10:20:00 AM) jast: what I meant is _storing_ links in a normalized form in the first place
(10:20:09 AM) jast: so a rename wouldn't have to touch all the topics at all
(10:20:29 AM) gac410: jast  have you implemented that locally?  
(10:20:43 AM) jast: no, it was just an idea
(10:20:49 AM) gac410: okay
(10:20:52 AM) MichaelDaum: solr rather indexes _outgoing_  links ... a reverse query then gets you the _backlinks_
(10:21:32 AM) MichaelDaum: anyway ...
(10:21:40 AM) andreli: MichaelDaum: Oh, I will have a look. We collected all metadata in a CouchDB. This was build in a project with the purpose of cleaning up old, forgotten, bad written etc. topics.
(10:21:40 AM) MichaelDaum: where are we on our release meeting agenda
(10:22:04 AM) gac410: We've covered the blockers,   We did Weblate earlier.   Just heard briefly from gmc.   I'll keep on him.
(10:22:27 AM) gac410: Any "New business" to put before the release process?
(10:23:16 AM) MichaelDaum: whats the required action for http://foswiki.org/Tasks/Item13200
(10:23:51 AM) MichaelDaum: and what do we finally decide on wrt SiteChanges?
(10:23:54 AM) jast: finding the bug and fixing it ;)
(10:24:14 AM) gac410: I think CDot needs to look at it.    He refactored the Upload dialog to use jquery / ajax.     and the companion tab - to insert a link - failed. 
(10:24:30 AM) gac410: the tmce pluigins architecture is pretty complex.    
(10:24:39 AM) MichaelDaum: jast, there you go: first finger gets the price :)
(10:25:14 AM) ***CDot returns and reads the logs
(10:25:26 AM) gac410: SiteChanges.     I think we should do same as CompleteDocumentation ... "Really do it" button.     
(10:25:33 AM) jast: regarding SiteChanges... might be a good time to add a topic about performance to admin docs
(10:25:41 AM) CDot: new business: yes, we are falling behind on triage
(10:25:57 AM) CDot: seems to me gac410 is the only one traiging
(10:25:59 AM) gac410: And add a <div> that displays for Admins    recommending Solr
(10:26:34 AM) ***gac410 has been going crazy with triag.    Invented a "Needs Developer" status just to get stuff I don't understand out of the "New" queue
(10:27:36 AM) gac410: It woudl be ****  REALLY REALLY HELPFUL ***   if everyone tried to assign a Component,   and changed tasks from New to Confirmed   or  Being Worked
(10:28:28 AM) gac410: quite a few  tasks were Sven's todo list.   just Engine,   new,   no component  ...    no or vague description.     "Blah didn't work ... fix it later"  
(10:29:01 AM) gac410: As I've been assigning Component,    FoswikiUIRest,  ... etc.     I've been finding duplicates,   fixed tasks, etc.
(10:29:25 AM) andreli: Sorry guys, have to leave. Bye
(10:29:26 AM) gac410: It sure is painful though.
(10:29:35 AM) gac410: see ya ... Thanks for joining
(10:29:54 AM) CDot: gac410: my approach on Sven's reports is to simply close them.
(10:30:15 AM) CDot: Most are aises memoire for himself
(10:30:18 AM) CDot: ^aises^aides
(10:30:19 AM) andreli left the room (quit: Quit: Page closed).
(10:30:30 AM) gac410: When they have no description.  I do.    If I can make sense of them and they seem accurate,  I confirm them and assign a component. 
(10:30:51 AM) CDot: but I agree, they are expecially painful
(10:31:25 AM) CDot: and in needs other people with knowledge - yes, that means you, jast and MichaelDaum - to help triage stuff that is *not* obviously aimed at them
(10:31:26 AM) gac410: I added a new search:   http://foswiki.org/Tasks/NeedsResolution       This is anything with Checkins     trying to figure out what needs action prior to 1.2   
(10:31:40 AM) CDot: cos otherwise, nasties may creep under the radar
(10:32:02 AM) gac410: MichaelDaum:   you also tend to leave tasks in New status.   Which means the next day I triage,   I forget I looked at them   and start all over.   :(
(10:32:22 AM) MichaelDaum: sorry for that
(10:32:30 AM) CDot: "new" means "no one looked at this yet"
(10:32:56 AM) jast: is there a way to be notified about new items without also being notified about changes to all existing items?
(10:33:25 AM) gac410: Or "new information has been added"   Which I really don't like.     It should just stay in Waiting for Feedback,    but with the Dev listed in the Waiting for.     Or maybe we need a new "WaitingForDeveloper"
(10:34:08 AM) ***CDot dislikes "WaitingForDeveloper" because anyone may be a developer
(10:34:31 AM) gac410: I've observed on some of the old tasks.    Dev reviews,  sets Waiting for.   User responds,  and then sets to New.   and theere it sits. 
(10:34:49 AM) MichaelDaum: Waiting and Progress ... these are two opposite things
(10:35:16 AM) gac410: One user even updated a 2nd time, saying  I changed this back to NEW as instructions state.  What more do  you want"     And that was a year back.
(10:36:45 AM) gac410: Once a user clears WaitingFor  we have no clear path back to the Dev.   And I don't expect the user to understand to fill in the Dev's name in WaitingFor field again.
(10:37:56 AM) MichaelDaum: lots of stuff in NeedsResolution is planned for 200 ... so it doesnt really need a resolution _for 120_
(10:38:15 AM) Lynnwood  entered the room.
(10:38:18 AM) gac410: http://foswiki.org/Tasks/NewItems?class=Engine;limit=100,   is down to 25 tasks.    I've made a lot of progress   Was 175 iirc
(10:38:49 AM) MichaelDaum: yay
(10:39:10 AM) gac410: The NeedsResolution issue   is the checkins are in trunk,  which means we'll be releasing partial work.    Though the one that scared me the most was the Store2 refactor.   And the 20 or so checkins were all UnitTest 
(10:39:26 AM) gac410: So that one is no issue.
(10:41:01 AM) gac410: Actually it may have been a lot higher.     My initial queries had limit=700    but that was mabye because I didn't have the Engine ...  I don't recall now.
(10:42:06 AM) gac410: NewItems?class=Extension is down to 424 tasks.   That was indeed nearly 700.   
(10:43:05 AM) gac410: Another release task we are going to face.   We need a debian packager,  or we should drop the debian packages.   They are not getting maintained it appears.
(10:44:10 AM) gac410: 33 open tasks against DebianPackage
(10:44:44 AM) gac410: And since the RPM packages come from the same source,  they probably have the same issues.
(10:45:24 AM) gac410: Oh... I meant to mention.    TWiki is updating the license on all files.    Changing from GPLv2 to GPLv3  
(10:45:49 AM) gac410: Just made the checkin a few days ago, as part of updating all copyrights to 2014
(10:47:36 AM) gac410: I was looking at the GPL faq to see if they need permission/agreement from previous contributors to increment the minimum GPL version  but it doesn't appear so.
(10:48:44 AM) CDot: what's the difference?
(10:49:12 AM) gac410: I wonder how that impacts us when we take updates from them.   Ie,   I synced over SpreadSheetPlugin macros    (before their update).   I did it now,  would I need to update our license too?
(10:49:55 AM) gac410: http://www.ifross.org/en/what-difference-between-gplv2-and-gplv3
(10:50:38 AM) jast: depends on how exactly the license got applied to the source files
(10:50:49 AM) jast: actually, no, probably still needs agreement from all contributor
(10:51:11 AM) jast: at least that's my interpretation of the law which is not backed by any formal legal training :)
(10:51:50 AM) gac410: The GPL faq said that as long as the license says   "GPLv2 or any later version"   the you are free to bump.    And it does say that in the files.
(10:52:43 AM) jast: yeah, I'll go back to my first statement on that
(10:52:56 AM) gac410: ... as published by the Free Software Foundation; either version 2
(10:52:56 AM) gac410: of the License, or (at your option) any later version. For
(10:52:56 AM) gac410: more details read LICENSE in the root of this distribution.
(10:54:28 AM) CDot: welll.... lets see. GPL3 licenses copyrights and patents necessary to run the software. GPL2 does not. So a change from GPL2 to GPL3 is granting licenses to that material. I suspect that's not legal without the original copyright holder's permission. Since many of the twiki code modules carry explicit personal copyright notices, I assume the permission of those individuals has been sought and granted.
(10:54:31 AM) gac410: So that begs the question... should we change our licenses to "version 3 or any later version" ... which is what TWiki did.
(10:54:50 AM) CDot: No, I have not had any such request, though the number of modules with my explicit copyright is small.
(10:55:14 AM) jast: copyright reassignment isn't actually legally possible in various countries
(10:55:14 AM) gac410: Reading their release meetings,  they just went ahead and did it with very minimal discussion.  
(10:55:24 AM) ***CDot doesn't see the advantage of "version 3 or any later version" as against "version 2 or any later version"
(10:55:56 AM) jast: a matter of advocacy, maybe
(10:56:05 AM) gac410: I believe it also impacts embedded machines.  
(10:56:21 AM) CDot: it's *slightly* easier to integrate with non-GPL code too, which may be the motivation.
(10:56:27 AM) gac410: Not that we would be in there.  But the changes were triggered by the Tivo appliances.
(10:57:22 AM) gac410: So for Foswiki,   just ignore this,  or should we consider making the same change?    Pass it by the FoswikiAssociation?    
(10:58:06 AM) gac410: I think where the T* change impacts us the most is when we copy code back.   Doesn't happen very often.  Mainly spreadsheet plugin.
(10:58:19 AM) gac410: Oh.... and another new business...
(10:58:44 AM) jast: IMO there's no big benefit in bumping to v3, save for spreadsheet macros
(10:59:15 AM) jast: in that specific case maybe a clean room type approach could be used to avoid license violations
(10:59:52 AM) gac410: There is a partially comleted  PatternSkinTheme2012    which is FatWilly with the new logo.   Do we need to finish this off for 1.2 release for foswiki.org,  or are we going to just abandon FatWilly?
(11:00:37 AM) MichaelDaum: we should use standard PatternSkin plus menus
(11:00:43 AM) gac410: Jast,  For that one module,  just bumping the GPL for it would probably be acceptable.    I can't see value of clean room for stuff that is of limited value.
(11:01:13 AM) jast: in fact you don't even need to clean room
(11:01:15 AM) Lynnwood left the room (quit: Ping timeout: 264 seconds).
(11:01:22 AM) jast: just don't look at the code/diffs when adopting a new feature
(11:02:08 AM) Lynnwood_ entered the room.
(11:02:10 AM) gac410: Well the value of these functions is limited.  And IMO they won't get done at all if we have to re-invent. ... unless someone converting really needs them and is willing to pay.
(11:03:06 AM) gac410: So no more opinions.   No theme for Foswiki.org,   just fall back to default pattern skin?     Any reason why?   
(11:03:55 AM) MichaelDaum: support
(11:04:22 AM) MichaelDaum: if it is okay for a release then it should be fit for foswiki.org as well ... and vice versa
(11:04:39 AM) gac410: Without Arthur  we miss a lot of our pattern skin support. 
(11:05:55 AM) MichaelDaum: current PatternSkin default theme is better than FatWilly
(11:07:22 AM) MichaelDaum: within the realm of PatternSkin themes
(11:07:54 AM) gac410: okay.   The only think I'll miss is the menus across the top.   Or can we do that without fatwilly
(11:08:16 AM) MichaelDaum: yes I think so.
(11:09:52 AM) gac410: okay.   Thrashing the subject one more time.  Back to FastCGIEngine.    The release in August doesn't have your fixes in the Item branch made in December.  Should you re-release  to Testing before I apply to foswiki.org?
(11:10:28 AM) MichaelDaum: ya
(11:10:35 AM) gac410: And do you want to add a config flag to skip the LocalSite.cfg checking?
(11:10:42 AM) MichaelDaum: ya
(11:10:48 AM) gac410: okay I'll hold off. 
(11:11:58 AM) gac410: For fcgi bootstrap, we also need to survive the "missing LSC" case.
(11:13:08 AM) gac410: And probably update the documentation to recommend "service fcgi restart "  or whatever is needed ...after bootstrap is done.    My testing was done by running fcgi under my own user,  no services 
(11:13:57 AM) gac410: CDot:  MichaelDaum jast    Any more business, or should we wrap up the meeting and move any more discussion to #foswiki
(11:14:24 AM) gac410: uebera||:  Lynnwood_   same question :)   Sorry for omitting you
(11:14:29 AM) jast: nothing from me, I think
(11:14:47 AM) MichaelDaum: thanks gac410 and everybody else
(11:14:49 AM) CDot: nope
(11:14:56 AM) Lynnwood_: no just listening in (catching the tail end at least)
(11:15:36 AM) gac410: Everyone.... please focus on clearing backlog tasks.   If Waiting for Feedback and it has checkins,   really important to resolve.   I consider a "semi-completed" task a possible blocker.    Incomplete work has to be reviewed.
(11:15:39 AM) MichaelDaum: this meeting proves again that we really need them 
(11:15:49 AM) gac410: y.   I think we made really good progress.
(11:16:20 AM) MichaelDaum: there were some good discussions and brainstorming too ... besides the typical meeting reflexes
(11:16:21 AM) gac410: Next meeting    2 weeks?    The 26th.         That work okay?
(11:16:26 AM) CDot: y
(11:16:29 AM) MichaelDaum: y
(11:17:13 AM) gac410: I'll keep after gmc   trying to get weblate going.    I really would like to be able to say build an alpha on the 26th. 
(11:17:30 AM) MichaelDaum: kool
(11:17:32 AM) gac410: And I think it goes without saying     Once Weblate is running we are in String Freeze
(11:17:47 AM) gac410: And certainly no more "enhancements"    bugfix only.
(11:17:54 AM) gac410: :)
(11:18:15 AM) MichaelDaum: gac410, about your recent email to the mailing list ... let's make it a blog posting next time to improve the viral impact
(11:18:42 AM) gac410: If anyone has time,  another administrivia task that everyone can help with.    Look at Waiting for Release.     Is the Subject line something that would make sense in the release notes.
(11:19:01 AM) gac410: And is it really a bugfix or an enhancement.    
(11:19:04 AM) MichaelDaum: there are way more people listening to twitter and facebook than to our ml
(11:19:35 AM) gac410: Do you want to do a blog post  ... update my Dec email with some status from Today's meeting.  
(11:20:14 AM) gac410: This all doesn't have to come from just me.     It would be helpful if everyone would tweet, blog, etc.    I don't have a blog or a twitter account.   (Luddite here ;) )
(11:20:16 AM) MichaelDaum: I'd rather paste it in ... with some lowercase "foswiki" converted to uppercase "Foswiki"
(11:20:44 AM) gac410: Hm    I thought our official name was foswiki    lower case   
(11:21:13 AM) MichaelDaum: hehe
(11:21:34 AM) MichaelDaum: our logo is FOSWIKI
(11:21:47 AM) gac410: Yeah  that changed.   it used to be foswiki    I think    
(11:21:54 AM) jast: I always say Foswiki
(11:21:58 AM) MichaelDaum: for better typographics, Foswiki is best.
(11:22:54 AM) MichaelDaum: gac410, let's do it 2gether next time and I'll take over the blog part ... adding image material n stuff
(11:23:03 AM) gac410: Hm.   i went all the way back to Foswiki 1.0.9,  and logo is  uppercase.  
(11:23:30 AM) gac410: okay.   
(11:24:00 AM) gac410: I should have added something to the Foswiki news headlines on f.o homepage as well.
(11:24:06 AM) Lynnwood entered the room.
(11:24:07 AM) MichaelDaum: shall we retro-post your text even now?
(11:24:26 AM) gac410: I was thinking maybe we should.   
(11:24:35 AM) MichaelDaum: okay then lets do it
(11:24:38 AM) gac410: It's close enough to year end.  And any news is good news.
(11:24:58 AM) gac410: Or is that Any publicity is good publicity ... except for listing by Mitre
(11:25:02 AM) gac410: ;)
(11:25:10 AM) Lynnwood_ left the room (quit: Ping timeout: 255 seconds).
(11:25:38 AM) MichaelDaum: yea whatever beats the bush
(11:26:36 AM) ***MichaelDaum updating wordpress yadda
(11:27:23 AM) gac410: okay.      Hm.  Another controversial subject ... :D    Should we change the Blog link on Foswiki.org to point to Wordpress   ....  
(11:27:23 AM) ***gac410 hates it when we don't eat our own dogfood
(11:27:35 AM) gac410: Or just double post stuff 
(11:27:45 AM) gac410: One more page to be indexed.
(11:29:03 AM) MichaelDaum: you are asking the wrong person
(11:29:11 AM) gac410: :)
(11:29:22 AM) MichaelDaum: as nobody would like my answer in that respect 
(11:30:26 AM) gac410: Well the person who was working on the Blog web is gone,   so it' now is stale, unmaintained.      i'm not sure whether deleting it, (and causing 404's from search indexes)  is better than just limping along with what we have.
(11:49:18 AM) MichaelDaum: nother subsystem down the drain. blog.foswiki.org is out of business it seems
(11:50:48 AM) jast: viewing the blog works for me
(11:51:15 AM) jast: as does accessing the dashboard
(11:53:18 AM) Lynnwood left the room.
(11:53:24 AM) Lynnwood_ entered the room.
(11:53:44 AM) MichaelDaum: did it blacklist me?
(11:55:21 AM) jast: if it did, there's nothing about it in the UI
(11:56:35 AM) jast: btw there's an awful lot of spammy-looking users registered on wordpress
(11:58:04 AM) jast: well, I gotta go. have a good evening.
(12:05:14 PM) MichaelDaum left the room (quit: ).