Release Meeting: 17 Nov 2014

Details

1. Release of core extensions

Requested by Michael Daum: Discuss updates of extensions post 1.1.9

Discussed the changes Michael needs to JQueryPlugin. A number of other non-default extensions cannot be released due to the pending changes in JQuery. Most are backwards compatible, except for the jquery.rating. After some discussion, Michael will add a "newrating" function and will deprecate the old rating API. This will be backwards compatible.

2. Tasks review - New Issues

Debian packages

There was a bit of discussion about the recent issues with the .deb packages. They don't work on systems using Apache 2.4. We really need a maintainer for the .deb and .rpm with some time to spend. We might also need to consider where they are hosted. This is a bit of a wider problem as we continually have issues with stale installers. FreeBSD Port is at 1.1.5, and has no maintainer. OSX installer is out of date and now archived.

Store migration and PlainFile store

The review of Tasks.Item13078 turned into a deep discussion about Store migration issues between RCS and PlainFile store. Discussion about possible changing the default store from Rcs to PlainFile and the impact on migration. Currently the default store for 1.2 is PlainFile. This has consequences:

  • New sites with no old data: No issues, PlainFile is the preferred store.
  • Existing sites: We should default to an RCS store, convert_store.pl needs to be used to migrate to the PlainFile store if desired.

The problem comes about if a site installs a new test 1.2 system, and then later migrates webs into new installation. In this case, the default of PlainFile will be wrong, and could result in corrupted or lost history. This is being mitigated by several things.

  1. We need to document the heck out of this with lots of visibility in the download sites, release notes, migration guides, etc.
  2. The bootstrap process will search for existing ,rcs files and will auto-select the correct store only if the RCS data is present during configuration
  3. Configure will make the same checks and error the {Store}{Implementation} if conflicting history files are detected
  4. PlainFile store will die if a topic with rcs,v history is saved by PlainFile

Other tasks opened recently.

  • 13077 (Closed): Configure crash "Not a HASH reference at ConfigurePlugin.pm line 160"
  • 13078 (Closed): Core calls undocumented store method CDot will get to it. Started working on Store issues.
  • 13079 (Closed): Configure Bootstrap problems
  • 13080 (Closed): Configuration setting errors
  • 13082 (Closed): Cache fetch is case insensitive in MySQL, but topic names are case sensitive
  • 13084 (Closed): remove "Study Web Server"
  • 13085 (Closed): rework "show expert" feature
  • 13086 (Closed): convert the top-most tabpane layer to a left-side navigation
  • 13087 (Confirmed): Configure interface performs too many jsonrpc calls
  • 13088 (Proposal Required): have a "Save" button per section ... not one big "Save" for all changes wherever they occurred
  • 13089 (Closed): Simplify the UI of every node being rendered
  • 13090 (Confirmed): extensions tab needs to be rendered differently vs the rest of the tabs
  • 13091 (Confirmed): same error message being repeated multiple times
  • 13100 (Closed): bulk_copy.pl needs thorough review & testing for 1.2 Opened after meeting.

3. Tasks update - previously discussed.

Discussed today:

  • 12019 (Closed): AjaxAccessFixes JQuery fixes mixed in with some non-default extension work. MichaelDaum working on this, but unsure about the changes.
    • This is related also to consumption / reusability of strikeone tokens. Discussed as some depth.

  • 12477 (Closed): Spurious entries being added to .changes Spurious .changes entries. Some discussion, recordChange API is way overdesigned to support some store changes that were never implemented. Probably simplify the calls to the required information.

Tasks previously reviewed:

  • 10203 (Closed): Add inline form validation to registration form. Mostly complete, Needs help with completing ajax MichaelDaum and gac410 will test registration changes
  • 12261 (Closed): add developer section to PageCaching : rest requests, URL attributes to suppress caching Someone needs to update docs for the new PageCaching.
  • 12661 (Closed): Add support for recursive manifests in BuildContrib Add support for recursive manifests in BuildContrib
  • 12705 (Closed): Verbatim blocks are corrupted on save by Wysiwyg editor if $Foswiki::cfg{Site}{Locale} = 'utf-8'; (hotfix available)Need help on this. CDot's patch resolves the corruption but causes   to be lost.
    • This is still urgent and needs help from CrawfordCurrie if at all possible.
  • 12855 (Closed): Audit core DEPENDENCIES This can be closed any time. Left open to remind that we should do a final audit before building release.
  • 12925 (Closed): Unit tests needed for Foswiki PageCache Page cache unit tests were all disabled in rewrite. StephanOsthold offered to help but has limited time over next few weeks.
  • 12926 (Closed): Subscribe links on top and bottom bar fail with validation errors Subscribe links are broken. GeorgeClark will change SubscribePlugin rest handler to permit GET urls.
    • Some issues were encountered. MichaelDaum had some suggestions, George will revisit.
  • 12958 (Closed): HTML in a label can break the editor HTML label issue with editor. CrawfordCurrie proposed a patch. Can we apply this? Does it need unit tests.
  • 13028 (Closed): Implement RemoveTaintCheckingFromFoswiki Implement Development.RemoveTaintCheckingFromFoswiki
  • 12973 (No Action Required): can't set cell type from "body" to "header" (I think that this is a bug in TinyMCE editor, and a limitation of TML)
  • 12987 (Closed): Foswiki returns "detected an internal error" with code 200, not 500 (Partially fixed. I think there is a bug remaining that will cause secondary crash after 500 rc.)
  • 13040 (Closed): Foswiki 1.2 issues on Nginx New configure and bootstrap on Nginx with fcgid

4: Next meeting - - Monday December 1st, 1300Z

