You are here: Foswiki>Development Web>ReleasePlan>ReleaseMeetings>ReleaseMeeting02x02_20160919 (19 Sep 2016, GeorgeClark)Edit Attach

Release Meeting: 19 Sep 2016

Details

1. Urgent Task review

  • 13797 (No Action Required): Possible cache poisoning No recreation, or other supporting reports.
  • 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.

2. Development Discussion
  • CleanUpFoswikiLocales Under Investigation: Provide relevant locale support in pure Foswiki code and eliminate perl/OS locale
  • ExtensionVersionsAndCleanUp
  • 14152 (Closed): Implement OONewPluginModel proposal: New OO Plugin proposal ready for review.
  • 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.

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 03 Oct 2016 1300Z — ReleaseMeeting02x02_20161003

IRC Log

Time Nick Message
12:34:52 JulianLevens joined the channel
14:14:59 gac410 joined the channel.
14:17:51 MichaelDaum joined the channel.
14:17:51 MichaelDaum has quit: Changing host.
14:17:51 MichaelDaum joined the channel.
14:40:55 jomo joined the channel.
15:00:00 uebera|| Hi there. :)
15:00:08 jomo hi
15:00:11 gac410 Hi everyone ...
15:01:09 CDot joined the channel.
15:01:33 gac410 Lets get started. Hit the urgent tasks quickly, and then we have a number of development topics to review.
15:01:55 vrurg Hi!
15:02:33 JulianLevens HI
15:02:37 gac410 jomo, Item13797 was an urgent task about cache poisoning from you. I could not recreate it. Anyone else. or can we set to no action.
15:02:48 gac410 https://foswiki.org/Development/ReleaseMeeting02x02_20160919 for agenda
15:03:11 gac410 https://foswiki.org/Tasks/Item13797
15:04:33 jomo no action for now... ;D - later (maybe sometime) will add an exact REPO :)
15:05:11 gac410 I fixed a number of bootstrap issues in the Item14180 branch. It could use volunteers to test. But a couple of parts I could definitely need some review before I merge into 2.1.3
15:06:48 gac410 CDot ... I made one change that I think originated from your design. PubUrl was set to bin/../pub by default. I could not find examples of when that was required vs. a simple substitution of the last part of the path with pub.
15:07:17 gac410 The bin/../pub broke some macro references to the puburl and Lavr discovered that issue.
15:09:30 gac410 MichaelDaum ... any further word from upstream on https://foswiki.org/Tasks/Item14117 and the TMCE loop?
15:10:15 MichaelDaum Hello everybody
15:10:19 gac410 For https://foswiki.org/Tasks/Item14126, I think we can no-action that one.
15:10:21 gac410 Hi MichaelDaum
15:10:28 MichaelDaum gac410, unfortunately not :/
15:10:44 CDot gac410: the /pub thing was just from trying to root off the same path for everything
15:10:56 MichaelDaum and I doubt we can fix the TinyMCE loop bug
15:11:25 gac410 Finally I found a really nasty loop yesterday. https://foswiki.org/Tasks/Item14195 which I won't disclose the recreation here as we are logged & searchable.
15:12:03 gac410 But it filled the disk on my live server with a multi-gig apache error_log and was recreatable by a simple URL. but seemed to be fcgi related only.
15:12:43 MichaelDaum %REVISIONS% ... what a nasty implementation
15:13:27 MichaelDaum nother legacy bs
15:14:10 gac410 yeah. Anyway, my patch does seem to fix the issue. I could not recreate it after I patched my server. So I think this makes a 2.1.3 a bit more urgent.
15:15:18 gac410 CDot: Any concerns about changing the URL from /prefix/bin/../pub to just /prefix/pub ??? It seems safe on all the apache I use here anyway.
15:15:24 CDot no
15:16:24 gac410 Okay great. Please if anyone has a chance to test out Item14180 branch. Let me know if you find issues. I've tested with mod_rewrite on & off, nginx and mod_perl.
15:16:45 gac410 Anything else on the Urgent task review?
15:17:34 MichaelDaum Item14195 should probably go into master as well
15:17:59 gac410 Yes, I'll merge Release02x01 into master. That will pick it up.
15:18:52 MichaelDaum I finally got the hang of it ... and now I am bullying others
15:19:10 gac410 git cherry master Release02x01 -v will show any patches on Release02x01 that are missing from master. Very helpful.
15:20:05 gac410 big grin Thanks michael. gentle persuasion .. bully free zone here hopefully
15:20:41 gac410 Okay ... 2) Development Discussion. JulianLevens and vrurg both added some things.
15:21:01 gac410 a) https://foswiki.org/Development/CleanUpFoswikiLocales
15:21:50 JulianLevens CleanUp hopefully means remove 'use locale'
15:21:55 gac410 JulianLevens: You want to remove the "use locale" throughout the code ... is this for master?
15:21:55 MichaelDaum can't say much about it. not my field of expertise.
15:22:42 JulianLevens vrurg what have you done with locales in the OO branch?
15:23:37 vrurg JulianLevens: Nothing at all except for making Foswiki locale module compatible with Moo.
15:23:47 vrurg I don't have time for it.
15:23:51 Lynnwood joined the channel.
15:24:17 gac410 The question is the "use locale" in the BEGIN blocks. iirc you wanted to remove all BEGIN blocks if possible.
15:24:49 JulianLevens What about the BEGIN blocks in all modules to conditionally do 'use locale'?
15:25:06 vrurg I still want to remove them. But as soon as we need to replace them with something meaningful.
15:25:41 gac410 I think the conclusion was that the change made to use NFK on every sort() somewhat made locales useless for now.
15:25:41 vrurg JulianLevens: not in OO branch if you want to rely upon LSC.
15:26:25 JulianLevens My point is that we don't, there isn't anything meaningful about them anyway, not since unicode Core
15:26:30 jomo ++ for remove "use locale". OS's locales a notoriously broken anyway....
15:26:50 jomo s/a/are/
15:28:56 gac410 I think someone said that our sort changes: sort { NFKD( $a->[0] ) cmp NFKD( $b->[0] ) } made 'use locale' moot anyway, so we could probably just strip out locale support from master until there is a better implementation.
15:29:21 JulianLevens zactly
15:29:41 vrurg Sort is not the only matter here. What about date formats and similar stuff?
15:30:01 CDot if that's the only occurence of sort, perhaps
15:30:33 JulianLevens The point is we don't currently take advantage of locale based dates anyway
15:30:47 jomo JulianLevens: ++
15:30:47 gac410 CDot ... I went through and channged every sort in core to use the NFKD comparison. MichaelDaum went through and made most of them actually efficient. :D
15:30:55 CDot cool
15:31:28 gac410 and yes, I don't believe our current date code honors locales, so it's just noise in the config & code for now.
15:31:32 CDot does the code actually use locale formatting in any user-facing code? e.g. dates?
15:31:34 vrurg May make a note to myself to saw off evey 'use locale' then? ;)
15:31:58 CDot sounds like you might be able to
15:32:17 vrurg Ok, it was always driving me crazy.
15:32:28 JulianLevens CDot I didn't find any
15:32:28 gac410 CDot: ... re dates, I don't believe so, but someone more knowing should check.
15:32:29 CDot y. Sorry about that ;-)
15:33:13 CDot I can't think of any user-facing code, though I do wonder about knock-on effects on external code, like RCS
15:33:14 gac410 I'd say. 1) Leave Locale in the config, documented as not used by core, in that extensions might try to make use of it, but remove it from the other code.
15:33:46 gac410 hm would the perl "use locale" in any way impact a fork out to rcs? What's the connection?
15:34:01 vrurg Actually dates are to be considered in a proposal. Not only formatting but time zones support would be on some demand too.
15:34:24 CDot if you remove use locale, then the code doesn't respect LC_, does it?
15:34:38 jomo have the used Locale defined in the LSC - yes - later we need grab it and use it. but now via "use locale" - LSC and "use locale" = two differnet things
15:34:40 vrurg CDot: right
15:34:58 CDot but if RCS did use LC_, and emitted dates formatted using the LC_ settings (for example)
15:35:02 MichaelDaum the locales should be about the user's preferences more than the server's
15:35:06 CDot then things might go pear shaped
15:35:35 CDot y, MichaelDaum, right, but LC_ is used by a lot of C code like RCS, diff, and maybe others
15:35:50 gac410 Does anyone have an test cases where they might detect pear shapedness
15:36:06 JulianLevens I didn't find any useful tests
15:36:12 vrurg CDot: easyly fixed. A dedicated call for running subprocesses which would populate %ENV with correct variables.
15:36:14 CDot I think the standard unit tests would, if you ran with the apache server set with a different locale
15:36:34 CDot vrurg: good point - we pass on a "reduced env", don't we?
15:36:52 gac410 hm Setting "use locale" in the perl begin block. and/or UseLocales in the config. Do either of them set the %ENV LC_ parameters, or do we just live with whatever the server gives us.
15:36:56 CDot so if the LC_ settings are filtered from that, it should revert to CTYPE
15:37:00 vrurg CDot: I don't remember now.
15:37:27 CDot y, there's a "SafeEnv" setting in configure
15:37:40 CDot that constrains the env used by subprocesses
15:38:37 CDot na, sorry, that's just the path :-(
15:38:41 vrurg SafeEnv is just a filter. But we may need to add something. Anyway, that's the minor issue. Doesn't worth much of talking.
15:38:54 gac410 JulianLevens: It's your proposal to remove the "use locale" Can you trace through this and update the proposal for 2.2 ?
15:38:57 CDot we do delete @ENV{qw( IFS CDPATH ENV BASH_ENV )};
15:39:07 CDot but not LC_*
15:39:31 gac410 So in that case, the forked programs are using the underlyin OS Locale regardless of what we do in the perl code.
15:40:17 vrurg To my view server must take the least care about locales. As it was correctly stated above, this is a user-level setting. Why should rcs care about it?
15:40:41 CDot vrurg: rcs is a user program
15:41:03 JulianLevens y, but the user is the web-server not the logged in FW user
15:41:11 CDot if the server user has set LC_, that may be a problem. Unlikely, but them most problems are.
15:41:25 gac410 As it stands now UseLocale in the config is EXPERT setting, with a caution that Perl locales are broken, ...
15:41:27 vrurg It may have an impact on rcs output when it fetches a version from the store – yes. But it must use LC_ set based on user language/locale preferences.
15:41:39 CDot gac410: what about adding a checker to configure?
15:41:49 CDot inspect LC and barf if any are set?
15:42:24 gac410 How do we tell the user to proceed? Checker is easy to add.
15:42:32 vrurg The problem here lies in multilanguage setups where different users use different locales. We don't support these well enough.
15:43:10 CDot vrurg: no, it shouldn't use LC_, I think. Eberything is done bytewise. The encoding only matters for posting/rendering.
15:43:11 JulianLevens We don't at all, but we're moving out of scope
15:43:19 vrurg And if server is basing on a single locale – that's no good for users using different one.
15:43:52 gac410 Okay. Conclusions: 1) "Use Locale" in perl code can go away. 2) LC_ in ENV are a complete unknown. So warn if discovered. 3) per-client locales is a completely different proposal for some future Foswiki 9.9
15:44:01 gac410 Does this sound right?
15:44:07 CDot yes
15:44:09 JulianLevens yes
15:44:38 vrurg Ok, the subject is growing, I'll try to summarize in the locales proposal.
15:44:59 vrurg yes
15:45:02 jast if 'use locale' is removed from the code, LC_ affects only third-party programs
15:45:34 gac410 Okay. Is "ExtensionVersionAndCleanup" small, or should we have vrurg discuss the new OO plugin model first.
15:45:40 jast of course with 'rcs' that can cause lots of issues, so the warning should maybe be conditional on RcsWrap?
15:46:22 JulianLevens The proposal already has a summary of missing support, and I'll update the i18n and l10n docs to reflect this
15:46:48 JulianLevens No the extension clean up is not small
15:48:03 gac410 I'd like to cover the OO extensions firs then, and then go to the Extension cleanup
15:48:09 gac410 vrurg: are you ready?
15:48:11 CDot (aside) jast: other external programs exist, such as diff
15:48:40 vrurg gac410: I hope so. :)
15:50:01 vrurg The new extensions are ready to be reviewed. But since I've got the code ready last Friday I think it's too preliminary to have it discussed.
15:50:29 MichaelDaum any EmptyPlugin.pm to look at?
15:50:37 vrurg I think people need too look into it first.
15:50:45 vrurg MichaelDaum: I was just typing about this. :)
15:50:51 MichaelDaum snap :)
15:50:53 vrurg There is no EmptyPlugin as such.
15:51:05 gac410 Is there a converted plugin to review?
15:51:13 vrurg But there is a test case which demonstrates them in action.
15:51:35 gac410 Name of test?
15:51:53 vrurg gac410: It's not ready for converting. ExtensionsTests in Item14152 branch.
15:52:05 MichaelDaum how dow you mean there is no EmptyPlugin as such, vrurg?
15:52:18 vrurg For now the code is just a framework to demonstrate its capabilities.
15:52:30 gac410 (back to locales .. quick aside. FoswikiServerInformation dumps the %ENV (filtered) but omits LC_ ... I'll get a patch to show any LC_ variables as well)
15:53:11 MichaelDaum it would help a lot to get to see it from the point of view of a plugin author ;)
15:53:11 vrurg MichaelDaum: may be I've used a wrong words. There is just no file EmptyPlugin.pm.
15:53:42 MichaelDaum at least a kind of boiler plate
15:53:57 vrurg I think the test case demonstrates it much better.
15:54:02 gac410 https://github.com/foswiki/distro/blob/Item14152/UnitTestContrib/test/unit/ExtensionsTests.pm
15:54:17 MichaelDaum for instance BuildContrib is using EmptyPlugin on the "new" target
15:54:49 jomo MichaelDaum: ++ - the empty plugin is not only an demonstartion - it is a guide, how to write plugins... so, would be nice to have one...
15:54:57 vrurg EmptyPlugin is for end-user to have a template. But before getting to this point we would have to get some infrastructure around the framework in the core to provide support for user code.
15:55:40 gac410 vrurg: The blob url I just pointed out. Can you suggest what to read in there and how? TBH I just don't follow this enough to make any sense of it.
15:56:07 MichaelDaum UnitTestContrib/test/unit/ExtensionsTests.pm doesn't tell me what I am looking for ... at least not on first sight
15:56:48 gac410 +1 vrurg, you are so deep in the OO code, that you've left me behind. I just don't understand what the example test is trying to show.
15:57:18 gac410 Sorry to be thick, but I just don't get it.
15:58:03 vrurg I'll try to think out a good EmptyPlugin code when the core is not really ready for it.
15:58:36 jomo i have one basic quiestion. at least basic for me. I checked out today first time the branch Item14152. And i'm unable to run it... so need some advice "how to" .. (maybe later in the "foswiki" channel)
15:58:39 gac410 So another question. Does this model "sit along side" the existing extension model? all extensions would continue to run (with caveats of other API changes in OO branch)
15:59:57 vrurg But generally test case kinda comes with the proposal page. smile The key point is _genExtModules which generates an empty module and inserts additional code into it if supplied in parameters.
16:00:22 vrurg gac410: Yes, they can co-exists until we need it.
16:01:29 vrurg Back to the test. _setExtDependencies lets one to define the order in which plugins are organized.
16:01:48 vrurg is doing this wrong.
16:02:13 vrurg I was planning to comment the test code anyway. Simply got no time for this yet.
16:02:54 jomo has quit: Quit: jomo.
16:03:33 gac410 I hate to say it vrurg, I know you've been doing a immense amount of work, but make believe I know nothing about perl, Even if you had the absolutely minimum "plugin" that just registered a single macro. that would help
16:03:34 MichaelDaum vrurg, order of plugins is so rarely useful in real life
16:03:41 vrurg I'd like to ask everybody to use https://foswiki.org/Development/OONewPluginModel for comments and suggestions to make the subject ready for the next meeting.
16:03:50 jomo joined the channel.
16:04:58 gac410 ie, a plugin which registers %HELLOWORLD% which emits "hello world" ... so I could see the basic model of a new macro. Then we could move onto the callbacks, etc.
16:05:03 vrurg gac410: This is where we would need support from the core. Though test_tag_handlers is about macros.
16:05:14 MichaelDaum I am tempted to say that, if your system is depending on a certain plugins order, then your solution smells.
16:06:05 vrurg MichaelDaum: Thay may be not true. No, I don't rely on the order. But I allow an extensions to be dependant on another extension.
16:06:28 MichaelDaum in what sense dependant?
16:06:47 MichaelDaum like "use FooBarPlugin"?
16:06:52 CDot dependant in what sense? In the evaluation order? If so, evaluation order of which listener/callback?
16:07:08 vrurg Nah... Just to define the order of calling methods where it matters.
16:07:29 jomo what is purpose of the current: $Foswiki::cfg{PluginsOrder} =....
16:07:34 gac410 The beauty of the registered macros is that they almost never depend upon plugin order. They follow the inside/out left/right. it's only the callbacks and mostly the old obsolete commonTagHandlers that get into plugin ordering. And that is really ugly and to be avoided.
16:08:01 gac410 jomo, mainly for old extensions that use the common- tags handler, or other callbacks where callback order is important.
16:08:02 vrurg Yeah, for callbacks too. If there is more than one registered callback handler.
16:08:06 MichaelDaum macros certainly don't need a plugin order. it is callbacks.
16:08:17 vrurg jomo: I don't use it.
16:09:00 vrurg gac410: That doesn't change. The only big difference is the way macros are registered.
16:09:14 MichaelDaum the only use case where current PluginsOrder is required that I have found is that GenPDF plugins need certain other plugins to have processed the resulting html before they start creating PDF from HTML
16:09:36 gac410 SpreadSheetPlugin is another one sensitive to ordering.
16:09:39 jomo i just commenting - we ALREADY using plugin-orders - so probably vrugs "ordering" isn't bad too :)
16:09:49 CDot there is sometimes an ordering between TML. For example, some table processing plugins require SSP to have completed mangling before they "parse" TML tables.
16:10:28 MichaelDaum I don't say it is of no use. It is of rare use up to the point we should better not care about any order.
16:10:49 CDot SSP without relative table addresses is fine, but SSP with relative table addresses is probably more common than it should be.
16:10:50 MichaelDaum It would rather be better code does not depend on its order other than the way you hacked it into your text editor
16:11:20 CDot yes, it's very ugly :-(
16:11:40 gac410 Anyway, we are down inspecting the lichen on the trees in the forest, and I still don't even see the darn forest :D
16:11:42 vrurg So, what I basically done is: a) macros are registered against methods on extenion objects; b) extended callbacks to be way more flexible and don't rely on positional parameters; c) implemented class overriding;
16:12:29 jomo just need cleanup the terminology first - IMHO plugin = macro. We have: Plugins, Extensions, Contribs... so when vrug talks about an "plugin" what this means? .
16:12:55 MichaelDaum jomo, a HelloWorldPlugin.pm
16:13:01 MichaelDaum whatever is in there
16:13:11 vrurg A fancy addition is support of individual method overriding if supported by a core class.
16:13:12 gac410 Extensions is an umbrella. Generally Plugins have active perl code. Contribs just add templates, topics, etc.
16:14:01 CDot Plugins can also register macros
16:14:07 gac410 of course there are many exceptions but that's how I like to think of it.
16:14:14 MichaelDaum vrurg, okay. so a) is another way to say registerTagHandler?
16:14:45 gac410 and b) is the handlers but with new calling conventions?
16:14:51 vrurg gac410 is correct here. Extensions to have it all in one place. Though the current code is mostly covering plugins functionality but this is also about future infrastructre built around.
16:15:12 gac410 and c) is things like Mappers, Login Managers, etc.
16:16:56 vrurg MichaelDaum: yes and no. Yes – use tagHandler MACRO => sub {}; to have it registered (though it then calls an Foswiki::Extensions method which is available for use too); No – the sub would be called as an extension method; i.e. – provided with $this as the first parameter.
16:17:34 gac410 vrurg, if you have some time later this week, can you help me write a new Extension that implements a %HELLOWORLD% ... I know you are overwhelmed but I'll try to work with you to explain if you want the help.
16:17:43 gac410 But you need to teach me :D
16:17:48 vrurg gac410: Rather yes. I have introduced callback into the OO branch for a while now. Simply wrapped them with better support code.
16:18:47 vrurg gac410: Sure I will. Anyway, I need to document what's done. As long as it was a moving target until the last few days I was avoiding any docs.
16:18:51 gac410 Okay. So table this and I'll work with vrurg to have an example operational for the October 3rd release meeting? Is that fair 'nuf
16:19:14 JulianLevens y
16:19:18 MichaelDaum we will see what you mean looking at a first simple plugin written that way. thanks.
16:19:26 gac410 work for everyone? And we can pick up JulianLevens extension cleanup proposal for a bit.
16:19:31 vrurg gac410: BTW, mappers and login managers I hope will be replaced with class overriding.
16:19:59 jomo (or roles) :)
16:20:08 vrurg jomo: It's done with roles.
16:20:10 gac410 right. That's what I was referring to with your c) class overriding
16:20:34 jomo great! :)
16:20:53 gac410 Okay ... https://foswiki.org/Development/ExtensionVersionsAndCleanUp
16:22:29 MichaelDaum JulianLevens, you asked what VERSION and RELEASE is currently being agreed on
16:22:34 vrurg jomo: If you have some experience in creating plack middleware I would probably have a few questions to you.
16:22:51 MichaelDaum VERSION should be clear.
16:23:09 MichaelDaum RELEASE is the date of the release in standard Foswiki date format, e.g. 19 Sep 2016
16:23:32 gac410 VERSION is a formal "perl version string" with very strong recommendation on "simple decimal" not dotted triplet.
16:23:34 jomo vrug ok - after this in the "normal" channel... i need also help with the installation...
16:24:10 JulianLevens Ok, but how should I replace $REV$
16:24:36 MichaelDaum where did you find it: in VERSION or RELEASE?
16:24:43 JulianLevens I built all 350 or so published extensions and many aborted due to $REV$
16:25:09 JulianLevens I suspect it's in both at least somewhere
16:25:10 vrurg JulianLevens: $REV$ is a cvs tag.
16:25:14 gac410 Re RELEASE, Date format is all over the place. I think there are differing opinions on a standard date.
16:25:46 MichaelDaum gac410, yes yes. But at some point we have to make a clear recommendation.
16:26:34 gac410 I agree MichaelDaum ... +1 +1 +1 but I think other dev's use a different format :(
16:26:45 JulianLevens OK, I could fix and standarize the date, in $RELEASE, should I?
16:26:47 vrurg Actually, this is no good in use stringified dates. RELEASE must be a timestamp.
16:27:29 vrurg If it's not too late to suggest...
16:27:32 gac410 Comparisons always made with VERSION. RELEASE is supposedly for display purposes. Though the code Foswiki::Dependency attempts to do the comparisons.
16:28:38 gac410 VERSION conforms with the PERL version string standards with a recommendation on decimal. version->... functions to compare when possible.
16:28:50 MichaelDaum xactly. RELEASE is only there for humans. no need to be timezone safe.
16:28:50 vrurg This would put us back to locales discussion. smile With RELEASE in UTC timestamp we can easily display it in any language and time zone when needed.
16:29:21 JulianLevens STOP!
16:29:36 MichaelDaum vrurg, you seem to lean towards complicated solutions, are you ;)
16:30:09 gac410 yes please. RELEASE is the "plugin authors" idea of the date he built/released the extension. code ignores it if possible and uses VERSION for comparisons.
16:30:09 JulianLevens Phase 1: change code in the GitHub repo of all Extensions
16:30:27 vrurg MichaelDaum: absolutely no! Complicated is when I need to parse a date to get timestamp. Otherwise it simplifies my life.
16:30:43 MichaelDaum vrurg, do not parse RELEASE
16:30:45 gac410 You should NEVER need to parse RELEASE. just display it
16:30:59 JulianLevens Specifically, Convert to use PackageForm from the 'info' table
16:31:27 JulianLevens Clean-up $VERSION & $DATE as best I can :)
16:31:49 JulianLevens Standardize remaining pieces of the 'info' table
16:32:00 vrurg JulianLevens: sorry, last time! – MichaelDaum , gac410 – what if a user would like to see a localized date? I'm just thinking of different possibilities.
16:32:09 MichaelDaum JulianLevens, may I ask you to not change code in CoordinateWithAuthor state?
16:32:13 gac410 RELEASE can also be "November" or "My-best-one-yet" or "xenial xersus" It's a displayed field. and would be dangerous to parse.
16:32:19 JulianLevens Clean-up dependencies
16:32:57 jomo just a question. Foswiki shows the extansions in an table. I want sort the table "by the release-date" of the extension. Will this work?
16:33:13 JulianLevens MichaelDaum: I'd rather change them as well, I'm not making any functional changes
16:33:15 gac410 JulianLevens: If "coordinate with author" is set, I think we FIRST need to determine that the author has abandoned the work before we go changing it.
16:33:22 JulianLevens Or indeed code changes
16:33:34 MichaelDaum JulianLevens, please do NOT change em.
16:33:58 MichaelDaum this was a major problem once when Babar tidied each and every perl code
16:34:20 JulianLevens Why did that cause a major problem?
16:34:25 gac410 It is the Authors privilege to determine setting of CoordinateWithAuthor.
16:34:47 gac410 JulianLevens: because some authors do NOT want our TIDY settings.
16:35:15 MichaelDaum ... and f*ed up their local versions enforcing complicated pointless merges
16:35:21 gac410 And got very irate. There is no reason to tidy everyone's code or make wholesales changes unless the author has abandoned the work.
16:35:37 MichaelDaum +1
16:37:12 gac410 I know it will be painful, but for apparently abandoned extensions with Coordinate* set, the author deserves a courtesy contact ... let them know that we intend to update the code.
16:37:40 gac410 With Coordinate* NOT set, then have at it :)
16:38:08 JulianLevens Ok, for now I'll create a report of issues and recommended changes
16:38:22 JulianLevens and repair those I can
16:38:30 MichaelDaum thanks
16:38:36 JulianLevens Emailing to the authors of those I cannot
16:38:54 jomo on the other side - in many opensource projects simply you MUST use some "perl-tidy" settings (by the rules) - and have commonly formatted code isn't bad at all...
16:40:21 vrurg jomo: You cannot demand this from plugin developers because it's their good will to publish the code on github.
16:40:23 MichaelDaum we don't have a perl tidy problem anymore. this is one of the phases we went thru in the early Foswiki days.
16:40:50 MichaelDaum however we learned a lot during the course
16:41:07 JulianLevens Note that I would like to re-build all extensions and re-load them onto f.o. (to eliminate inconsistencies), but similar objections ref CoordinateWithAuthor
16:41:12 MichaelDaum i.e. how to deal with the plugins community, and stuff left behind
16:42:11 JulianLevens However, longer term I'm looking to auto-build and load plugins esp ref each release and to enable installing the Extension apt to the FW release
16:42:12 gac410 JulianLevens: That might be a challenge. There are a few extensions that are not in github repo, and some that have had manual patching with obsolete code in github. It's ugly.
16:42:53 JulianLevens There are 348 published (on f.o) Extensions that I can re-build (unless any of those are broken)
16:43:26 JulianLevens Another 200+ are in GitHub in various states I will report on those as well
16:43:26 gac410 Some of them for sure have code in zip/tar files that is NOT on, or inconsistent with github
16:44:00 JulianLevens Yes, I want to compare the zip, tar against GitHub and report those as issues
16:44:40 MichaelDaum guys gotta leave
16:44:54 vrurg too. Work is awaiting.
16:44:59 gac410 We probably also ought to recommend a github tag approach, maybe consistent with VERSION
16:45:12 vrurg Thenk for the discussion everybody! bbl
16:45:30 gac410 also has commitments shortly. So lets wrap.
16:45:55 gac410 Anyone. Please checkout the bootstrap changes in Item14180. It's a critical part of our release and I want to merge for 2.1.3
16:45:59 JulianLevens Sure, thanks everyone
16:46:13 MichaelDaum good discussion.
16:46:26 gac410 Thanks everyone. This was an excellent meeting. Good progress in several areas
16:47:04 gac410 Also if you run a fcgi site, might want to consider applying the patch for Item14195
16:47:43 MichaelDaum is now known as MichaelDaum_
17:14:25 jomo has quit: Quit: jomo.

BasicForm edit

TopicClassification Select one...
TopicSummary
InterestedParties
Edit  | Attach | Print version | History: r5 < r4 < r3 < r2 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r5 - 19 Sep 2016, 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