Release Meeting: 11 Jan 2016

Details

1. Urgent Task review

  • 13917 (Closed): NameFilter not working on 2.0 / 2.1 if configure reset to default is used. Some brief discussion, no resolution. (Security task currently)

2. Development Discussion

Review of features / Feature branches

We had a general discussion of the state of our proposals - FeatureProposals. We need to do a review and get these appropriately classified, so we have a better picture of what needs review and what is potential for future releases.

  • SupportAllMacrosInTemplateTopics Merged To Core: Support all macros in template topics 13909 (Waiting for Release): Support expansion of standard macros during topic creation from template.
    No concerns raised, 7 more days for approval.
  • ImproveSupportForComments Merged To Core: Support comment syntax in topics and topic templates 13905 (Waiting for Release): I'd like a way to make FW-level comments in topics.
    Some unrelated discussion of template comments.
    <
  • AddValidationsToURLPARAMMacro Parked Proposal: URLPARAM should be able to validate the browser input 13859 (No Action Required): Implement AddValidationsToURLPARAMMacro
    CDot thinks that inline alert is the way to report validation errors. Anything else is not KISS.
  • ImproveOOModel Under Investigation: Foswiki OO model need to be more comprehensive and unified. 13897 (Being Worked On): Implement ImproveOOModel proposal.
  • DeprecateErrorPm Under Investigation: Deprecate Error.pm
    These two features drew the bulk of the discussion. Could these features be ready for a 3.0 release in summer, or where will it stand. There is general consensus that the move toward Moo and more formal object design is the way to go. vrurg felt that it would be another couple of months before he will know. The conclusion is that if the initial results (migration of core and test framework to Moo) are promising and can be a "strong base" for 3.0, it will be an all-hands-on-deck to move toward the OO architecture. At that point, we will need a dual merge strategy, merging feature branches into master and the Moo master.

3 Next release 2.1.0

  • Feature Freeze: TBD
  • Release from: master
  • Branch date: TBD
  • Beta start: TBD
  • Release target: Summer 2016

Next meeting - - Monday 25 Jan 2016 1300Z — ReleaseMeeting02x01_20160125

IRC Log

(08:38:23 AM) gac410: Hi everyone.   My apologies for starting off the new year with a botched schedule.
(08:39:00 AM) CDot [~crawford@foswiki/developer/cdot] entered the room.
(08:39:15 AM) gac410: 2.1 Beta 1 is uploaded to Foswiki.org.   Michael, should we do an announcement to foswiki-announce email list?  or just keep it a quiet beta.
(08:40:17 AM) MichaelDaum: I am for openness
(08:40:30 AM) gac410: We found one bug yesterday.   It can become a security bug if you attempt to reset NameFilter to it's default setting.   It basically breaks the regex and allows anything.  But it's broken on 2.0 as well.
(08:40:49 AM) MichaelDaum: thats probably more pressing than working on the beta?
(08:41:41 AM) gac410: I'll get back to tracing after the meeting.   But more importantly,   unicode topic names allows for some very creative topics 
(08:42:29 AM) MichaelDaum: ay
(08:42:32 AM) gac410: even with a workig filter,   1)  Combining marks can make a real mess of the names,  and 2)   non-alpha graphics can be used as well.
(08:43:12 AM) CDot: who are we to dictate? If it passes the NameFilter, it's valid IMHO
(08:44:08 AM) gac410:   http://trunk.foswiki.org/Sandbox/Jomo.▁▂▃▅▆▇
(08:44:42 AM) CDot: :-)
(08:45:02 AM) gac410: I'm not saying we should dictate,  but that further controls might be nice to provide should the site administrator desire.
(08:45:40 AM) gac410: And with combining marks:    http://trunk.foswiki.org/Sandbox/Jomo/̴%CC%B5̶%CC%B7%CC%B8̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̃̄̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿͂͆͊͋͌̕̚Ι%CD%8F͓͔͕͖͙͚͐͑͒͗͛ͣ͘͜͟͢͝͞͠͡
(08:45:43 AM) CDot: you'll be wanting us to filter out swear words next :-(
(08:46:00 AM) gac410: No.   absolutely not
(08:47:02 AM) gac410: Okay   anyway,  issue raised.   The bug is the doubling of backslashes which I will work on.
(08:48:48 AM) gac410: I didn't do an agenda for today.    with 2.1 beta out,  shall we discuss any pending feature proposals for 2.2 /  3.0 ?
(08:51:36 AM) gac410: Okay,  for proposals where "14 day rule applies"   there are 21 of them.    I propose that if the developer appears to be missing, we "Park" them,  and ask that everyone else set proposals to either Accepted or as desired,  to clean up the list.
(08:51:39 AM) CDot: only interested in the %TMPL: and #{ proposals, both of which have had lively discussion
(08:52:00 AM) CDot: cleaning up is a great idea
(08:54:03 AM) gac410: ones with concern raised,  can everyone look them over to decide if they are either rejected,  withdrawn,  or need to go to community vote.   
(08:54:31 AM) CDot: can you give us a list (or a pointer to a search that generates one)?
(08:54:59 AM) gac410: Lets try to get the "Feature proposals" page to a state where it can be an agenda for these meetings.    http://foswiki.org/Development/FeatureProposals
(08:56:44 AM) gac410: UnderInvestigation category is massive,     and then http://foswiki.org/Development/FeatureProposals#Accepted_Feature_Proposals    really ought to be our "menu" for future releases. 
(08:57:55 AM) gac410: I don't think that page is ready to review in a meeting yet ... waste of time until it's cleaned up.    So let's discuss the active work.   
(08:58:25 AM) gac410: 1)   TMPL:macro    2) Comments    3)   vrurg's   restructuring 
(08:59:31 AM) jomo: vrurg works on the DeprecateErrorPm but only in his own branch - so don't know what to do with the proposal... should i withdraw it?
(09:00:16 AM) CDot: therein lies the path to a fork.....
(09:00:35 AM) gac410: Well it's a branch in the foswiki repo,  not a fork. 
(09:01:27 AM) gac410: So it could be merged.   but is part of a large restructuring.    Right now he is really just experimenting I think.
(09:01:56 AM) gac410: But he's not here to discuss.   I think he realizes that merging should we accept the proposal would be a massive effort.   
(09:02:44 AM) JulianLevens entered the room.
(09:03:44 AM) gac410: For CDot's  http://foswiki.org/Development/SupportAllMacrosInTemplateTopics     That seems to to be a needed and relatively straight forward enhancement.    7 days into the timer.  
(09:04:28 AM) gac410: *much* cleaner than the TWiki hack of  "EOTC__" as a macro prefix to cause expansion.  
(09:04:44 AM) CDot: the only debatable point is whether %TMPL: is the right syntax, since it somewhat conflates the skin template syntax with the macro syntax
(09:04:59 AM) CDot: but it *feels* right....
(09:05:28 AM) gac410: hm   well it does move the macro into the template expansion domain doesn't it?
(09:05:47 AM) CDot: well.... sort of. Template topics are a bit odd.
(09:05:54 AM) gac410: y for sure  :)
(09:06:07 AM) CDot: they are really like a topic that is rendered in two steps; one static, one dynamic
(09:06:35 AM) CDot: but the syntax seems fairly natural to me, so tempted just to go with it.
(09:07:19 AM) gac410: well 7 more days for the concrete to harden. 
(09:07:25 AM) CDot: :-)
(09:07:48 AM) Lynnwood [~Lynnwood@foswiki/developer/lynnwood] entered the room.
(09:08:50 AM) gac410: The topic comments is much more difficult.   http://foswiki.org/Development/ImproveSupportForComments
(09:10:12 AM) gac410: I tried a template comment on foswiki.org,  and it totally broke the rendering of our download topic ... So maybe I don't understand comments  
(09:10:20 AM) jomo: have no concerns... :)
(09:11:24 AM) gac410: http://foswiki.org/Download/FoswikiReleaseViewTemplate    has a verbatim class="foswikiHidden"  (NOT in a comment)   that hides a bunch of transcluded blocks
(09:11:40 AM) CDot: I don't think the comments are all that difficult; we've ironed it out now
(09:11:59 AM) CDot: gac410: so? That's OK
(09:12:19 AM) gac410: I tried converting that to %{     and the /verbatim to   }%       we don't need them in the download topic.
(09:12:31 AM) CDot: that won't work
(09:12:40 AM) gac410: As I said.   I don't undersand.
(09:12:44 AM) CDot: :-)
(09:13:24 AM) CDot: %{...}% is a *real* comment; anything in them plays no further part after the comment is removed
(09:13:50 AM) CDot: %{ verbatim>}% leverages the fact that in a normal topic view, %{...}% is *not* a comment
(09:14:05 AM) CDot: so the %{ verbatim>}% string persists into the renderer
(09:14:08 AM) gac410: Right.   But they are accessed using %INCLUDE section=    which processes the template topic ignoring themplate 
(09:14:58 AM) CDot: but when the topic is used as a skin template, skin template syntax rules apply, and the %{ verbatim>}% gets removed
(09:15:24 AM) CDot: it's basically just a way of making the skin template topic carry it's own documentation
(09:15:40 AM) gac410: if I %INCLUDE  a topic section ... so I'm reading the template topic as a topic,  not as a template,     won't include see the %{  }%   blocks
(09:16:02 AM) CDot: you will see them, yes
(09:16:07 AM) gac410: Just like viewing a template topic displays the %{  }% 
(09:16:15 AM) CDot: because %{ is not a comment delimiter in a normal topic view
(09:17:32 AM) gac410: Right.  That is what I expected.   So I should have been able to convert the (not a comment!)   verbatim class=foswikiHidden>     into a %{ ... hidden from template }%  block,  and still include from it.
(09:17:50 AM) CDot: yes, you should
(09:18:20 AM) gac410: okay.   So maybe it's some other syntax issue.   I'll review and then ask you some other time. rather than hijack the meeting.
(09:18:29 AM) CDot: y
(09:20:33 AM) gac410: So back to your proposal.   *topic* comments.   should 1)  Macros be active within them?    2)  Should * Set blah=   preferences be active in them.
(09:24:15 AM) jomo: comments should stop expensive macro executions... aren't?
(09:25:38 AM) gac410: Right.   But, if the purpose is to hide foswiki internals,   beyond just hiding documentation,   runtime %SET macros might be of some benefit to process from within comment blocks.
(09:26:35 AM) gac410:   * Set  statements are easily hidden in %META,  but runtime %SET have no way to be hidden.   
(09:27:14 AM) gac410: Anyway,  I should probably add that to the discussion topic.   and let it play out there.
(09:28:09 AM) gac410: Okay,  one other proposal http://foswiki.org/Development/AddValidationsToURLPARAMMacro    has really gathered no discussion, beyond an irc discussuion with vrurg a while back.
(09:29:32 AM) CDot: wow, first reaction to that is "urgh!"
(09:30:35 AM) gac410: :)    We have all those wonderful checkers in configure.    And I wondered why we shouldn't have something similar for wiki applications.
(09:30:46 AM) CDot: while I like the idea of validators on URL params, the idea of rewriting them..... stinks
(09:31:38 AM) CDot: %URLPARAM{"xyz" expect="integer"}% - but then what do you do if it in't
(09:31:43 AM) gac410: it was in hindsight after some xss scrubbing.   when I realized.   "We are scrubbing a field that really has only two valid values  "Yes" and "no"  
(09:33:05 AM) gac410: that was where the experiment got fuzzy.     1)   Throw an "oops",   2)  Return an inline  alert,   3)  Collect them and report in a validation report of some sort
(09:33:30 AM) CDot: has to be an inline alert (which is a shaky concept at best. I know)
(09:33:41 AM) gac410: After discussion with vrurg,  it seemed we needed to allow any of those options.
(09:34:11 AM) CDot: why? what other macros report failures through an oops?
(09:34:25 AM) CDot: or a validation report?
(09:34:44 AM) gac410: If the urlparam say was being used to create a topic,   an inline report would just end up in the topic.
(09:35:03 AM) gac410: And oops, means you get one... oops ... error ... oops ... at a time.
(09:35:03 AM) CDot: yuck
(09:35:49 AM) gac410: yeah.   So collecting the errors into a single oops   seems likely to be needed.
(09:35:51 AM) CDot: still think an inline alert would be appropriate
(09:36:06 AM) CDot: anything else is not KISS.
(09:38:10 AM) gac410: yeah,  I was having trouble figuring out where to actually collect them   Probably needed to add something hanging off $session->{urlerrors} or something
(09:38:28 AM) gac410: There is precedence for some other macros that I've found   though it's ugly.
(09:39:35 AM) gac410: Anyway,  it's a proposal that needs more discussion.
(09:40:01 AM) gac410: Any other proposals anyone wants to bring up for discussion?
(09:42:19 AM) gac410: Okay,   For our "Next release" ...    2.2 planned for sometime in the summer?    Does that give everyone enough time to get some interesting work done?
(09:42:20 AM) jomo: would be nice to get some more comments to the QuoVadisPsgiFoswiki... just for brainstorming... not here and now - but would be nice to know what the team want to achieve - in more details...
(09:43:27 AM) MichaelDaum: jomo, I think I made my point clear
(09:43:59 AM) MichaelDaum: I consider psgi + moo the future of foswiki
(09:44:23 AM) MichaelDaum: as well as sass
(09:45:07 AM) gac410: So as the current RM,    a big question is how do we accomplish a change like this without another 4-year black hole of development. 
(09:45:31 AM) gac410: As vrurg said,  merging will be hell if we keep adding incremental work to master.
(09:45:56 AM) CDot: that's the nature of collaborative dev
(09:46:14 AM) MichaelDaum: we need more of us to help vrurg
(09:46:26 AM) MichaelDaum: he is definitely in hero mode atm
(09:46:28 AM) CDot: the rewrite to use psgi is not a complete rewrite of foswiki
(09:46:42 AM) CDot: it's a rewrite of the engine layer (as I understand it)
(09:46:58 AM) gac410: vrurg is doing a rewrite to Moo  with a complete object restructuring.
(09:47:00 AM) CDot: plus a few bits to cushion where cgi has been abused
(09:47:53 AM) MichaelDaum: psgi and moo are two separate undertakings though not independent of each other. 
(09:48:27 AM) CDot: moo produces perl objects; I don't understand why objects can't move to moo incrementally
(09:48:34 AM) gac410: And Lavr raised a concern  ... of course because Centos doesn't have Moo available. 
(09:48:48 AM) CDot: seems fairly straightforward to me (albeit a big job)
(09:48:52 AM) MichaelDaum: Moo is available as pure-perl afaik
(09:49:01 AM) jomo: sry - i have  a pinter here.. ;( was AFK.. - yes, the only who commented nicely is MichaelDaum :)
(09:49:04 AM) CDot: moo is pure perl
(09:49:06 AM) jomo: painter
(09:49:13 AM) MichaelDaum: so Kenneth's concerns are easy to address
(09:49:34 AM) MichaelDaum: he did not re-comment though
(09:50:24 AM) gac410: Anwyay,    for a Summer release.    we could.  1)   Continue with incremental work with all the deferred changes from 2.1.  Michael, a lot of them were yours.
(09:50:38 AM) CDot: anyway, most of the existing foswiki objects could move to moo with barely a blink
(09:50:58 AM) gac410: or 2)  All hands on deck... help vrurg to the Mooification and PSGIfication   and that becomes 3.0 in summer?
(09:51:07 AM) gac410: or 3)   Both in parallel,  
(09:51:08 AM) MichaelDaum: Moo-ification of Foswiki would make an excellent marketing spash as well
(09:51:18 AM) CDot: at least, the ones where I was able to maintain strict encapsulation
(09:51:33 AM) MichaelDaum: yea some stuff is very un-oo-ish
(09:51:53 AM) CDot: i think there has to be some detail decisions about how moo is used before lots of work goes in
(09:52:13 AM) JulianLevens: vrurg agreed with me that the 1st phase of Moo is establishing a good base; not everything in one go
(09:52:21 AM) CDot: for example, so all field accesses have to move to accessors? That would be a hell of a lot of rewriting :-(
(09:52:40 AM) jomo: i don't think than the OO restructulasition (with some architectural changes) is real timing for the summer... just IMHO...
(09:53:20 AM) MichaelDaum: too bad he is not online atm, is he?
(09:53:21 AM) CDot: plus there are places where we do things that are in the spirit of OO, but leverage some of perl's features to do things more efficiently
(09:53:22 AM) JulianLevens: I think a foundation can be established for the summer
(09:53:43 AM) gac410: From a git perspective,   we could continue adding features to master,  and merge them with some pain into his Mooification branch.  
(09:53:58 AM) CDot: so I would expect a move to Moo will slow FW down by quite a bit, until re-optimisation can be performed
(09:54:13 AM) gac410: And then rename the Moo branch to master when we are ready.
(09:54:32 AM) CDot: fine, as long as all the tests pass :-)
(09:54:56 AM) vrurg entered the room.
(09:55:03 AM) CDot: speak of the devil
(09:55:07 AM) jomo: :) :)
(09:55:10 AM) vrurg: Hi there.
(09:55:17 AM) gac410: vrurg appears to be working on the tests as well,  which is excellent.  
(09:55:27 AM) vrurg: Sorry, don't have much time but few minutes.
(09:55:39 AM) CDot: gac410: is there a log for Vadim to read?
(09:55:50 AM) gac410: no not yet. ... this channel isn't logged
(09:56:02 AM) ***gac410 wonders if we ought to hold release meetings in the main channel.
(09:56:04 AM) CDot: c+p to pastebin?
(09:56:11 AM) gac410: one moment. 
(09:56:23 AM) JulianLevens: http://pastebin.com/LyTZ6t9w
(09:58:21 AM) gac410: you beat me  :)
(10:00:44 AM) gac410: So the question vrurg  is  could your mooification effort be a foundation for a July/August  3.0 release,     
(10:01:19 AM) vrurg: I haven't read the discussion all the way down but have a note to CDot : moving to Moo isn't that simple. It's model is pretty much different from Perl's default. Look at Foswiki::Address which I was working on just yesterday. In Moo processing of parameters and object initialization are separate whereas in the Address it's mixed and spread across several subs.
(10:02:56 AM) CDot: ok, but (1) moo and default perl objects can coexist (2) a moo object can subclass a default perl object
(10:03:03 AM) CDot: so a change can be done incrementally
(10:03:05 AM) vrurg: gac410: I hope so. Depending on the time I have it could either be just a solid base for redesign of the core or something more. I hope for more.
(10:03:13 AM) gac410: I think what we want to avoid is a multi-year black hole of develompent.     So can there be a step-wise  migration
(10:03:43 AM) vrurg: CDot: but that's the worst way to do it and it kill the whole point of the job.
(10:04:34 AM) ***CDot puts his hands up and turns away. If it can't be done incrementally, then hero is the only way.
(10:05:09 AM) gac410: CDot passes hero hat to vrurg. ...   He wore it long enough with the Configure redesign  :D
(10:05:39 AM) CDot: gac410: and for many years before that. Since about 2004, I think.
(10:05:47 AM) gac410: y.   :)
(10:05:57 AM) JulianLevens: Hero not necessary? We all seem to be in  favour of this and indeed want to get there; so establish a great base and then quickly move to finish the job soon after
(10:06:11 AM) MichaelDaum: JulianLevens, +1
(10:06:15 AM) vrurg: gac410: If nothing changes I get the whole core+test framework migrated in ~2month. By then we'd better work out a new model for the OO based API, agree on the ways of moving plugins into OO paradigm and exceptions structure.
(10:07:05 AM) CDot: sounds great
(10:07:39 AM) CDot: note that what changes do occur tend to be small, so should not be hard to port
(10:07:46 AM) vrurg: With clear plan I'd say it'll take another 2 month to get 3.0 beta out. For these 2months 2.0 has to be in feature-freeze state.
(10:07:54 AM) vrurg: 2.x, actually...
(10:08:14 AM) CDot: however it's not clear to me why you are not tackling this on a subsystem basis
(10:08:37 AM) CDot: e.g. start by moving the user management over, then the store, then.....
(10:09:02 AM) JulianLevens: y, I was looking at Meta last year and thinking about redesign and dreaming of using Moo
(10:09:13 AM) JulianLevens: Could just start with that
(10:09:28 AM) CDot: meta is a nightmare piece of knitting. Possibly the worst place to start :-(
(10:09:36 AM) JulianLevens: Might not be the best starting point though
(10:09:56 AM) gac410: before we lose you ... vrurg,  is there a time/timezone that would work better for you for discussions on your efforts.
(10:09:56 AM) CDot: it's the place I put things when i couldn't figure out a better place :-(
(10:09:59 AM) JulianLevens: y, it requires some serious untangling as well
(10:10:21 AM) vrurg: CDot: Reason 1: I'm not that familiar with the internals; 2 – I want working tests, so for now I depend on their order; 3 – I learn the core that way too. Not the best reasoning, but it keeps me motivated.
(10:11:06 AM) CDot: ok, fair points. The tests overlap in some places, but are generally per-subsystem
(10:11:25 AM) CDot: the subsystems themselves are in subdirs of Foswiki
(10:12:16 AM) gac410: I'd say we treat vrurg's  branch to be the   "MooMaster" branch  :D    and rather than a feature freeze,  we can try to merge small features into both master an MooMaster?  
(10:12:17 AM) CDot: e.g. Foswiki/Store, Foswiki/Users, Foswiki/Prefs, Foswiki/Search
(10:12:32 AM) vrurg: gac410: I'm in Miami. Considering our Europeans this period would be the best anyway. It's just the time I work with my Ukranian team so might be busy sometimes.
(10:13:38 AM) CDot: FWIW it's essential that other people do work on the Moo branch. if we end up with only Vadim understanding it, we are lost.
(10:13:57 AM) CDot: so merging to both master and moo is the only way
(10:14:02 AM) gac410: +1
(10:14:33 AM) gac410: vrurg,  so the "MooMaster"  is currently  remotes/origin/Item13897 ....  maybe we should rename it to be obvious :)
(10:14:48 AM) ***vrurg though that the branch is just a playground.............
(10:14:58 AM) gac410: They are whatever we want them to be.  
(10:15:00 AM) vrurg: Yes, it is. 
(10:15:21 AM) vrurg: Shall we make it more meaningful name then?
(10:15:56 AM) gac410: If the playground is promising we can merge it,   or we can eventually rename it to be the new master.    Though not sure how that works out when people pull 
(10:19:05 AM) vrurg: gac410: Actually I was always opposed to the model where the master is the main release line. To me it looks more clear when it's more tree-like with, say, major release branching from the master and minors are branching from their respective majors. But that's something from another topic and not a big matter whatsoever.
(10:19:20 AM) gac410: Why don't we leave this that ... dev's should review Item13897 branch,  and vrurg,  you let us know when you want everyone to "pile on"  
(10:20:41 AM) gac410: And when you are ready,  we'll have to figure out a rename that will still work with posting commits to tasks.
(10:21:34 AM) vrurg: What I'd like to have for the moment is the plan I mentioned above. Unfortuntanely, I don't have clear overview of the core to build plans like that. I do want plugins to become objects but this pulls out the question on handling documents/inclusions where me expertise is barely above zero.
(10:21:38 AM) gac410: I have to review FoswikiOrgPlugin ...   currently it expects a branch to be a task ID
(10:23:41 AM) gac410: So what do you need from us.    It seems we want to go in your general direction.  But it's early enough you need to steer for a bit more to flesh things out.
(10:26:01 AM) gac410: Anyway ...   any further business?     Shall we wrap this up?  
(10:26:31 AM) JulianLevens: Nothing from me
(10:26:40 AM) MichaelDaum: good discussion
(10:26:58 AM) gac410: Yes indeed.   2016 will be an interesting year.
(10:27:02 AM) JulianLevens: y, needs to be captured
(10:27:08 AM) vrurg: gac410: I'd get back on this in a week or two. So far I still have questions to myself. 
(10:27:13 AM) vrurg: Gotta go, cu!
(10:27:18 AM) gac410: thanks vrurg
(10:27:22 AM) JulianLevens: Can we get this channel logged in the future?
(10:27:52 AM) jomo: cu vrurg :)
(10:28:02 AM) gac410: JulianLevens:   Yes   it will be captured.   I c/p each meeting into a ReleaseMeeting_YYYYMMDD  topic in development'
(10:28:15 AM) gac410: But I missed the meeting before christmas.  The rest are all there.
(10:28:43 AM) gac410: See http://foswiki.org/Development/ReleaseMeetings
(10:29:15 AM) gac410: Thanks everyone.  great meeting.