IRC Log

 
  Conversation with #foswiki-release at Mon 17 Nov 2014 07:58:53 AM EST on gac410@chat.freenode.net (irc)

   (08:03:18 AM) ModAcOst
   (08:05:50 AM) gac410: g'morning all
   (08:06:14 AM) JulianLevens: Afternoon :)
   (08:07:08 AM) gac410: Shall we get started, or wait a few more minutes?
   (08:09:34 AM) JulianLevens: Well thatʼs two minutes gone, I suggest we start now
   (08:11:00 AM) gac410: Okay. 10 past the hour. Lets start. First on the agenda Michael Daum asked that we discuss release of updated default extensions for 1.1.9 Michael are you ready?
   (08:11:02 AM) gac410: http://foswiki.org/Development/ReleaseMeeting01x02_20141117
   (08:11:27 AM) MichaelDaum: hey there
   (08:11:38 AM) gac410: good day
   (08:11:51 AM) MichaelDaum: sorry for the delay. was heads down on fixing some annoying bugs
   (08:12:47 AM) MichaelDaum: okay. yes. there are some plugins that I have already parked in the Extensions/Testing web that I actually would like to release in the public Extensions web.
   (08:13:17 AM) gac410: JQuery ?
   (08:13:18 AM) MichaelDaum: This is mostly related to JQueryPlugin deprecating the old jquery.tmpl rendering package.
   (08:13:44 AM) gac410: Is it backwards compatible? ie can sites using jquery.tmpl still function okay?
   (08:13:58 AM) MichaelDaum: As quite a few plugins needed to be fixed moving to jsrender, those are on hold as well as long as JQueryPlugin isnʼt out yet.
   (08:14:18 AM) jast entered the room.
   (08:14:25 AM) MichaelDaum: yes, we still ship jquery.tmpl as well as the new jsrender library part of JQueryPlugin.
   (08:15:44 AM) MichaelDaum: releasing JQueryPlugin properly now lets me release the following plugins as well ... which would otherwise be blocked:
   (08:15:54 AM) gac410: We definitely bug-fix other extensions between releases. Certainly Wysiwyg has had intrim releases
   (08:16:13 AM) MichaelDaum: NatEditPlugin, ListyPlugin, SolrPlugin, HarvestPlugin, CaptchaPlugin, BlogPlugin
   (08:16:45 AM) MichaelDaum: there are some more changes in JQueryPlugin not yet checked in that are required for the upcoming AngularPlugin/Skin
   (08:16:58 AM) gac410: I don't have objections unless it somehow broke existing 1.1.9 sites
   (08:17:10 AM) MichaelDaum: okay thanks
   (08:17:18 AM) gac410: anyone else?
   (08:18:07 AM) MichaelDaum: with regards to JQueryPlugin
   (08:18:47 AM) MichaelDaum: we still ship some very old jquery-x.x.x releases with it that are incompatible with jquery-ui at a certain point. some other modules require newer jquery-x.x.xes as well
   (08:19:42 AM) MichaelDaum: not too urgent but we might need a way to make sure upgrades work out fine
   (08:20:17 AM) gac410: We could add a checker, but for sites using debian packages, they might not get run.
   (08:20:31 AM) MichaelDaum: for instance this affects people upgrading from very old JQueryPluginʼs comming with jquery-1.3.x or so. So the LocalSite.cfg needs a warning in that case.
   (08:21:43 AM) gac410: And probably a hightlighted note in the extensions topic. and maybe in the compatibility note of the extension form.
   (08:23:40 AM) MichaelDaum: I have a few more changes to JQueryPlugin that Iʼd like to release as well:
   (08:24:04 AM) MichaelDaum: (1) add mousewheel support (https://github.com/jquery/jquery-mousewheel)
   (08:24:28 AM) MichaelDaum: (2) add sprintf 4 javascript (https://github.com/alexei/sprintf.js)
   (08:25:36 AM) MichaelDaum: (3) rewrite jquery.rating library ... as the current one is creating too much markup when using half-star rating
   (08:26:35 AM) MichaelDaum: about (3) this will be backwards compatible with regards to the rating formfield but probably miss a few javacript api interfaces in the third party library that are not used by our formfield impl
   (08:27:12 AM) gac410: Are you planning that for an intrim release or just 1.2 versin
   (08:27:21 AM) MichaelDaum: for the interim release
   (08:27:47 AM) MichaelDaum: this all piles up too long in WaintingForRelease state
   (08:28:01 AM) MichaelDaum: as 1.2.0 is still not ante portas
   (08:28:28 AM) gac410: So 3) would be incompatible with possible custom site javascript code, but not with what we release.
   (08:28:35 AM) MichaelDaum: right
   (08:29:15 AM) gac410: Any way to reasonably hold that one for 1.2, and include a warning in the interim release just to make it a bit smoother?
   (08:29:16 AM) MichaelDaum: the currently shipped rating library is from http://www.fyneworks.com/jquery/star-rating/
   (08:30:30 AM) MichaelDaum: apiʼs not implʼed by my current jquery.nurating.js: $().rating(ʼselectʼ, index / value), $().rating(ʼreadOnlyʼ, true / false), $().rating(ʼdisableʼ) / $().rating(ʼenableʼ) as well as callbacks
   (08:31:30 AM) MichaelDaum: the other option is to ship both jquery.rating (the third-party one) as well as jquery.nurating.js ... which our rating formfield will be based on
   (08:31:44 AM) MichaelDaum: and then properly deprecate jquery.rating
   (08:32:09 AM) gac410: That might be better ... I hate to see us breaking existing code although at times it'd unavoidable.
   (08:32:11 AM) CDot [~crawford@foswiki/developer/cdot] entered the room.
   (08:32:29 AM) MichaelDaum: okay will do that (deprecation process)
   (08:33:36 AM) gac410: Great thanks. CDot ... welcome. We were just discussing Michael is proposing releasing an updated JQueryPlugin ahead of 1.2.
   (08:33:55 AM) CDot: ok, that should be fine
   (08:35:12 AM) gac410: While on the subject of extension releases, are there any other default extensions that we should consider interim releases for? Otherwise next on agenda is task review.
   (08:35:44 AM) MichaelDaum: NatEditPlugin
   (08:35:44 AM) CDot: only in dire emergency. I thought about it for WysiwygPlugin.... for about 0.0000001s
   (08:36:02 AM) MichaelDaum: and proably FastCGIEngineContrib
   (08:36:29 AM) gac410: yeah that was the one (Wysiwgy) I thought of as well.
   (08:36:45 AM) gac410: FastCGI is not a default extension, so you could releaes that anytimte
   (08:36:57 AM) gac410: yeesh I cant spell this morning.
   (08:37:10 AM) MichaelDaum: ah ok. wasnʼt sure what the state of affairs are on making it a default extension...
   (08:37:36 AM) gac410: I think we should make it defauit in 1.2 but until then it's fair game :)
   (08:38:23 AM) MichaelDaum: FastCGIEngineContrib needs a bit more shared brain with regards to stability under nginx ... or merely when running Foswiki stand-alone under FCGI::ProcManager control
   (08:38:51 AM) gac410: I think the project also needs to consider what to do about the .deb pkgs. Unless we find a maintainer, they are going to have trouble. Not compatible with latest apache :(
   (08:39:53 AM) gac410: Or get Sven to work on them. The debian pkg related tasks are building up.
   (08:39:54 AM) MichaelDaum: needs a new volunteer to take over leadership for the deb repo
   (08:40:27 AM) CDot: yup. Preferably someone who uses it, so they are motivated to keep following up.
   (08:40:50 AM) MichaelDaum: jast, do you run debian repos at Modell-Aachen?
   (08:40:56 AM) gac410: Sometimes I also wonder about adding a help wanted notice on sourceforge.
   (08:41:20 AM) CDot: pretty sure m-a donʼt use the debs
   (08:41:32 AM) CDot: gac410: good idea
   (08:41:56 AM) gac410: Maybe we should delegate that to the Foswiki board
   (08:42:10 AM) MichaelDaum: ... which delegates it further down the road?
   (08:43:18 AM) CDot: delegating to the board is not appropriate, itʼs not the project administration. Just do it.
   (08:43:31 AM) gac410: yeah. it's just if the "Project" is going to go public with a request for help, we should probably wordsimth that a bit. ... another thought is to add a "Debian maintainer wanted" to the foswiki.org
   (08:44:05 AM) gac410: okay. well anyway this is going off track from the release meeting.
   (08:44:20 AM) MichaelDaum: what the board can do is to ratify a DebianTaskTeamʼs agenda
   (08:44:54 AM) MichaelDaum: and perk its members
   (08:45:03 AM) gac410: Yeah. And we need to reform a DebianTaskTeam (Though sven also does the .rpm pkgs. So maybe a Packaging task team ?)
   (08:45:15 AM) MichaelDaum: +1
   (08:45:43 AM) MichaelDaum: hosting the repo should be of concern as well
   (08:45:47 AM) jast: MichaelDaum: nope
   (08:46:01 AM) MichaelDaum: jast, rpm repos?
   (08:46:07 AM) jast: no packages of any kind
   (08:46:20 AM) gac410: Our freebsd port is also badly out of date. Same with OSX packages. Should probably be removed .. This is treading on embarrassing to the project.
   (08:46:22 AM) jast: maybe in the far future
   (08:46:57 AM) CDot: There is no point in pushing out packages that donʼt work, or are so far out of date as to be useless.
   (08:47:38 AM) gac410: The attrition over the past year or so is quite painful. That's why I mentioned the board. Somehow we need to get some more maintainers, or those of us left are going to burn out.
   (08:48:23 AM) CDot: agreed.
   (08:49:16 AM) gac410: On the good news side, we do seem to be attracting migrations and new installations. There have been several over the past weeks popping up asking for help.
   (08:49:54 AM) gac410: Time check. Task review?
   (08:50:14 AM) CDot: k
   (08:50:44 AM) gac410: I listed all the new core related tasks in http://foswiki.org/Development/ReleaseMeeting01x02_20141117 Many are Configure releated. We need to triage them.
   (08:51:39 AM) gac410: MichaelDaum: Most are yours from the last meeting. I suspect most should be "normals" and not blockers.
   (08:52:45 AM) ***MichaelDaum clicks to review them
   (08:52:56 AM) gac410: CDot Maybe not here, but I need to talk to you about http://foswiki.org/Tasks/Item13078 PlainFile is missing a function and the "manage" link for attachments crashes
   (08:53:29 AM) CDot: y, I know. Iʼm working on stores at the moment, but havenʼt fixed that specific issue.
   (08:53:30 AM) gac410: I was looking at implementing, but I don't understand it, and the first thing the RCS version does is pass it back to a Meta call. So Meta -> Store -> Meta
   (08:53:38 AM) gac410: okay.
   (08:53:48 AM) CDot: Trying to untangle the store mixins that Sven did at the moment
   (08:54:27 AM) ***MichaelDaum has been creeping around http://foswiki.org/Tasks/Item12019 for too long unsure what to make out of those changes ... or understand which code actually makes use of the added features
   (08:54:33 AM) gac410: :) Yeah. I was also trying to fix the .changes mess. I keep getting tangled up in it.
   (08:54:37 AM) CDot: RCS is a plate of spaghetti, because I never was able to fully decouple it from the core
   (08:55:12 AM) CDot: Meta should know *nothing* of .changes, itʼs all behind the Store.pm interface
   (08:55:31 AM) CDot: big, big error if it *does* know about it
   (08:55:39 AM) gac410: Yeah. Sorry I changed subjects. they are NOT tangled
   (08:56:19 AM) gac410: It's the getAttachmentVersionInfo that tangles meta & store.
   (08:56:53 AM) CDot: MichaelDaum: 12019 - good point about the key reuse
   (08:57:19 AM) gac410: recordChange is messy because it is passed _meta, oldMeta and newMeta 3 meta objects, apparently used inconsistently if at all.
   (08:57:22 AM) CDot: I *did* think about passing over a "spare" key in <meta, but......
   (08:57:52 AM) CDot: yes, recordChange needs refactoring, badly. AFAICT there&#700;s no robust reason for it to receive $meta
   (08:58:06 AM) CDot: however, low down (my) todo list
   (08:58:46 AM) CDot: BTW it got meta because at one point we thought we might use it for store extensions (an idea since abandoned)
   (08:58:51 AM) MichaelDaum: CDot, I also wondered in how far a js api to save that fetches new tokens if needed (see the extra ajax call to do so) would make things too easy wrt security
   (08:59:00 AM) gac410: Okay good. I was going to tackle it becuase it breaks mailNotify as written.
   (08:59:52 AM) CDot: MichaelDaum: yes, it would. If you hand out tokens blindly, then you circumvent s1 completely
   (09:00:26 AM) CDot: new tokens should only be emitted in response to a well-structured, predictable request
   (09:00:34 AM) CDot: such as a form post
   (09:00:52 AM) MichaelDaum: right. and that&#700;s what the current code does: if no spare token of another form could be found, it requests one using a separate ajax call.
   (09:01:29 AM) gac410: CDot and my PlainFile change to "die" if rcs,v files are found for the "currently saved" topic breaks the unit tests. Tests "switch store" on the fly, so the users get registered using both stores, and
   WikiUsers save dies when the store switches.
   (09:01:30 AM) CDot: hmmmm. How is that ajax call validated?
   (09:01:48 AM) CDot: gac410: I noticed. :-)
   (09:01:52 AM) MichaelDaum: actually the call to foswiki.post () should provide a token as part of the api call.
   (09:02:17 AM) CDot: gac410: $Foswiki::inUnitTestMode (which I dislike but someone added) may be your friend
   (09:02:52 AM) gac410: Ah cool thanks. Didn't know about that. That makes it easy.
   (09:03:52 AM) JulianLevens: What unit tests need to switch stores?
   (09:04:00 AM) gac410: The StoreTests :)
   (09:04:15 AM) JulianLevens: Thanks ;)
   (09:05:22 AM) gac410: CDot I figured out the nightly test crashes.
   (09:05:42 AM) CDot: well done!
   (09:05:43 AM) JulianLevens: Why not put PlainFile data in a directory called pfdata?
   (09:05:45 AM) gac410: pseudo_install copies $TRUE / $FALSE into the LocalSite.cfg And they then cause the crahs.
   (09:05:48 AM) MichaelDaum: gawd, foswiki.post() even depends on PatternSkin
   (09:05:56 AM) CDot: JulianLevens: it *does*
   (09:06:19 AM) CDot: aha
   (09:06:54 AM) CDot: during the unit test, the store is burned down and rebuilt for each unit test
   (09:07:08 AM) CDot: well, the webs used in the test, anyway
   (09:07:59 AM) JulianLevens: If PlainFile stores as standard in pfdata and RCS stays in data, do we really need to test for rcs,v files?
   (09:07:59 AM) gac410: The problem is that the initial test setup uses the LocalSite.cfg defined store, and then the unit test takes control, siwtches store, and tries to register another usxer.
   (09:08:28 AM) CDot: JulianLevens: fair point
   (09:08:46 AM) gac410: Yes. When saving any ONE topic, if that topic has rcs,v files existing, then that says the store was not migrated and the user is starting a new history with that change.
   (09:08:53 AM) CDot: after all, other stores don&#700;t use the data directory
   (09:09:05 AM) CDot: so why should PF
   (09:09:45 AM) gac410: But but..... the underlyin issue is still there. An rcs,v file exists with history that has not been migrated. So a save causes DAMAGE
   (09:10:17 AM) CDot: yeah. The problem with not using data is that the *distribtuion* ships all topics in - yes you guessed it - data
   (09:10:32 AM) CDot: so unless you ware going to duplicate in pfdata, it&#700;s not going to work
   (09:11:00 AM) jast: well, if you switch to PFS (which stores everything in pfdata) and haven&#700;t migrated yet, there are no topics
   (09:11:04 AM) jast: that should be pretty safe ;)
   (09:11:05 AM) gac410: The distribution though does not ship ANY history. So the presence of history of another format says the user has switched stores.
   (09:11:21 AM) CDot: right
   (09:11:47 AM) gac410: adding pfdata is another directory which needs protection in apache configuration. Adding a directory is trouble I suspect
   (09:11:50 AM) CDot: basically what george is saying is that once you use RCS, you are stuck with it until you explicitly migrate
   (09:12:05 AM) CDot: he is just trying to add the checks to make that safe
   (09:12:19 AM) JulianLevens: I am perturbed, in general, by the idea that Stores share space
   (09:12:28 AM) CDot: they do *not* share space
   (09:12:41 AM) jast: if the .txt files are taken from the same place, they do
   (09:12:44 AM) JulianLevens: No the release does
   (09:12:50 AM) CDot: the &#700;data&#700; dir is - at any given time - either a PF store *or* a RCS store - never both
   (09:13:06 AM) CDot: (sorry, or a "could be either" store)
   (09:13:21 AM) JulianLevens: And the check is to make sure that &#700;data&#700; is clean
   (09:13:31 AM) JulianLevens: One or the other
   (09:13:37 AM) CDot: yes, there is a basic problem with DB stores. The installation process has to include populating the DB from data
   (09:14:11 AM) gac410: We release a "Store agnostic" data. No ,rcs no ,pfv present. So until you make your first save, there is no confilct. Heisenburg uncertanty The poor cat is both dead and alive.
   (09:14:19 AM) CDot: so if you think about RCS and PF as having a "database", they should not be crapping on the distribution topics
   (09:14:48 AM) JulianLevens: y, I started writing a StoreToolsContrib to address that. Includes a better copy_store amongst others
   (09:15:03 AM) JulianLevens: Also need a upgrade_store facility
   (09:15:45 AM) JulianLevens: To pick up changed topics in a release and load to the Store (DB stores will need this)
   (09:16:09 AM) gac410: The checks I added. are 1) In bootstrap, test if store has already been determined and choose a correct default
   (09:16:09 AM) gac410: 2) In the configure checker, scan the whole store looking for conflicting history. And report an error if multiple active stores are detected in history
   (09:16:09 AM) gac410: 3) In PlainFile store, if a ,v file is detected when saving a topic, die. to prevent loss of history.
   (09:16:11 AM) CDot: by rights, if we do this properly, then =data= needs to stay agnostic - for ever. RCS should use rcsdata and pf use pf data
   (09:16:26 AM) CDot: if we do that, there is no conflict
   (09:17:10 AM) gac410: There is STILL A CONFLICT! If you have V1, V2 V3 in RCS, and then save in PlainFile, even in a new location, you start over with V1 ..
   (09:17:25 AM) CDot: no, because PF only saves in pfdata, never in rcsdata
   (09:17:40 AM) CDot: and that is a *different* DB
   (09:17:53 AM) CDot: unless you copy from the RCS store to the PF store first
   (09:18:06 AM) JulianLevens: Yes and that would be really broken
   (09:18:24 AM) gac410: Ah.... So when you switch stores you have NO topics until you migrate. okay yes that would be safe.
   (09:18:36 AM) CDot: JulianLevens: why?
   (09:18:50 AM) JulianLevens: I mean broken admin behaviour
   (09:18:59 AM) CDot: ?
   (09:19:05 AM) jast: gac410: yeah, that would be my preferred approach, though hard to pull off without having each store take its .txt equivalent from a different place
   (09:19:35 AM) CDot: jast: that has to happen. DB&#700;s don&#700;t *have* a .txt equivalent
   (09:19:44 AM) jast: which in turn creates a need for &#700;populate during install&#700; even for the default store
   (09:19:55 AM) JulianLevens: CDot: why would an admin copy from rcsdata to pfdata?
   (09:19:58 AM) CDot: yes, that&#700;s the one major problem with the idea
   (09:20:06 AM) jast: JulianLevens: I believe he meant "copy" not very literally
   (09:20:06 AM) CDot: JulianLevens: using copy_store.pl
   (09:20:14 AM) CDot: right
   (09:20:44 AM) CDot: I *guess* a configure wizard *could* seed the store from /data
   (09:21:02 AM) jast: conceptually, populating during install and migrate seems like the cleanest solution
   (09:21:23 AM) CDot: bootstrap can set the store read-only until an implementation is committed
   (09:21:23 AM) gac410: A change from data to rcsdata / pfdata will make parallel execution really painful.
   (09:21:33 AM) CDot: so you can still browse the doc, straing from /data
   (09:21:40 AM) jast: in fact that would make populate-during-intsall a special case of migration, from BootstrapContentPseudoStore to OurFancyDefaultStore :)
   (09:21:59 AM) CDot: a change away from data will make all 3rd party scripts break
   (09:22:27 AM) JulianLevens: We need populate-during-install anyway for bug fix releases
   (09:22:29 AM) gac410: And mean every existing apache (et. al.) config has to change, and/or potentially be vulnerable.
   (09:22:42 AM) CDot: gac410: ? Why ?
   (09:22:57 AM) jast: data could remain the place for Rcs*, only then you&#700;d have to put the bootstrap content into a different place
   (09:23:12 AM) gac410: If we add a new directory at root level, it needs a <Directory> entry in config, and/or another .htaccess file.
   (09:23:14 AM) jast: with all of this, another problem is that !noci in extensions becomes tricky
   (09:23:15 AM) CDot: ah, gac410, sorry, icwym - /pub/
   (09:23:36 AM) gac410: Oh yeah that too. I forgot about pub :)
   (09:23:56 AM) jast: default to viewfile, Problem Solved (tm) :}
   (09:24:11 AM) gac410: :P
   (09:24:58 AM) CDot: ok, let&#700;s say &#700;data&#700; and &#700;pub&#700; are left as RCS&#700;s dirty area. We move all the current data/pub content into /stores/agnostic/data /stores/agnostic/pub
   (09:25:05 AM) CDot: (names to be debated later)
   (09:25:18 AM) MichaelDaum: viewfile reads all of a binary into memory, then copies it over to the http server which keeps it in memory as well as long as the client didn&#700;t fully receive it...bloating resources quite some for big
   attachments
   (09:25:20 AM) CDot: then bottstrap uses /agnositc to get it&#700;s data
   (09:25:23 AM) gac410: Extension installer certainly becomes more complex. And Install with "unzip" becomes impossible.
   (09:25:41 AM) CDot: install with unzip unpacks to the agnostic store
   (09:25:53 AM) JulianLevens: Install with unzip with DB stores does not work in general
   (09:26:00 AM) CDot: yes
   (09:26:12 AM) gac410: Which is "data" or we repackage every existing zipfile out there.
   (09:26:30 AM) CDot: gac410: can&#700;t have our cake *and* eat it
   (09:26:39 AM) jast: good prompt...
   (09:26:42 AM) gac410: :P
   (09:26:44 AM) CDot: data is either agnostic, or it&#700;s RCS&#700;s toilet. Can&#700;t be both.
   (09:26:45 AM) ***jast fetches cake from fridge
   (09:27:11 AM) JulianLevens: I&#700;m fasting today you swine
   (09:27:27 AM) gac410: And even extensionInstaller with !noci copies into data just like unzip. So DB based stores is going to be incompatle with extensions installer.
   (09:27:30 AM) CDot: JulianLevens: chocolate chip cookies.
   (09:27:39 AM) CDot: JulianLevens: bacon!
   (09:28:16 AM) MichaelDaum: another idea for custom stores is to always be able to (re-) bootstrap it from data+pub
   (09:28:33 AM) CDot: gac410: I&#700;m hearing lots of objections..... hoping for some constructive ideas
   (09:29:10 AM) CDot: MichaelDaum: yes, that would be possible. data *could* be the agnostic store *and* the RCS play area
   (09:29:18 AM) MichaelDaum: ya
   (09:29:23 AM) gac410: I'm not objecting, I'm listing stuff that needs to be addressed. ext. installer DOES copy into data.
   (09:29:39 AM) MichaelDaum: so it depends on the kind of added value a custom store comes with
   (09:29:44 AM) CDot: yes
   (09:30:08 AM) MichaelDaum: for instance, is it (a) accessing amazon or google drive or (b) just there to speed up search
   (09:30:11 AM) CDot: I think the pressure is on to revert to RcsLite as the default store impl
   (09:30:36 AM) gac410: Well that just defers the issue. The problem still exists.
   (09:30:57 AM) MichaelDaum: RcsLite really is not an option for production systems
   (09:31:15 AM) CDot: the biggest problem I have with the "agnostic+rcs" idea is, what happens when there&#700;s a ,v file for a topic that is supposed to be a release topic?
   (09:31:25 AM) gac410: It MUST be an option, or mod_perl is not really usable.
   (09:31:29 AM) CDot: RcsLite/Wrap/whatever
   (09:31:37 AM) MichaelDaum: gac410, why?
   (09:31:54 AM) gac410: CDot: There was only one topic in the release with a ,v file. I removed it from the manifest and update CompareRevisionsAddOn
   (09:32:14 AM) MichaelDaum: using RcsWrap on mod_perl or FastCGI is way better than suffering from the problems RcsLite has got
   (09:32:19 AM) gac410: MichaelDaum: fork under mod_perl forks the whole apache server.
   (09:32:52 AM) MichaelDaum: that&#700;s a problem for any plugin that calls anything external ... using mod_perl
   (09:32:55 AM) gac410: For any site not using big binaries, RcsLite is fine isn't it?
   (09:33:15 AM) jast: or insanely big histories
   (09:33:24 AM) MichaelDaum: ^^ was going to say
   (09:33:48 AM) MichaelDaum: with version>=100 as of being "insane"
   (09:34:05 AM) MichaelDaum: problem stems from the same design issue in RcsLite
   (09:34:12 AM) CDot: hang on a mo, we&#700;re not talking about forcing existing large sites to use Rcs in any form
   (09:34:24 AM) CDot: we&#700;re talking about the out of the box, fresh install
   (09:34:31 AM) CDot: and not breaking anyone else
   (09:34:59 AM) CDot: we want to offer PFS (and DBIStorem and Mungo) as options
   (09:35:14 AM) MichaelDaum: right. but why is PFS not considered default anymore?
   (09:35:18 AM) CDot: and in that case it&#700;s acceptable to require a migration step
   (09:35:45 AM) JulianLevens: Yes, that&#700;s cleaner
   (09:35:48 AM) gac410: Right. As 1.2 stands right now, OOB is PlainFile. And it is safe. The issue comes if someone migrates data/pub AFTER the initial install. That's what the checker and "save check" attempt to address.
   (09:36:27 AM) CDot: "migrates", or simply changes {Store}{Implementation}?
   (09:36:37 AM) jast: simply changes
   (09:36:37 AM) gac410: So I don't have any major concerns with out of box, PlainFile default.
   (09:37:03 AM) jast: were there any concerns about the save check? ISTR hearing something like that
   (09:37:11 AM) CDot: gac410: describe again thae specific upgrade-path use cae you described to me on #foswiki
   (09:37:37 AM) gac410: User installs 1.2. new install. ( That was our recommended upgrade for 1.0 -> 1.1)
   (09:37:46 AM) gac410: User configures and does sanity checks.
   (09:38:10 AM) gac410: User then copies "user data" webs Main, Sandbox, And all non-system webs .... from 1.1. to 1.2
   (09:38:41 AM) MichaelDaum: ... which would require another call of ./tools/do_store_migration.pl
   (09:38:43 AM) gac410: So that last step then pollutes an happy PlainFile installation with RCS data.
   (09:39:49 AM) JulianLevens: If we RCS OOB that that&#700;s not an issue; user must explicitly convert these RCS store to PF
   (09:40:29 AM) gac410: Right. The issue with that specific migration process, is the default of PFS. But tbh, for new installs, PFS is **clearly** preferred.
   (09:40:35 AM) jast: just tell people to install with RCS when setting up 1.2 to migrate from 1.1?
   (09:40:49 AM) jast: and then switch when they&#700;ve copied everything
   (09:41:34 AM) JulianLevens: Alternatively use copy_store pointing to existing RCS store as long as dest is a different store
   (09:41:37 AM) gac410: Right. I'm reasonably happy with what we have now. We *attempt* to guess the correct store, check it in configure, and then die if we still got it wrong.
   (09:42:13 AM) gac410: And of course we'll release note the heck out of is and add it to our download topics.
   (09:42:57 AM) gac410: .deb pkgs still need to deal with it, but that's the .deb maintainer's issue :P
   (09:43:08 AM) CDot: ok, so actually this problem goes away - so long as everyone understands it :-)
   (09:43:36 AM) ***CDot still likes the idea of keeping the release data "untainted" by RCS
   (09:43:57 AM) gac410: Yes. The problem we "defer" is what about non-traditional stores. It IS untainted. We ship no RCS file. There was one, and I removed it.
   (09:44:32 AM) gac410: And the extensino installer can't handle installing them So no extension unless installed with unzip, should pollute the store.
   (09:46:39 AM) JulianLevens: I think this is important; but I need to sleep on it
   (09:46:49 AM) CDot: !noci is a default
   (09:46:56 AM) CDot: should be a default
   (09:47:30 AM) CDot: ok, I kinda have my head around it now. That store migration script has become very important.
   (09:48:06 AM) CDot: for one thing, it has to remove all traces of RCS when it migrates to PFS (and vice-versa)
   (09:48:10 AM) gac410: So for 1.2, *File based stores are fine. Aw S*** Okay one small issue. !noci is overridden if the file exists with history. So installer copies the file and overlays the existing, unless the existing file has
   history, Then it forces a checkin.
   (09:48:19 AM) gac410: CDot: yes.
   (09:48:19 AM) ***CDot considers that to be a BIG release blocker
   (09:48:48 AM) gac410: I don't remember how the _installer detects history.
   (09:48:56 AM) CDot: badly. It looks for ,v
   (09:49:08 AM) gac410: That's what I was afraid of.
   (09:49:54 AM) gac410: So it needs to look for ,v or ,pfv. The reason not to use the API is for contribs like FamFamFam with 1000's of files. Install runs forever and times out the web server.
   (09:50:16 AM) CDot: y
   (09:51:09 AM) gac410: The non text file based stores (ie not shadow stores, but a real database store) I think have to be at least a 2.0 consideration. Sorry JulianLevens
   (09:51:55 AM) gac410: There is way too much dependency on existing .txt files.
   (09:53:19 AM) CDot: where?
   (09:53:26 AM) gac410: Okay. we are approaching two hours. I think we've covered only a few tasks, I reviewed what I needed to do with CDot.
   (09:53:28 AM) JulianLevens: That&#700;s ok; I just wanted to be sure we mange the transition from RCS as your only choice to WhateverStoreYouFancyContrib
   (09:53:30 AM) ***CDot has tried hard to eliminate all those dependencies
   (09:54:01 AM) ***CDot has DBIStore almost ready to roll - not a shadow store, a full DBI-based store implementation
   (09:54:07 AM) gac410: Existing extensions, Install insturctions (unzip into ...) Lots of user code writing to .txt files ...
   (09:54:13 AM) CDot: it would be a crying shame not to support it in 1.2
   (09:54:52 AM) gac410: We can support it recognizing that you can't install extensinos, Existing sites .txt file manipulations are an issue, ...
   (09:55:25 AM) JulianLevens: It should be supported but they will be extensions with special install instructions
   (09:55:28 AM) gac410: And any extension that touches {DataDir} or {PubDir} are in trouble.
   (09:56:03 AM) gac410: Given that every extension that used our boilerplate says " To install, unzip into your foswiki root directory " is in trouble
   (09:57:02 AM) gac410: And even Configure::Package with (!noci) assumes you just copy into {DataDir} and {PubDir}
   (09:57:05 AM) JulianLevens: StoreTools are needed to support &#700;importing&#700; stuff from data/pub not merely copying
   (09:57:18 AM) CDot: true, all true
   (09:57:42 AM) CDot: ok, so maybe DBI stores are a bridge too far. Still got to get the core support right for them, though.
   (09:58:53 AM) gac410: Yes. There is a difference in "Support" meaning it works for lunatic fringe, vs "Support" meaning all of our surrounding tools happily work without modificatinos.
   (09:59:04 AM) JulianLevens: These can be completed post 1.2 as extensions, n&#700;est pas?
   (09:59:49 AM) gac410: Hm... Configure::Package is pretty dependent upon the data/ pub/ structures. Extension can't do much with that.
   (10:01:17 AM) JulianLevens: Yes, post install of another extension. Site using AnotherStore will need to run a utility to import these topics - the price a site will need to pay to use a better Store
   (10:01:39 AM) gac410: I suspect we would need a thorough review of *any* direct file access in core and the "popular" extensions. But "core" defined as "Foswiki.pm" should all work with non-file based store.
   (10:02:15 AM) gac410: I know I've never heistated to use ( -e somefile ) ... (-d some/dir )
   (10:02:34 AM) gac410: For a db store to be fully supported we need to find / kill everyone of those
   (10:03:12 AM) gac410: well every one that uses data/pub
   (10:03:24 AM) ***CDot did that when he encapsulated the store. However it may have rotted since then :-(
   (10:03:57 AM) gac410: I suspect it's more extensions ... and configure ... where that will have rotted.
   (10:04:31 AM) CDot: configure is well behaved - most of the time.
   (10:04:45 AM) CDot: though you are right, there may well be inherent problems.
   (10:04:58 AM) CDot: ok, running late, gotta go
   (10:04:59 AM) gac410: Anyway. 2 hour mark. Shall we close the meeting. I don't think we should do a task/by/task review.
   (10:05:00 AM) MichaelDaum: when moving away from /pub we have to consider all use cases of /pub ... and how files in there are required by the user session
   (10:05:12 AM) MichaelDaum: note /pub is not only attachments
   (10:05:19 AM) gac410: User session? really?
   (10:05:35 AM) MichaelDaum: it is css, js, thumbnails, ... stuff like that
   (10:05:36 AM) CDot: yes, it&#700;s JS etc as well
   (10:05:54 AM) CDot: all of which *could* be attachments - at a high cost (when using viewfile)
   (10:06:00 AM) MichaelDaum: exactly, and this stuff has to be accessible to the http server without anything in between
   (10:06:01 AM) JulianLevens: CDot does DBIStore use pub for attachments still?
   (10:06:03 AM) gac410: Ah... but that's all attachments isn't it. Ah..no... answering my own questino. Sometimes subdirs of attachment dirs.
   (10:06:33 AM) MichaelDaum: consider xsendfile for example
   (10:06:46 AM) MichaelDaum: which is a high-performance replacement for viewfile use cases
   (10:06:55 AM) CDot: JulianLevens: depends. The DBIStore plugin, which shadows the main DB, does. The pure DBI Store does not (it uses viewfile and stores the attachments in the DB)
   (10:07:20 AM) MichaelDaum: outch
   (10:07:22 AM) CDot: or rather, it uses BLOB storage, which *might* be in the DB
   (10:07:30 AM) MichaelDaum: better
   (10:07:43 AM) JulianLevens: Ok, Versatile use PlainFile to manage attachments
   (10:07:51 AM) JulianLevens: So still pub there
   (10:08:01 AM) CDot: sure, that&#700;s one way to do it
   (10:08:15 AM) CDot: I pulled all into the DB because.... well, just because.
   (10:08:17 AM) MichaelDaum: a "store" for attachment could also mean to just point to another DMS url
   (10:08:28 AM) ***gac410 is opening a task for Package testing for rcs,v files.
   (10:08:38 AM) CDot: MichaelDaum: very good point. Need to look at the API for that.
   (10:08:57 AM) CDot: Foswiki::Store::getAttachmentURI(...)
   (10:09:32 AM) CDot: argh, blooding %PUBDIR%/This/That.js
   (10:09:59 AM) MichaelDaum: .. to support an Alfresco store. In this case, viewfile should not be used to deliver the document, but the 3rd party DMS directly, e.g. when using a streaming service for videos or audios or flvs or ...
   you name it that the DMS itself is better suited to serve to the user
   (10:10:00 AM) JulianLevens: xsendfile may become very important
   (10:10:02 AM) CDot: (mutters under breath: all this should have been considered from day one)
   (10:10:17 AM) JulianLevens: famous last words
   (10:10:26 AM) MichaelDaum: yes %PUBDIR% should become context sensitive
   (10:11:12 AM) MichaelDaum: %PUBDIR%/%WEB%/%TOPIC% -> %PUBDIR{"%WEB%.%TOPIC%" attachment="File.stream"}%
   (10:12:00 AM) MichaelDaum: otherwise mapping certain areas of the store to different urls won&#700;t work out
   (10:12:43 AM) MichaelDaum: things simply aren&#700;t necessarily organized /pub/web/topic-ish on an alfresco or amazon or google drive
   (10:13:57 AM) JulianLevens: Can xsendfile be used to translate the URI
   (10:14:09 AM) MichaelDaum: no
   (10:14:15 AM) JulianLevens: :(
   (10:15:14 AM) MichaelDaum: goes like this (1) url comes in (2) http server calls xsendfile (3) foswiki says file is okay go serve it from somewhere else (4) http server takes it from there and streams it back to the browser
   (10:15:52 AM) ***gac410 ages ago wanted to look at using an amazon or other public store to cache attachments, when I had a utterly buried slow dsl uplink. But cable internet solved that :D
   (10:16:49 AM) JulianLevens: I was hoping you could provide an alternate URI when saying okay
   (10:17:24 AM) MichaelDaum: the only "url translation" in xsendfile happens internally when foswiki talks to the http server in step (3)
   (10:17:51 AM) MichaelDaum: for nginx it tells the server to use location /files to serve the real attachment ... whatevr you configured the location /files to do
   (10:17:52 AM) gac410: IIRC it would be in the completePageHandler, need to scrape out url's and remap them to an alternat store
   (10:18:25 AM) MichaelDaum: gac410, you think to twiki-ish
   (10:18:29 AM) MichaelDaum: ^to^too
   (10:19:03 AM) MichaelDaum: better would be to have a %PUBURL macro that expands to the current url store right away
   (10:19:14 AM) MichaelDaum: based on params to the %PUBURL macro
   (10:19:33 AM) MichaelDaum: ^current^correct
   (10:19:46 AM) gac410: Right. I agree fully. But lots of old content exists. So then need to scan/convert existing topics.
   (10:19:56 AM) JulianLevens: But that needs a topic conversion tool
   (10:20:11 AM) gac410: yes. indeed.
   (10:20:12 AM) jast: if they&#700;re not using %PUBURL% in existing topics it&#700;s their own darn fault :)
   (10:20:30 AM) jast: the admin can add a redirect to the web server config. done.
   (10:21:46 AM) MichaelDaum: we thought about making PUBURL(PATH) proper macros for a very long time afaics
   (10:22:27 AM) MichaelDaum: the only reason we did not execute was content conversion
   (10:22:29 AM) JulianLevens: Long term a redirect is not enough: file could be served locally or cloud; FW may dynamically change that
   (10:23:12 AM) MichaelDaum: JulianLevens, exactly. E.g. think of a store url that is different per user.
   (10:23:12 AM) jast: the redirect could go to /bin/viewfile/Web/Topic/attachment.foo?justredirectme=yesplease
   (10:23:33 AM) gac410: I seem to vaguely recall that Sven or someone had an extension that did remap attacment url's for a public mirror like Amazon / drive ...
   (10:24:10 AM) CDot: MichaelDaum: right. And we should probably bite that content conversion for 1.2. As jast says, a server redirect can mop up the rest.
   (10:24:34 AM) MichaelDaum: I am all for a PUBURL macro
   (10:24:40 AM) MichaelDaum: count me in
   (10:25:20 AM) JulianLevens: Which brings us back to copy_store: now with added converters?
   (10:25:40 AM) MichaelDaum: ... such as PUBURL and proably toUTF8
   (10:25:59 AM) JulianLevens: toUTF8 is the default anyway
   (10:26:07 AM) MichaelDaum: yay
   (10:27:03 AM) JulianLevens: One was to implement converter is as a mixin: minimal store to change $meta before save inheriting from new target store
   (10:27:36 AM) gac410: So are we saying that for 1.2, you will be required to convert your store, even if you do not change Store implementation ... to do the PUBURL change and UTF8 change?
   (10:27:53 AM) gac410: Guys. We are making 1.2 bigger and bigger and pushing it out further and further.
   (10:28:16 AM) MichaelDaum: this all is post 1.2
   (10:28:18 AM) gac410: I really think we should be at feature freeze and NOT adding more functinoality / changing major things.
   (10:28:42 AM) gac410: CDot said "Dot: MichaelDaum: right. And we should probably bite that content conversion for 1.2. "
   (10:28:42 AM) MichaelDaum: 1.2 should only get PFS + configure done
   (10:28:51 AM) JulianLevens: No, maybe could 1.3 focus on these issues?
   (10:29:08 AM) gac410: Agreed. We really need to hold the line. Or 1.2 will NEVER get done.
   (10:29:33 AM) MichaelDaum: 1.2. should be oriented towards asking what is the least effort requried to get it out in the wild
   (10:29:33 AM) CDot: fairy snuff
   (10:29:41 AM) JulianLevens: I think even PFS should be deferred based on discussions above
   (10:29:49 AM) JulianLevens: 1.3 can follow quickly?
   (10:30:01 AM) gac410: 1.3 vs. 2.0 is "just a number" ... so yes, 1.2 no new features / no more major changes.
   (10:30:07 AM) JulianLevens: Sorry, PFS as default should be deferred
   (10:30:38 AM) gac410: I don't have a problem with the default change.
   (10:30:41 AM) MichaelDaum: ... yet still ship it but not as a default?
   (10:31:25 AM) gac410: Changing the default are one-liners to Foswiki.spec & Bootstrap. But with all the RCS issues, I think new sites should get PFS.
   (10:31:33 AM) JulianLevens: The tools to manage RCS to PFS (in the fullest sense) are immature
   (10:32:54 AM) gac410: So We have yet to really plan our "Migration guide" Which we need to do. 1.0 -> 1.1 was a "re-install and convert" not migrate. 1.1 -> 1.2 ???
   (10:33:41 AM) JulianLevens: Same again?
   (10:33:48 AM) gac410: I don't know if it will be safe to just install 1.2 on top of a 1.1. system. I've been *assuming* that 1.1 -> 1.2 will be reinstall / reconfigure / convert
   (10:33:55 AM) jast: FWIW I upgraded 1.0 -> 1.1 in place
   (10:34:05 AM) jast: and will probably do so again for -> 1.2
   (10:34:37 AM) gac410: Yes it can be done, but there were some really ugly known issues where out-of-date topic templates / stale .js in pub etc. caused huge issues iirc
   (10:36:04 AM) gac410: iirc, I did in place too, but used the foswiki-upgrade-check bash script to clean out the obsolete stuff. And that process is not for mere mortals :)
   (10:36:41 AM) jast: I like me some adrenaline :}
   (10:36:59 AM) CDot: Is anyone listening to JulianLevens?
   (10:37:07 AM) ***CDot wants to hear the arguments
   (10:37:24 AM) gac410: yes me too JulianLevens
   (10:37:36 AM) jast: we do have a robust tool for converting from RCS to PFS, right?
   (10:37:40 AM) jast: that&#700;s enough for me
   (10:38:06 AM) ***gac410 has never tried it. No idea how robust it is. CDot&#700;s comments about it give me concerns.
   (10:38:42 AM) CDot: NOT NOT rely on my (lack of) testing of that conversion.
   (10:38:43 AM) JulianLevens: I&#700;ve written a better copy_store based on CDots original eliminating some of his concerns
   (10:39:00 AM) CDot: JulianLevens: have you checked it in? If not, why not?
   (10:39:47 AM) JulianLevens: No I was trying to implement a FeatureProposal (not accepted yet). I&#700;ll need to back out that back and check it in ASAP
   (10:39:47 AM) jast: even if we don&#700;t have a conversion tool, I don&#700;t mind changing the default to PFS if there are no known issues
   (10:40:26 AM) gac410: There is one blocker. You can't manage existing attachments with PFS. But other than that ...
   (10:41:08 AM) JulianLevens: I was writing StoreTools in general and realised that copy_store is not good enough to cover all requirements
   (10:41:09 AM) jast: right, so with that taken care of, I don&#700;t have any complaints, though of course a working convertor would be very good to have ready for 1.2
   (10:41:37 AM) JulianLevens: However PFS is a file based one like RCS and some of my concerns may be moot there
   (10:42:03 AM) gac410: Yes, the converter needs to be very reliable ... both directions rcs <-> pfs
   (10:42:22 AM) CDot: I think a working convertor is critical. I was hoping for some help, but.....
   (10:42:45 AM) JulianLevens: That&#700;s covered: I converted Rcs; PF and Versatile in all directions
   (10:42:53 AM) gac410: Would be nice to also have a "fixup mode" Scan a converted store, to find any stragglers.
   (10:43:18 AM) JulianLevens: ?
   (10:43:48 AM) gac410: I've never tried the converter. So ignore my ramblings :)
   (10:44:37 AM) gac410: My file system is in a state where topics have a mixture of ,v and ,pfv, sometimes both, :)
   (10:45:27 AM) gac410: ie, my test system bounces between pfs and rcs without any realization that when I checked out 1.1.9 or 1.2.0, my store was changing.
   (10:45:55 AM) ***gac410 admires the holes in his feet.
   (10:46:15 AM) jast: how? shouldn&#700;t your config have a specific store set?
   (10:47:24 AM) JulianLevens: I refer you to http://foswiki.org/Development/StoresShouldBePassedConfigHash
   (10:48:04 AM) gac410: jast, I test configure a lot, So I was reconfiguring often with very different results at times.
   (10:48:07 AM) JulianLevens: But that has to be post 1.2 it needs core changes if accepted
   (10:48:31 AM) JulianLevens: That why my store tools need refactoring to remove that!
   (10:50:18 AM) MichaelDaum is now known as MichaelDaum_
   (10:52:29 AM) ***gac410 makes an RM decision. Adding an urgent task to "convert_store.pl needs testing and improved robustness"
   (10:52:46 AM) CDot: :-)
   (10:53:39 AM) gac410: And decision on PFS to ship, and/or to make default, will defer based upon results of testing
   (10:54:30 AM) gac410: ie if we end up with blocker convert bugs, that will gate whether we release without pfs, or delay release for a robust converter .... fair enough?
   (10:55:56 AM) Lynnwood [~lynnwood@foswiki/developer/lynnwood] entered the room.
   (10:56:10 AM) Lynnwood left the room.
   (10:56:37 AM) ***gac410 asks our Testing grur: CDot, could the Store tests that I&#700;ve broken with the "die" actually run the convert_store against the test webs? so that the die doesn&#700;t
   (10:57:23 AM) gac410: Though it's only the WikiUsers topic in the TestUsersWeb that has the rcs issue.
   (10:57:38 AM) CDot: gac410: you could, but it&#700;d be very, very slow
   (10:58:00 AM) CDot: better to make sure the right store is selected earlier in the tests
   (10:59:10 AM) gac410: hm.... that is well deep in the test plumbing. It would have to happen before the test setup creates the temporary users web. I'm guessing.
   (11:00:18 AM) gac410: Guys ... 3 hours. I'm declaring this meeting adjourned Continue to discuss here or on #foswiki ... I'll capture the logs a bit later.
   (11:00:21 AM) ***gac410 needs breakfast
   (11:06:15 AM) gac410: http://foswiki.org/Tasks/Item13100 convert_store.pl needs testing
   (11:06:19 AM) MichaelDaum_ is now known as MichaelDaum
   (11:06:40 AM) MichaelDaum: thanks everybody for this intensive discussion. I enjoyed it a lot.
   (11:07:21 AM) MichaelDaum: makes obvious that we should continue meeting up regulary
   (11:07:44 AM) MichaelDaum: not only drop in silently into #foswiki but be more formal to join at #foswiki-release
   (11:08:10 AM) gac410: I listed 2-weeks on the ReleaseMeetings agenda. Next meeting December 1st ...That okay?
   (11:12:09 AM) gac410: Damn. Our new extensions are missing the "StandardReleaseComponent" string, so they don't show up on our blockers. Just fixed PFS, RCSStore and JsonRpc
   (11:12:51 AM) gac410: CDot, ConfigurePlugin is a required component. ConfigureContrib is not. Correct?
   (11:13:48 AM) CDot: ConfigureContrib is dead
   (11:14:06 AM) CDot: ConfigurePlugin is required for the UI for Configure, but isn&#700;t *strictly* required
   (11:14:15 AM) CDot: as you *could* use =tools/configure=
   (11:14:29 AM) CDot: or even manually edit LSC
   (11:14:43 AM) gac410: Right, but we will release it with fw, so urgent tasks against it need to show up as blockers.
   (11:16:45 AM) gac410: So I just added ConfigurePlugin, PlainFileStoreContrib, RCSStoreContrib, JsonRpcContrib, and NatEditPlugin ... Are we adding anything else to 1.2? from 1.1.
   (11:19:30 AM) gac410: Ah MichaelDaum Regarding our UserRegistration form. We are getting lots of registrations with a company url in the form. Can we change templates to just not display that url by default.
   (11:20:18 AM) gac410: If I find a registration with a suspicious url, and a check of apache log shows no activity other than register / save .. done. then I add the url to awsp list and kill the user,.
   (11:20:26 AM) gac410: yesterday there were 4. :(
   (11:20:54 AM) gac410: I figure if anyone is really interested in foswiki, they will browse to something other than the user registration.
   (11:31:34 AM) ModAcOst left the room (quit: Quit: Konversation terminated!).
   (11:36:31 AM) JulianLevens: http://foswiki.org/Tasks/Item13100 updated with my work on this attached
   (11:40:16 AM) jast left the room.
   (12:23:18 PM) MichaelDaum left the room (quit: ).
   (12:30:43 PM) JulianLevens left the room.
   (02:06:50 PM) CDot left the room (quit: Quit: Leaving.).

Topic revision: r2 - 18 Nov 2014, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy