You are here: Foswiki>Development Web>ReleasePlan>ReleaseMeetings>ReleaseMeeting02x02_20161031>ReleaseMeeting02x02_20161114 (14 Nov 2016, JulianLevens)Edit Attach

Release Meeting: 14 Nov 2016

Details

1. Urgent Task review

  • 14063 (Closed): Bootstrap fails to correctly detect path when mod_rewrite engine is disabled. Fix checked into Item14180 branch.
  • 14117 (Waiting for Release): TML sends TinyMCE into an eternal loop Upstream bug, no progress.
  • 14126 (No Action Required): Random topics or webs get access restricted No recreation, or other supporting reports.
  • 14195 (Closed): Loop in Foswiki::UI::View::revisionsAround under some conditions. Fix checked in - probably ready for release.
  • 14202 (Closed): PageCache tweaks to control dependency growth. - extensive discussion on cache performance. The name of a new function was changed. Changes will be tested on Foswiki.org

2. Development Discussion

  • DependenciesFreedom Rejected Proposal: Foswiki dependencies and installation simplicity.
    Quite a bit of discussion on the new CPAN dependency installer. Currently an experimental branch.

(No feedback yet on the following experimental branch.)
  • 14180 (Closed): Bootstrap enhancements and refactoring. Bootstrap changes
    • Refactored into separate Foswiki::Configure::Bootstrap - no operational impact
    • Pub path replaces /bin with /pub vs. /bin/../pub
    • Properly handles apache ENV with mod_rewrite disabled.
    • Detects a proxy for properly setting DefaultUrlHost
    • Tested with mod_perl, nginx+fastcgi, apache with & without mod_rewrite.

3. Release plan / strategy

Review of features / Feature branches

New proposals - Proposals on 14 day clock

No new proposals need review

14 Day timer ended - Last call

No proposals reaching 14-day threshold.

Major redesign proposals / Development discussion for 3.0+ / 4.0

3. Next release

Patch release 2.1.3

  • Release from: Release02x01
  • Beta start: TBD
  • Release target: August 2016

Feature release 2.2.0

We are at the feature freeze, and still no proposals on the ReleasePlan have been merged! Agreed to defer 2.2 until December

  • Feature Freeze: 1 Dec 2016
  • Release from: master
  • Beta start: 15 Dec 2016
  • Release target: Jan 2017

Next meeting - - Monday 28 Nov 2016 1300Z — ReleaseMeeting02x02_20161128

IRC Log