12:52:30 (You joined the channel)
13:13:00 JulianLevens Hi
13:15:41 JulianLevens Lavr, MichaelDaum, vrurg: We don't have an agenda for today so we need to check last meetings minutes: http://foswiki.org/Development/ReleaseMeeting02x01_20160111
13:16:50 JulianLevens To be honest, I cannot see much we can add today, if we progress I think we need CDot and jomo
13:18:10 MichaelDaum maybe a status quo on the new server would be nice. presumably by uebera|| who has done most of the work so far.
13:21:42 JulianLevens ok, I've asked him to join us
13:53:32 uebera|| joined the channel.
13:53:43 uebera|| Hi there. Sorry, was afk.
13:54:21 JulianLevens No worries glad you could make it
13:54:48 JulianLevens We were wondering about an update on the new server
13:56:05 uebera|| I added an "executive summary" on the FoswikiOrgServer page. In short, gmc needs to prepare the decommission of the new server, so we should switch over to the new one (steps are outlined).
13:56:24 uebera|| Unfortunately, the DNS issue is still not resolved, DreamHost is still listed as authoritative source.
13:56:55 uebera|| Have not received updates from Sven--according to the info from the new hosting provider, he's bound to receive a mail for each domain which is required to finish the transfer.
13:57:07 uebera|| That should happen within 5 days after the transfer is triggered.
13:57:38 uebera|| However, the only difference for the time being is that in the current situation, once the move happened, both Sven and me need to update the DNS settings.
13:58:20 uebera|| Given we need 48 hours for the changes to propagate, we should move within the next 2-3 days and add a banner with the new IP (as a backup).
13:59:01 JulianLevens y, thanks to you, Koen and others for getting this done
13:59:12 uebera|| Your're very welcome. smile
13:59:53 JulianLevens Someone needs to write a blog entry about this as well
14:01:53 JulianLevens In a summary of you're summary: we should be live by the end of the week and no blockers to stop us
14:02:42 uebera|| Yes. Or, rather, "we must be live" or else... wink -- not sure how long Koen can/wants to wait with the decommission. wink
14:03:05 uebera|| But I see no obstacles. The require SW is in place.
14:03:29 uebera|| s /require/required/
14:03:58 JulianLevens Cool, MichaelDaum: you been volunteered to write a blog entry
14:04:50 jast joined the channel.
14:05:52 JulianLevens jast: welcome, not that we've discussed much in terms of releases
14:06:25 jast so I didn't miss much in the five minutes I was late? wink
14:09:00 JulianLevens Oh, we've been talking about the new server
14:11:13 jast I don't think I've got any interesting related to that
14:12:38 JulianLevens On topic, ref the release-meeting: we don't have an agenda for today so we need to check last meetings minutes: http://foswiki.org/Development/ReleaseMeeting02x01_20160111
14:13:40 CDot joined the channel.
14:13:57 JulianLevens We don't have an agenda for today so we need to check last meetings minutes: http://foswiki.org/Development/ReleaseMeeting02x01_20160111
14:14:24 JulianLevens ping Lavr MichaelDaum
14:15:28 JulianLevens I don't have anything to add since the last meeting, anybody else?
14:15:57 CDot Not I.
14:16:29 MichaelDaum hey there. things got me heads down on urgent stuff atm.
14:17:16 JulianLevens y, my heads elsewhere somewhat as well
14:17:41 JulianLevens jast, Lavr: did you have anything to add
14:17:46 MichaelDaum got nothing urgent for the next release, though couple of stuff I'd like to commit to master soon after
14:18:19 MichaelDaum which branch is used for the next release?
14:19:33 JulianLevens Don't know need to ask gac410
14:20:06 JulianLevens I think we need to review our git flow
14:20:11 MichaelDaum alright. I can hold back. the least I want is to disrupt the release process.
14:20:57 JulianLevens http://foswiki.org/Development/GitBranchingAndTagging
14:22:12 JulianLevens Ok, rather than hold us all up for very little I suggest we close and meet again in two weeks
14:22:15 CDot I had hoped to do some work on pushing the character set knowledge down into the store, but haven't been able to.
14:22:36 CDot The patch for the TMPL: calls in topic templates is ready to be merged, though
14:22:44 CDot and has passed it's 14day gestation.
14:23:11 CDot I can't remember if gac410 wanted to merge it or not.
14:24:13 JulianLevens As the Beta went out I'd have said not, but ...
14:24:31 CDot no hen smile
14:24:33 CDot then
14:25:47 JulianLevens I suspect we should create a 2.1 branch now and make master the bleeding edge, but must have RM involved in that
14:26:29 JulianLevens When we next see him on IRC we can hassle him about this
14:29:33 uebera|| I understand he's "back" tomorrow. (Might be a good date for switching the server, btw.--I can't trigger it as I have no account on the old server and don't know how to deal with the *BSD installation.)
14:31:54 JulianLevens y, let's hope so, and that he's not snowed out

Topic revision: r3 - 26 Jan 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