#foswiki-release 2018-04-16,Mon

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
gac410hi everyone - good morning / good day
Are we going to have a release meeting today?
[13:02]
MichaelDaumHi George
I am here finally
[13:09]
gac410Hi MichaelDaum
Okay ... On to the release. 1st - urgent tasks / release blockers
Nothing new. reported in the last couple of weeks.
For features, there are a couple of Item branches that could be reviewed.
[13:09]
MichaelDaumwhich are these? [13:13]
gac410https://foswiki.org/Tasks/Item14602 - Allow lower case topic names, is ready to merge. Not a lot to it. It does not impact WikiWords or [[spaced wiki links]]
In the latter if it detects a space, then the old rules kick in.
[13:13]
MichaelDaumoh cool
I have once seen a suppor question about this topic. I guess that triggered this feature?
[13:14]
gac410yes. Mainly for the klingon wiki :D
He also wanted ' singe quotes in topic names, but that's a non-starter. I tried it but it breaks %IF statements all over the place.
[13:15]
MichaelDaumhe should have a look at the new TopicTitlePlugin [13:16]
gac410Yes. [13:17]
MichaelDaumit lowers the pressure on what we want to allow as a WikiWord and what not [13:17]
gac410Anyway, the lower case names IMO make sense, especially as with utf8 you might have topic names in unicameral languages. [13:18]
MichaelDaumyep [13:19]
gac410But in those cases, wikiwords don't make sense either. So from that regard only [[ explicit linking makes sense. [13:19]
vrurgHi all :) [13:19]
gac410Howdy vrurg [13:19]
MichaelDaumI tend more and more to disable autolinking anyway
with all these modern brands and product names and types autolinking happens more than desirable
[13:19]
gac410Another one I *started* on was the {ConfigWebName} and {HomeWebName} config. only doing the config web part - in https://foswiki.org/Tasks/Item14664 branch
However I've run into a challenge when it comes to automatically setting the default for upgrade sites.
[13:20]
MichaelDaumhow so [13:21]
gac410Just in the order of how missing config variables get initialized / merged from the Foswiki.spec file
I need to re-think the process of when that particular key gets set either during Configure::Load or by Foswiki.pm initialization.
[13:21]
MichaelDaum... an area I never dived into [13:23]
gac410Anyway, iirc Item14664 branch works okay as a new install. System/Config web exists as an empty web. I changed the SitePreferences topic into System.SitePreferencesTemplate. So there is no topic to override during future upgrade. [13:24]
MichaelDaumThis helps a lot really. The main challenge always was to migrate Main, half net data, half foswiki distro. [13:25]
gac410er. Main.SitePreferences moved to System.SitePreferencesTemplate. and docs on how to connfigure your system use %IF statements to create a missing System/Config.SitePreferences using an edit link with template. [13:26]
MichaelDaumand another half config settings [13:26]
gac410y.
I think I've also found all the links to Main.blah overrides System.blah and pointed them to the new {ConfigWebName} location
I'm wondering if for upgrade it makes sense to either ship a shell tool, or a small bootstrap hook that will copy a list of key Main.topics into the System/Config web on first execution.
[13:26]
MichaelDaumI will have to adjust NatSkin following that logic also
I don't think so. For upgraders we should follow a "just works" approach
the old topic layout should still be supported
only new installs will suggest the superior approach
[13:28]
gac410hm And that runs into the challenge. For upgraders, the default ConfigWebName must be set to the UsersWebName. But for new installs, ConfigWebName should be the System/Config location. [13:30]
MichaelDaumConfig as a subweb of System? [13:30]
gac410That's what we initially discussed last time around. [13:31]
MichaelDaumyea I remember. yet this wont work for VirtualhostingContrib where System is symlined among different vhosts [13:31]
gac410It could really be anywhere, but risk of a root level web is running into someone who already created a web of that name. [13:31]
MichaelDaum^symlined^symliked
true, but we are talking about new installs that might choose where to locate the Config web.
I tend to separate _users_ in a different web and use Main for the static parts
[13:31]
gac410Right. I was considering a OnSave handler in the {ConfigWebname} checker which could create/copy the directory. [13:33]
MichaelDaumIt seems I would choose a setting {ConfigWebName} = {HomeWebName} = Home, and {UsersWebName} = Users
as far as I see with your work, we will be able to set up whatever we want :D
[13:34]
gac410From our last round of security issues, we want the configweb to be something that users clearly / obviously cannot edit. In typical open wikis the home web is fair game, at least modeled after the old Main web. [13:35]
MichaelDaumsh* phone call coming in [13:36]
gac410Yes. I've cleanly split {UsersWebName} and {ConfigWebName} and figured you were signed up to do the {UsersWeb / HomeWeb} split
Didn't want to step you your developers toes :D
So the only hard parts are: 1) choosing sane defaults for the new site 2) Making an easy upgrade for existing sites and <maybe> 3) Allowing easy change from bin/configure
[13:36]
MichaelDaum(3) seems to be the hardest part [13:41]
gac410Actually I think 2) will be harder [13:41]
MichaelDaumwhy not just leave things as they are in the config [13:43]
gac410I need to find the "right place" in Configure::Load that can detect if {ConfigWebName} is unset (before the Spec merge) and then set it appropriately - but only if the configured LocalSitePrefs exists. [13:43]
MichaelDaumwhen upgrading an existing site, new default config settings should be set in LocalSite.cfg, but default to a layout that matches the existing site. [13:43]
gac410For a new site. Foswiki.spec sets {ConfigWebName} to System/Config (or wherever we decide. [13:43]
MichaelDaumupgrade -> worx [13:44]
gac410For an existing site {ConfigWebName} is un-set. So configure will merge it from Foswiki.spec automatically.
setting it to the new location , which we do NOT want.
So I need to figurer out how to conditionally prevent that merge from the foswiki.spec by detecting an upgrade vs a new install and setting a value.
My initial attempt was less than successful :D
I expect I'll get there. Need to just step back and think a bit more.
[13:44]
MichaelDaumhack and see
:)
[13:47]
gac410part is my own whacky configuration - where I use tools/configure to build my LocalSite.cfg from a series of -save -set -set -set commands. [13:47]
MichaelDaumI'll have to leave in 10 minutes and would like to give you a short update on TopicTitles [13:48]
gac410BTW I agree with you that I do NOT like the System/Config location. maybe HomeWeb/Config might make more sense?
Okay go for it
[13:48]
vrurgI didn't do upgrades personally for quite some time. Don't we have a special upgrade bundle?
I mean – separate from a clean installation one?
[13:49]
gac410Yes but in this case we are moving the location of the topics. [13:49]
MichaelDaumI've decided to approach it similar to the way we did the ZonePlugin and implemented a TopicTitlePlugin that monkey-patches Foswiki::Func when required on today's engines. [13:49]
gac410Yes I saw that. [13:49]
MichaelDaumI then reworked all plugins that already implemented a getTopicTitle() perl api to depend on the new TopicTitlePlugin [13:50]
gac410Will you still add the ToipcTitile functinoality to 2.2 [13:50]
MichaelDaumand call Foswiki::Func::getTopicTitle to be forward compatible
yes
[13:50]
vrurgFoswiki.spec could be edited for the upgrade bundle to leave ConfigWeb pointing to the old default. Won't it work? [13:50]
gac410ConfigWeb does not exist in old configurations [13:50]
MichaelDaumthe separate plugin is required for me to provide an upgrade path for plugins already using topic titles
part of the logic was removed from DBCachePlugin as well as NatEditPlugin
and consolidated in TopicTitlePlugin
[13:51]
vrurggac410: Right, but you supply it with Foswiki.spec. Just have different defaults for a -upgrade and -install tarballs. [13:51]
gac410cool [13:51]
MichaelDaumthese wll be released soon [13:52]
gac410Ah.. MichaelDaum - any timing on when we should update the 20 or so out-of-date extensions in blog.foswiki.org? [13:52]
MichaelDaumFoswiki-2.2 won't require a TopicTitlePlugin as I plan to implement native support for this feature in Foswiki::Meta and Foswiki::Func [13:52]
gac410Technically I was supposed to announce feature freeze for 2.2 I guess we are slipping it again? [13:53]
MichaelDaumthe important part to take care of is current WikiWord unit tests. there might be changes in how WikiWords render.
feature freeze is fine as I already have started implementing the feature half way.
[13:53]
gac410Ugh unit tests. That reminds me, I need to get Florian to add a dependency to fix the password tests.
Or make some more parts of the test conditional
vrurg: The problem with fiddling with the upgrade package is not everyone uses that stragegy - unzip in place - to upgrade.
I have never used that way - except for testing the package.
[13:56]
vrurgOk. [13:58]
gac410However the more I think about my test environment, I may be shooting at my own feet. My test env. probably more closely resembles the site that installs new and copies over old data. [13:59]
MichaelDaumhave to leave. thanks folks. [13:59]
gac410That approach I don't see that we can automate.
Okay Thanks MichaelDaum ... cu around
[14:00]
vrurgMichaelDaum: cu! [14:01]
gac410So for any site that does an install / merge, that we just handle in the release notes. If you do this, be sure to move <list of topics> [14:01]
vrurgUnfortunately, for the last couple of years upgrades are done by one of my co-workers. So, I don't remember many details of the procedure.
BTW, this week I start preparing for the conference and would probably continue doiing things for 3.0 branch.
[14:03]
gac410My test installatoin is probably a worst case. My Main web is already renamed to Usersweb, and i build a new LocalSite.cfg using tools/configure [14:04]
vrurgWe're probably done for today. I'll be back to my work too. [14:09]
gac410Thanks vrurg. [14:09]
vrurgThanks! and cu! :) [14:09]
gac410Thanks everyone. That's a wrap. See you all here in 2 weeks, and in the #foswiki channel. [14:10]
Hi JulianLevens you just missed the meeting
Should we move the Backlnks proposal out to post 3.0 ?
[14:16]
........ (idle for 38mn)
JulianLevensI'll need to get my head around where Foswiki is going, and where I am
I'll try and chat in the next few days
[14:55]
***JulianLevens has left [14:57]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)