13:38:12 JulianLevens joined the channel
13:50:08 gac410 joined the channel.
13:51:46 gac410 Hi everyone. g'morning. End of daylight savings time here. No coffee yet and not awake.
13:53:39 JulianLevens good morning to you to
13:54:04 JulianLevens I've had a few coffee already, albeit decaf and I think I'm awake
13:57:45 jomo joined the channel.
13:57:54 jomo hiall..
13:58:09 gac410 hi jomo
14:02:37 gac410 Hello everone. It's 1301Z ... are we ready to start?
14:03:15 JulianLevens Yep
14:03:18 gac410 First up - ReleaseBlockers
14:04:37 gac410 There are 4 that list under PatchReleaseBlocker, but only one practical for the patch release.
14:05:30 gac410 Fixes for Item14205 - with help of Vadim, can be tested. I'll probably merge.
14:06:25 gac410 It's some work on the certificate wizard, and the email autoconfig. Makes it more reliable. Newer vesions of IO::Socket::SSL wouldn't work.
14:07:18 gac410 Not a blocker, but Item13936 also has a test branch.
14:08:00 gac410 On some servers, the email is rejected when "From" == "To" on a email We ran into that with the infra list for foswiki.org
14:08:52 gac410 The patch adds an optional EXPERT config for a WikiAgent name & email, used when sending messages. Defaults to WikiWebMaster if omitted.b
14:10:01 gac410 I was debating whether that one needed a FeatureRequest, or if I could slip it into a patch release.
14:10:50 JulianLevens What are the issues with it?
14:11:02 gac410 If I merge those two, I'm ready to build Release 2.1.3
14:11:19 gac410 with?
14:11:43 JulianLevens Why not wait to 2.2 at least that's a minor release?
14:12:07 gac410 I'm wondering if we will have a 2.2 in the forseeable future. No feature work yet.
14:12:12 JulianLevens With the EXPERT option possibly needing an FP
14:12:54 gac410 It's a fuzzy one. All it does it add another identity for sending email. And if you don't use it it's exactly like prior releases.
14:12:55 JulianLevens Well I'm active with locales with QueryBackLinks to follow, I might make Dec 1 for the former
14:14:05 JulianLevens Looks like low risk to me, not even sure it's a new feature just extending an existing feature, but I don't know the code
14:14:08 gac410 So I'm leaning toward calling it a bugfix not a feature. It really doesn't impact any user operation unless activated.
14:15:18 gac410 Code is 2 new config keys, and changing the various email templates to use Wiki Administrator <[email protected]> in place of Wiki Administrator <[email protected]>
14:15:19 JulianLevens FWIW: I'm not concerned about it, it's your call
14:16:10 JulianLevens How would anybody be impacted with locally tailored email templates
14:16:11 gac410 and 2 lines in Foswiki.pm macro init that adds the new variables, set to the original values new values
14:16:31 gac410 Not at all. Existing webmaster@foswiki.org key remains.
14:16:36 JulianLevens Of course
14:16:57 gac410 Unless they had added their own new parameters that collided.
14:17:11 JulianLevens Highly unlikely
14:17:53 gac410 Y. That was the only part that suggested maybe a feature request was required. So my thought is to merge and put an alpha on foswiki.org
14:18:50 gac410 There is one other bug - Item14208 - extender.pl hardcoded the repository for cli extensions. I'll probably pick that one up too.
14:18:50 JulianLevens Fine by me
14:19:51 gac410 So everyone. Check your bug lists ... Anything you want in a 2.1.3 - please prioritize within the next week lets say.
14:20:12 gac410 I'll build an Alpha on the weekend, and do an email to Translations list asking translators to get a start.
14:21:29 jomo one question - what happens if someone upgrades the foswiki, and he using his OWN templates for the email handling. Need change them to use it the WIKIAGENTNAME?
14:21:48 gac410 No. The old templates will work just fine.
14:22:04 gac410 I'm adding two new keys for name & email, not changing the old ones.
14:22:27 jomo then probably no problem and could slip without FP.
14:23:08 gac410 And in thining about it, there really ought to always have been the distinction. the WebMaster is a "Contact" address - email webmaster for help. But email originated from the wiki isn't reallly coming from the webmaster, but from the wiki itself.
14:23:36 gac410 If you add in things like dkim signing, really the wiki should not be sending emails with the webmaster's identity.
14:23:47 jomo yeah - it is usually something as some_thing_no_reply@example.com
14:23:57 jomo aka added the no_reply smile
14:24:21 gac410 Right. So the fix feels right.
14:24:27 jomo smile
14:25:02 gac410 Some news to report. We've lost another developer
14:25:18 jomo ?
14:25:30 gac410 JanKrueger aka jast. He will still hang out, but he's changed jobs and no longer using Foswiki in his work.
14:26:00 jomo he managed many wikis right?
14:26:03 jomo ibm?
14:26:25 gac410 no, Modell-Aachen they had a service based upon Foswiki - with lots of local modifications.
14:26:33 jomo ah...
14:26:54 jomo frown, sad smile
14:27:01 jomo bad news
14:27:03 jomo frown, sad smile
14:27:28 gac410 Modell-Aachen also hosts our translate.foswiki.org server. That thankfully will continue. But I expect we may eventually want to find another host.
14:27:55 jomo but model-aachen will confitune using FW... so, hopefully someone taking his position...
14:27:56 JulianLevens bad new indeed, especially as he's talented
14:28:20 jomo yeah! frown, sad smile
14:28:32 JulianLevens The whole of Model-Aachen use FW there business is based around it
14:28:45 JulianLevens s/there/their/
14:29:04 gac410 Y. though when someone leaves due to real-life changes, it's no where near as negative as a project dispute. Maybe it's an opportunity to spread Foswiki to a new business big grin
14:29:26 JulianLevens Let's hope so
14:29:58 gac410 So ... any more bugs to discuss. Or onto feature requests.
14:30:36 gac410 One new proposal from Vadim vrurg - https://foswiki.org/Development/OOConfigSpecsFormat
14:30:57 jomo hm... me still don't understand it fully.
14:31:20 gac410 And one more hitting the 14 day timer https://foswiki.org/Development/DependenciesFreedom
14:31:28 gac410 Okay . vrurg ... are you around?
14:32:03 gac410 The OOConfigSpecs. This really is purely internal jomo. The Config.spec and Foswiki.spec files are used to drive the Configure UI.
14:32:15 gac410 It's the metadata behind LocalSite.cfg
14:32:46 jomo yes, the current is more than clear for me... wink
14:32:59 jomo just not the things in the FP smile
14:33:33 JulianLevens I do not have a fundamental problem with either, or at least with the principle behind them. I need time to consider them more
14:33:53 JulianLevens I am positive in principle
14:33:58 gac410 The Config.spec / Foswiki.spec Used to be processed with a "Do" ... to prime the config with defaults, then overridden with at "do" of LocalSite.cfg
14:34:50 jomo i understand the current implememtation... wink just not understand fully the proposed one...
14:35:09 gac410 So Foswiki when creating a new config would do Foswiki.spec do each Confg.spec, and then save the results as LocalSite.cfg. But, it does NOT work that way any more.
14:35:19 JulianLevens I've been considering combining DEPENDENCIES, MANIFEST and Spec files into one. Part and parcel of improving the SCM of the project
14:35:49 JulianLevens And being able to automate build, testing etc with reliable results
14:36:05 gac410 There is a custom parser in Configure that takes apart the comments embedded in the Spec files and processing them into the internals.
14:36:33 JulianLevens y, I came across that
14:36:54 gac410 So vrurg proposed storing the Spec files into a perl structure, which would certainly simplify then parser.
14:37:06 gac410 if not eliminate it.
14:37:26 gac410 At least that's my understanding from a 10,000 meter level.
14:37:36 jomo i very concerned with this sentence: But intermixing means only one thing: the internal structure would store not only value field for the config data but few other fields with this value's attributes.
14:38:05 jomo this sound for me as WRONG design.
14:38:06 gac410 It's the default value, not the running config value.
14:38:25 JulianLevens and possibly other meta-data
14:38:38 gac410 LocalSite.cfg will still have the runtime value. (I hope)
14:39:20 JulianLevens I've been considering the whole SCM/build process and I'm not sure it's enough by itself
14:39:49 gac410 It's really a minor change if you think about it. The config.spec has the Default value, and all the other metadata is encoded into the perl comments.
14:40:35 gac410 He is proposing storing the metadata along with the default into a hash instead of needing to parse it from the comments.
14:40:53 JulianLevens y, I'm not likely to raise a concern. It doesn't block my ideas in any way
14:40:54 jomo hm... for me this ISN'T minor - if i understand right the FP.... and IMHO converting the spec to perl-format isn't buy nothing for us..
14:42:01 JulianLevens I think it does - if the comments containing code are parsed out into separate named meta-fields, then
14:42:18 JulianLevens it will be easier to extend the meta-options
14:42:40 gac410 As a user it has no impact, As a Developer, it simplifies writing the config.spec / reading the spec. And simplifies configure that parses the spec on every load.
14:43:49 gac410 Exactly JulianLevens ... If you need to add some different meta about a key - say to drive a custom "checker" you can add it without having to revise the spec parser to handle it.
14:44:45 gac410 This one really needs Crawford's input too. CDot is the master of the spec file wink
14:44:53 jomo me will never raise any concern /im not an developer :)/ - just for me this sound as an very wrong design...
14:45:18 JulianLevens How will the new spec file be parsed? via do or is there something safer?
14:45:46 JulianLevens I'm thinking of malicious spec files placed in extensions
14:45:47 jomo exacltly - the proposed is "perl-calls"... frown, sad smile
14:45:50 gac410 Don't know currently need vrurg
14:46:02 jomo in the FP - clearly - perl-calls... cry
14:46:52 JulianLevens That won't necessarily stop the basic idea. JSON structure is similar-ish and even JSON::PP would be fast enough in this case
14:47:38 gac410 Y that was my only thought, It the format of a perl structure right, or should it be JSON or XML or some other well known format.
14:47:44 jomo JSON is OK, XML is OK, YAML is OK - but please no direct perl-calls... cry
14:48:16 jomo so NO more "do" smile
14:49:36 gac410 jomo, it's not really perl calls, but it is perl code. It's a nested hash of key => value where value can b e { morekey => value }
14:50:16 jomo ok - so terminology - i mean - no perl code in the spec. files.
14:50:33 gac410 The storage format could still be json or xml, resulting in the same hash representation I think.
14:51:01 jomo the LSC (and spec too) should be parseable - universally - not only by "perl"...
14:51:55 gac410 Well LSC we want to be simple and really fast. key = value ... It doesn't need anything else - embedded meta, etc.
14:52:15 jomo ok - thats right.
14:52:46 jomo then why we need the:
14:52:48 jomo the internal structure would store not only value field for the config data but few other fields with this value's attributes.
14:52:55 jomo for the NORMAL foswiki run.
14:53:17 vrurg Hi all!
14:53:29 jomo the configuraion management is totally fifferent beast as the normal-foswiki runtime...
14:53:31 vrurg I'm late today.
14:53:35 gac410 needs to read it more closely ... heya vrurg ... ears been burning?
14:53:47 jomo hi, you're very needed here smile
14:54:01 vrurg No, daylight time change missed. frown, sad smile
14:54:39 gac410 had the same challenge. 1300Z comes too early ... luckily Monday is trash pick-up day, or I'd never make it.
14:55:11 vrurg Shall we push it for 1hr?
14:55:36 JulianLevens What time is it there?
14:55:38 vrurg Ok, I see there're questions to me but it'd take time to read through. A brief?
14:55:45 jomo we can't move the Rel-meet to 1500Z ? (for the EU it is still inside working hours) imho...
14:55:46 gac410 I'm more concerned about getting more attendance. I'm willing to keep the 1300Z
14:55:49 vrurg 8:55 on the east coast.
14:56:15 jomo vrurg: one question (unfortunaley wide one): need explain the: the internal structure would store not only value field for the config data but few other fields with this value's attributes.
14:56:28 gac410 right, so meeting start now for me is 8: AM. Not all that bad.
14:57:01 JulianLevens jomo: meta-attributes, e.g. validation options for use in configure
14:57:31 gac410 JulianLevens: re malicious spec file in extension. That's rather minor, in that if you can install an extension, any part could be malicious. js, perl, etc. Spec is least of worries.
14:57:34 vrurg jomo: Not completely true, as I wrote it on the topic. Meta from specs would be fetched on request only.
14:57:38 jomo ok, why we need such fields for the normal foswiki runtime?
14:57:57 vrurg gac410: Absolutely correct.
14:58:19 JulianLevens The default-value in the spec is copied into LSC, but user can change that in configure
14:59:14 vrurg jomo: For saving, for configure. There could be other applications we don't foresee now.
14:59:15 jomo we have (even currently) 2 different things: 1.) loading the LSC 2.) config-management - for the normal FW runtime we need only the LSC (1) - and only for the config-management we need the "additional fields"...
14:59:23 JulianLevens Right it's not a great risk
15:00:04 vrurg jomo: I want to split config data processing and config management UI from each other.
15:00:04 JulianLevens I converted a project using perl-structure to JSON, it was better for some reason
15:00:37 vrurg Current approach limit developers in their access to config internals.
15:01:41 JulianLevens How urgent is this for the OO work?
15:01:48 jomo ok, so just want ensure: for the normal foswiki runtime (aka, outside of the /bin/configure) here will be NO other field attached to the config, even in the internal representation... is this correct? if yes - i have no more questions big grin
15:02:10 JulianLevens Could FW 3.0 launch without this?
15:02:14 gac410 jomo, there are actually 4 things. 1) Config runtime (LSC), 2) Config defaults (Spec), 3) Config UI (Spec comments), 4) Config validations (Spec comments comprising javascript snippets)
15:02:33 jomo me concerniing just about the 1
15:02:46 vrurg For example, I want the new extensions to get into. There it would be possible to replace current config with, say, one saving into a SQL DB. But saving currently is such a headache (not to use harsher words) that nobody would take a task of writing such extension.
15:03:06 vrurg jomo: corrent.
15:03:07 jomo aka - if the runtime LSC doesn't will have any unecessary meta attached - i will be perfectly happy...
15:03:33 vrurg JulianLevens: It will but there will be no 'killer feature'. And I think we need one.
15:04:21 vrurg And to my view new extensions + steps towards possible clusterization of foswiki is what might be that feature.
15:04:56 gac410 Yes, 3.0 is in desperate need of a killer (user facing) feature or upgrade will be a really tough sell. We still have lots of sites running 1.1.x that have not bothered to upgrade because of the data migration requirement.
15:05:13 gac410 Just was helping another one yesterday
15:05:53 gac410 I think that was really Lavr's biggest concern. All this internal muckity muck is of no direct interest to the user base of a wiki.
15:06:51 vrurg jomo: I wonder what makes you opposed to keeping helper data in memory? The footprint? Just for the info.
15:07:58 gac410 I need to tune out for a bit. Keep going.
15:08:08 vrurg gac410 is right and I would agree to Lavr's concern too. Though Lavr is willing for UI features only. But I think in terms of scalability too.
15:08:48 gac410 Y, that would be a big one. Really his significant performance concerns are another side of scalabiility.
15:09:25 JulianLevens You'd need to keep the meta-data in a shadow hash to %cfg, wouldn't you?
15:09:38 jomo code and loginc cleannes. The main problem of the current foswiki. SPAGHETTY and full of uncesessaty data (like the current $session - even recursice references) frown, sad smile Simply thing should be where they reaaly belong and not spagethy-everythingf in the memory.... for the runtime, NO METADATA is needed (because the condiguration (for the runtime) is static thing).
15:10:58 vrurg I wanna the new extensions for 3.0 because they would allow a developer to have more freedom in extending Foswiki – up to complete replacement of certain core frameworks. I wanna Foswiki servers to get rid of local data storages and move towards any kind of storage – and all this without the core developers participation. Only by extension developers.
15:12:17 jomo also, if someone manages the configuration OUTSIDE of the foswiki (like me, currenly me using YAML) - an patching the Foswiki code in every release, replacing the "runtime do" with YAML smile
15:12:30 vrurg JulianLevens: %Foswiki::cfg has to be avoided and deprecated as much as possible. Otherwise the config data hash would be a tied one one meta is read into memory. So, for the code nothing would change.
15:12:41 gac410 So regarding the new OO extensions. MichaelDaum raised a concern. I think it's merely because there is no simple example of what a new extension would look like.
15:14:11 vrurg jomo: My answer to your YAML matter is in the new extensions again. You could write one for yourself or publish it – and forget about patching.
15:14:46 MichaelDaum current LSC is too monolithic
15:14:52 jomo but only if the config-data will NOT have attached some unnecessary meta (for the normal foswiki runtime) smile
15:14:57 MichaelDaum imagine we once get integrated into debian
15:15:28 vrurg But then again, to implement saving one would need to understand all the undocumented internals of ConfigurePlugin by now. I want to get rid of these and have a clear API to config data and specs.
15:15:37 MichaelDaum current best practice is to have a .d directory where additional components are placed one after the other by the package manager
15:16:27 MichaelDaum like /.../xorg.conf.d/*.conf
15:16:53 MichaelDaum or /etc/apt/source.list.d/*list
15:16:55 MichaelDaum etc
15:17:04 jomo +++
15:17:06 jomo also, please NOTE one thing - In the Plack you can specify the env/conf as "production" and "development" - the Placked FW should accept such thing too...
15:18:05 MichaelDaum there is one master config that then does something like #include /etc/nginx/mods-enabled/*conf
15:18:10 MichaelDaum and things proceed from there
15:18:33 vrurg jomo: I won't be taking care of such details like additional support for Plack. Simply have no resources for this.
15:19:05 MichaelDaum there might be a way to program the configure script to enable a newly installed plugin ... never tried, guess so.
15:19:13 JulianLevens Can I come back to 2.2 for a moment
15:19:23 jomo vrurg: agree and understand - just DO NOT develop something wich disallowes in the future such development...
15:19:52 MichaelDaum well, who are we to disallow contributions of that kind wink
15:20:16 JulianLevens I'm tasked with fixing locale and QueryBackLinks
15:20:42 vrurg jomo: How does more information about config would prevent these developements? smile More additional info is always good for a developer (I don't speak of performance matters here).
15:20:57 gac410 Okay .. back to 2.2. Right now there still has been almost no movement on features for 2.2 We keep pushing the freeze date off a few months at a time.
15:21:03 JulianLevens vrurg has already removed locale from the OO branch and I do not see it worth my time to remove that from FW 2 anymore - there are some fixes and docs required
15:21:44 vrurg MichaelDaum: would you remove your concern on https://foswiki.org/Development/OONewPluginModel?
15:22:06 JulianLevens I want to finish off locale fixes and QueryBackLinks then I could spend time on OO and help vrurg
15:22:07 MichaelDaum y, sec.
15:22:53 gac410 Current freeze date is 01 December. Michael, do you think you'll have time to complete any of your proposals before 12/1 or should we push again out to lets say Feb 2017
15:23:14 JulianLevens More extensive locale enhancements are possible but that is better waiting for the OO branch and someone actually needing extra locale capability
15:23:16 vrurg MichaelDaum: thanks, I will then merge it into the main OO branch.
15:23:25 MichaelDaum I am flooded with last minute projects of orgs that want to spent money before 31.12.16
15:23:43 MichaelDaum vrurg, awesome
15:24:20 MichaelDaum gac410, yes, please delay freeze a bit more. thanks.
15:24:44 gac410 So for 2.2 proposals, we really have very little for Dec. then. Need to re-engage with CDot to see if he has recovered enough from his 2.0 configure burnout.
15:25:21 JulianLevens I'll still try to finish of my FP work by Dec, after all I like to play with all that OO goodness
15:25:47 vrurg would have another proposal in a day or two and that would be all I see for 3.0.
15:26:14 gac410 That would be good JulianLevens ... I'm continnuing to merge master -> OO branch on occasion. So anything done on master should be fine in 3.0 as well.
15:26:29 MichaelDaum I am overwhelmed by the sheer amount of writing going on in current proposals on F.O. .... gosh please, think about us having to read all this ... kidding wink
15:26:36 gac410 is afraid to ask ... what next vrurg wink
15:26:53 vrurg gac410: You know, we discussed it last week. Feature sets.
15:27:02 gac410 Ah... that .. okay good
15:27:21 vrurg That's something simple and something we could even port back into 2.0
15:27:31 MichaelDaum to all: if you are commenting on any dev topics, please keep it short and sweet.
15:27:48 jomo understands smile
15:28:04 MichaelDaum was not going to point fingers ... but now that you say smile
15:29:15 JulianLevens Some of my work appears to overlap some of vrurgs
15:29:33 JulianLevens another reason to work on OO ASAP
15:30:45 vrurg BTW, if we let the new specs go then I will definitely need sombody to patch the ConfigurePlugin to make it support the new standard.
15:31:51 vrurg And perhaps there would be some good points on implementation. I wanna make it in a way to have minimal amount of patching required for the ConfigurePlugins.
15:32:59 JulianLevens When I'm available I'll start to help wherever I can
15:33:09 gac410 Oh ... DependencyFreedom. That one could also be a 2.2 feature. Completely standalone.
15:33:54 vrurg gac410: Ah, right. I forgot to mention it. It was developed to be this way too.
15:34:22 JulianLevens Well no promises but it's in my interest area
15:34:23 vrurg JulianLevens: thanks a lot! I'm looking forward for it.
15:34:47 gac410 once i get 2.1.3 out i'll get back to 2.2
15:38:09 vrurg It seems like no more subjects for today?
15:40:51 JulianLevens Seems so
15:41:11 JulianLevens Either that or we're all worn out wink
15:48:31 gac410 Thanks everyone. ... 2 weeks. Next meeting Nov 28.
15:48:49 vrurg thanks!

BasicForm edit

TopicClassification Select one...
TopicSummary
InterestedParties
Edit  | Attach | Print version | History: r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r1 - 14 Nov 2016, JulianLevens
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