Release Meeting: 11 Jul 2016

Details

1. Urgent Task review

No new urgent tasks need review.

2. Development Discussion

There was some discussion of current developer momentum. Other than VadimBelman 's work on the OO rewrite, there has been very little core development being done. Based on no recent completed features, it might be an opportunity to move forward with Foswiki 3.0 and the Plack / Moo rewrite.

Focus on Foswiki 3.0 development plans:

Status update

  • Currently working now with PSGI. (Other engines momentarily broken)
  • A small number of the core plugins have been converted.
  • Unit tests mostly converted, tests pass.

Major issues needing discussion:

Work not completed / problem areas

  • CLI engine and tools/configure not working
  • We need documentation on how to use the new foswiki, especially with Plack/PSGI
  • Plack/PSGI cannot serve files, so a proxy configuration with nginx or Apache's mod_proxy is required.
  • Dependencies need updating. Foswiki now needs Plack::Request and Moo.

Compatibility with old extensions

There are 3 possible extension models
  • The original Foswiki 1.0/2.0 extensions API. These are currently not compatible with Foswiki 3.0, and there has been no work yet on a compatibility layer.
  • The current Moo / Foswiki::App converted extensions. They are not compatible with Foswiki 1.x/2.x.
  • Vadim is proposing that the current "procedural" hook / callback based model be replaced with a true OO based extension implementation.

There was no consensus on approaches, but there is hope that some compatibility layer be implemented to allow use of older extensions on Foswiki 3.0. It was also suggested that for now we stabilize 3.0 with the existing plugin model, and defer an extension redesign for some future version.

Distribution strategy for next generation extensions

See the prior release meeting minutes for a more detailed discussion of the extensions issues.

There are a couple of possibilities:
  • A Foswiki 3.0 extensions web. (Not very desirable).
  • Some sort of dual packaging that could be installed on any version of Foswiki.
None of this has been explored in any detail yet.

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 no proposals on the ReleasePlan have been merged! Agreed to defer 2.2 until September

  • Feature Freeze: 1 Sep 2016
  • Release from: master
  • Beta start: 15 Sep 2016
  • Release target: August 2016

Next meeting - - Monday 08 Aug 2016 1300Z — ReleaseMeeting02x02_20160808

IRC Log

(09:01:28 AM) gac410: Hi Everyone ... good day.   Thanks for attending the release meeting.
(09:01:35 AM) MichaelDaum: Hi there
(09:01:56 AM) vrurg: Hi
(09:02:31 AM) MichaelDaum: https://foswiki.org/Development/ReleaseMeeting02X02_20160711
(09:03:44 AM) gac410: First on the agenda is urgent task review. ...  and there have been no new urgent tasks,   
(09:04:26 AM) MichaelDaum: I wished we had more of em
(09:04:44 AM) MichaelDaum: as that is a clear sign of people using our shit
(09:04:53 AM) gac410: Normally next would be review of proposals,   but again all has been quiet.  nothing new, and nothing with expired timers.
(09:05:19 AM) gac410: MichaelDaum:   There has definitely been activity, just nothing rising to urgent.
(09:06:40 AM) MichaelDaum: there is one issue I need to investigate further wrt TinyMCEPlugin and changing a form as part of an edit
(09:06:51 AM) MichaelDaum: I tried to repro it on trunk but failed
(09:07:03 AM) MichaelDaum: but can do so repeatedly on my local install as well as on the customer's one
(09:07:05 AM) gac410: vrurg requested that we focus on Foswiki 3.0 and his OO branch.  He has mostly finished with the oo-ification  
(09:07:21 AM) MichaelDaum: agreed
(09:07:31 AM) gac410: MichaelDaum:   strange.   There really is not much different yet between trunk and Release02x01 branch
(09:07:38 AM) MichaelDaum: y
(09:08:28 AM) MichaelDaum: what I experienced is that a wiki app spanning several lines sich as %SEARCH{\n param \n parm \n param }% ... will be converted to %SEARCH{ <br /> param <br /> param <br /> param }% ... and thus break :( :(
(09:08:47 AM) gac410: vrurg:    Are you there?  
(09:08:49 AM) MichaelDaum: somebody experienced this
(09:09:26 AM) gac410: strange.   Macros should be be automatically protected during edit 
(09:09:50 AM) MichaelDaum: y
(09:09:51 AM) vrurg: gac410: I am.
(09:10:01 AM) gac410: I have on occasion seen other things end up with <br \>  embedded.  But seems to be inconsistent.
(09:10:34 AM) gac410: Okay,  so so far it's just the 3 of us.     jast,  uebera||     are you around?
(09:11:00 AM) gac410: vrurg:   There was not much else on the agenda - tasks and proposals have generally been quiet.    So floor is yours.
(09:12:10 AM) vrurg: It's not much to add to your agenda.
(09:12:58 AM) gac410: Okay.   so first,  status review.    You have completed much of the OO conversion,  and unit tests conversion is done as well?
(09:13:02 AM) vrurg: 'Mostly finished' means that I have running tests, core displaying pages correctly and few key plugins working (NatEdit, Json, JQuery, Comment)
(09:13:31 AM) gac410: PSGI engine is working  (and others are broken now?)
(09:13:48 AM) vrurg: CGI is easy to fix but the rest I didn't bother about.
(09:14:09 AM) vrurg: I think we can get same functionality with Plack::Hanlders
(09:14:23 AM) ***gac410 looked at the CGI engine, but could not figure out how to add in the secure method.
(09:14:51 AM) gac410: Should we continue with even the CGI engine, or handle CGI with plack as well?
(09:14:53 AM) vrurg: secure has the same meaning as in Request. Bool value.
(09:15:13 AM) vrurg: I didn't find CGI in Plack.
(09:15:15 AM) gac410: I know.    Just don't really understand the Moo Foo
(09:15:23 AM) gac410: Ah.
(09:15:26 AM) vrurg: Though didn't look thoroughly.
(09:15:54 AM) gac410: Wish jomo was around ... he seemed to be really certain that Plack would do it all.
(09:16:06 AM) vrurg: Ok, there is CGI handler too. Just googled it.
(09:16:57 AM) vrurg: Plus Plack would do tests we can hardly implement with current Unit.
(09:17:59 AM) gac410: I'm a bit worried in general for the project that we are losing our "critical mass" of developers.   Our release meetings are beginning to resemble the "other projects" 
(09:18:29 AM) vrurg: gac410: Could it be 'summer time' effect? 
(09:19:18 AM) vrurg: I mean people on vacations and generally more relaxed.
(09:19:42 AM) gac410: Yeah ... I hope so.   Either that or the big effort on 2.x wore everyone out ... or maybe a bit of both,.
(09:21:00 AM) gac410: Anyway    As there is almost nothing going on for 2.2,    do we consider branching master into Release02x02   for some future minor release ... and merge the OO branch into master.      Make a big push to make 3.0 then next big release?
(09:22:44 AM) vrurg: I would like to see things go this way but not sure if its reasonable with wider discussion about what 3.0 would consist of.
(09:23:10 AM) vrurg: And without extra help from other developers.
(09:23:12 AM) gac410: What are the big tasks needed for a 3.0.      CLI engine,    tools/configure,    Conversion of remaining extensions.   The extensions compatibility issue 
(09:23:22 AM) ***vrurg is not able to deal with all core plugins.
(09:23:48 AM) gac410: yeah.   If we are unable to pull 2.2 forwards,  then how can we tackle 3.0,   unless the "big break" from the old code attracts other developers.
(09:24:56 AM) gac410: vrurg:    One thing we need is some instructions on how to run 3.0 using PSGI  ... since the other engines are all broken.
(09:25:13 AM) vrurg: I would like to add a task of implementing a new plugin model as another big feature in addition to PSGI.
(09:25:48 AM) gac410: Have to be really careful about putting in too much and never getting a 3.0 out.
(09:26:15 AM) vrurg: gac410: Nothing special is needed. foswiki.psgi and foswiki_debug.psgi are the app scripts to be feeded to a PSGI server.
(09:26:25 AM) vrurg: And then it just runs.
(09:27:14 AM) gac410: So I have my apache config,   generated from ApacheConfigGenerator. ... what magic to I do to it?   
(09:27:42 AM) vrurg: I know that overloading is dangerous but the new model is needed as a part of completing OO-fication.
(09:28:08 AM) vrurg: Forget about apache.
(09:28:19 AM) MichaelDaum: heh :)
(09:28:19 AM) gac410: er.    I have a bunch of vhosts ...   
(09:29:09 AM) vrurg: I didn't work with vhosts yet. For now let's focus on testing purposes.
(09:29:28 AM) vrurg: It's too early to go deeply into the hole.
(09:29:50 AM) gac410: What I'm saying is my test system has a large number of apache virtual hosts.     (not foswiki ones) ...   runing various stuff.    
(09:30:22 AM) MichaelDaum: apache would probably proxy to the plack server
(09:30:28 AM) vrurg: I see. Well, I would need some help with this too then. Because I simply didn't have time to consider this aspect.
(09:30:47 AM) vrurg: MichaelDaum: Some proxy is needed for sure.
(09:30:56 AM) ***vrurg forgot to say about this.
(09:30:58 AM) gac410: I've been saying this from day one.    I have one IP.   and one server  running apache on port 80.   
(09:31:15 AM) vrurg: Foswiki doesn't server plain files. In my case I had to setup nginx.
(09:31:38 AM) MichaelDaum: or run it using Plack::Handler::Apache2 ... kind of mod_perl
(09:32:11 AM) vrurg: Perhaps Plack::Handler looks like the best idea for now.
(09:32:53 AM) vrurg: Must be completely transparent.
(09:33:24 AM) MichaelDaum: I'd rather use some kind of separation in a production setup
(09:33:33 AM) MichaelDaum: webserver <-> foswiki backend
(09:33:57 AM) MichaelDaum: which is now glued togther using fcgi ... but using plack this might be just plain http
(09:34:12 AM) vrurg: gac410: I'm sorry for limited funcitonality, but really cannot handle it all. Have to choose and focus on something particular.
(09:34:51 AM) MichaelDaum: so that's mod_proxy for apache
(09:35:05 AM) vrurg: MichaelDaum: plain files serving shall be considered too because we now have full non-ACL access to /pub which is no good for many cases.
(09:35:47 AM) MichaelDaum: plain file serving is done by the webserver ... not starman directly afaics
(09:36:15 AM) vrurg: Neither starman nor any other PSGI do this.
(09:36:37 AM) MichaelDaum: xsendfile is currently the best option for the webserver to ask the backend for permissions to hand out a plain file
(09:37:21 AM) vrurg: Ok, it could be considered later.
(09:37:29 AM) MichaelDaum: this is really similar to what we have now
(09:37:55 AM) gac410: I realize you have to focus vrurg,  but right now I have nothing functional.   the OO branch crashes,   I fought with it last night for an hour or so.     And I need to keep the ability to flip between 2.2. 1.1.9, and some other stuff easily.   which today I do with apache vhosts.  
(09:37:55 AM) MichaelDaum: foswiki.fcgi really only cranks out html .... with the bad exception of viewfile
(09:39:05 AM) MichaelDaum: btw did you guys already renamed the oo branch?
(09:39:21 AM) gac410: Maybe I'm thick   but I've tried for hours to make tools/configure to work,   tried to add a Foswik::App->new()    and other renaming of the Foswiki::Configure::Load, etc.  
(09:39:27 AM) gac410: no  not renamed yet.
(09:39:49 AM) MichaelDaum: y, I am afraid to dive into the same pool
(09:40:09 AM) MichaelDaum: got a secondary checkout ready to be psgied
(09:40:41 AM) MichaelDaum: there is loads of plugins that I need to deal with to get on par with my current foswiki/master install
(09:41:00 AM) MichaelDaum: what I am particularly intereste in is performance benchmarking
(09:41:05 AM) vrurg: gac410: Ok, I'll check out how to get CGI work with plack – must be really simple: http://search.cpan.org/dist/Plack-0.9979/lib/Plack/Handler/CGI.pm
(09:41:06 AM) gac410: They will be a lot of work.   
(09:41:37 AM) MichaelDaum: most worrying: VirtualHostingContrib and WebDAVContrib
(09:42:08 AM) vrurg: And I will move my focus on configure and pseudo_install. But later this week as we're moving tomorrow and will be busy all these days.
(09:42:14 AM) gac410: vrurg:   Do you have a list of packages needed  as well?    I've been gradually apt-getting and cpanm ing stuff
(09:42:26 AM) gac410: pseudo-install seems to work fine
(09:42:51 AM) gac410: (except for  pseudo-install -A   ... which uses  tools/configure to build a default config)
(09:43:21 AM) vrurg: Ok, then configure only.
(09:43:52 AM) MichaelDaum: how do we deal with Foswiki2 maintenance while Foswiki3 is being relased? how about plugins for both?
(09:44:03 AM) vrurg: For the packages: Plack::Request and Moo. And any dependencies they have.
(09:44:18 AM) gac410: That will be the huge question MichaelDaum     
(09:44:37 AM) vrurg: So far, nothing more that I would remember about. I'm trying to keep their number as low as possible.
(09:45:02 AM) MichaelDaum: there will be a load of changes only making sense for Foswiki3 that I will have to apply to plugins ... on the way to re-install feature parity
(09:45:06 AM) gac410: without someone to work on  Extensions web redesign,  best I can think of is to create an Extensions3 web.
(09:46:05 AM) MichaelDaum: I am pretty sure thats a bad idea
(09:46:12 AM) gac410: or a re-structuring of Foswiki to have a  Plugins3 and Contrib3 directory    and let extensions install "chaff" into the old Plugins and Contrib directories.
(09:46:33 AM) gac410: MichaelDaum:   I agree.   
(09:46:51 AM) MichaelDaum: I still have hove there is a way to run a glue layer
(09:47:11 AM) MichaelDaum: that let's you run Foswiki3 plugins in a Foswiki2 and vice versa
(09:47:24 AM) MichaelDaum: s/hove/hope
(09:47:43 AM) gac410: I think that needs vrurg to do is Plugins3.0 redesign as well.   
(09:48:02 AM) MichaelDaum: o dea
(09:48:18 AM) gac410: Right now hard to see what it will take as the old plugins model still exists.
(09:48:41 AM) vrurg: It's not a big deal to adapt a plugin to the new OO.
(09:48:45 AM) MichaelDaum: I am afraid this "plugin api redesign" is nothing more than talking about a vague idea. sorry, vrurg ;)
(09:49:19 AM) MichaelDaum: I am not even sure what and why the plugin api _needs_ a redesign
(09:50:03 AM) MichaelDaum: vrurg, what is it that you envision here? any rough outline?
(09:50:32 AM) vrurg: MichaelDaum: It's not about API redesign. It's about making plugins fully OO (plugin as an object) and having a few more power features like possibility to fully substitute a class within the core to add or reimplement it's functionality.
(09:50:39 AM) gac410: vrurg,   please don't underestimate the "opaqueness" of the new code.    I've looked at the Moo stuff a number of times.  I can do minor tweaks,  but it feels like I'm back at looking at perl code for the very first time.
(09:51:36 AM) vrurg: gac410: It's not opaque. No more than the original Foswiki code was to me whan I dove in it.
(09:51:50 AM) gac410: You said on CGI Engine yesterday something to the effect of "It's simple.  Just add secure  like PSGI engine does"     I looked and looked and tried and poked and prodded   and had absolutely no friggin clue.   
(09:51:56 AM) gac410: It's  utterly opaque to me.
(09:52:02 AM) vrurg: MichaelDaum: did I answer your question above?
(09:52:10 AM) MichaelDaum: nope ;)
(09:52:20 AM) MichaelDaum: not by far
(09:53:04 AM) vrurg: gac410: did you read Moo code? Plus 'secure' could be my fault too. I didn't have time to recheck what's wrong.
(09:53:36 AM) vrurg: MichaelDaum: It's hard to explain in few words.
(09:53:45 AM) MichaelDaum: then please do use more
(09:54:05 AM) vrurg: But what's wrong with today's plugins is that they're procedural style (using some OO from the core).
(09:54:11 AM) MichaelDaum: meanwhile: do we _need_ a new plugin model for the core being oo-redesigned?
(09:54:41 AM) vrurg: And they rely on the a global variable to access the core ($Foswiki::Plugins::SESSION or $Foswiki::app). 
(09:54:58 AM) vrurg: And this I consider a huge flaw.
(09:55:08 AM) MichaelDaum: yes sure, but.
(09:55:44 AM) MichaelDaum: the pattern is a different here. rather than requiring a plugin to be oo-ish, we now have slot fillers.
(09:55:56 AM) vrurg: Plus some few handy-candy tweaks making plugins a way more powerful subsystem. But, no, we don't really need the new plugins for the core. 
(09:57:13 AM) vrurg: gac410: Does CGI have 'secure' method?
(09:57:33 AM) vrurg: MichaelDaum: sorry, what are the slot fillers? I probablly missing something.
(09:57:40 AM) MichaelDaum: from what I see we first need to be able to walk before we can run
(09:57:49 AM) MichaelDaum: signals and slots
(09:57:50 AM) vrurg: MichaelDaum: agree.
(09:57:50 AM) gac410: My fear is that the Plugins OO redesign is yet another huge change.   Maybe it should be a 4.0 ... unless it lives besides the work you've already done.  We need to get what you are doing   stable and usable.
(09:58:09 AM) gac410: vrurg:    Not sure.   It may be a Foswiki::Request thing.
(09:58:20 AM) MichaelDaum: vrurg, this is a slightly different name for callbacks and handlers
(09:59:00 AM) vrurg: MichaelDaum: googled again. Must read more on this.
(09:59:36 AM) vrurg: But anyway the primary task is to get rid of global variables. Including %Foswiki::cfg. Which is another big issue. Really big.
(09:59:43 AM) MichaelDaum: anyway: once we cut off the current handlers will we end with almost zero plugins ... given plugins being one of the biggest selling point of foswiki
(10:00:14 AM) vrurg: And what I mean here is that LSC heavily depends on expanding Foswiki::cfg.
(10:00:52 AM) MichaelDaum: vrurg, if there is any halt for your reinvention feaver, give us a break.
(10:01:11 AM) MichaelDaum: we first have to anticipate your current work into the rest of the project
(10:01:41 AM) MichaelDaum: right now all of your oo work has got a bus-factor of 1
(10:01:56 AM) MichaelDaum: means: if a bus hits you, we end up with nothing.
(10:02:07 AM) JulianLevens  entered the room.
(10:02:34 AM) vrurg: MichaelDaum: I'm not rushing. But I need help and now more than before.
(10:02:58 AM) MichaelDaum: next should be: fix any issue keeping us back from running a bare-bones foswiki using the new oo-model
(10:03:05 AM) gac410: vrurg:   I've tried but I can't figure out where to begin 
(10:04:06 AM) vrurg: So, the first thing we need is to have some explanatory topic. The problem is I don't know how to write it because I'm inside and don't understand how does it look from out side. So, if somebody would write me a set of questions to be explained – that would be great.
(10:04:13 AM) gac410: right.   +1 MichaelDaum       if you want others to help, we really need to get core stable and functional for others to use.
(10:04:58 AM) MichaelDaum: vrurg, a "getting started"
(10:05:00 AM) vrurg: gac410: This is what 'mostly done' really means. :) It's ready to be stabilized.
(10:05:06 AM) MichaelDaum: how to set up a foswiki3
(10:05:38 AM) MichaelDaum: for dev and for prod
(10:06:23 AM) vrurg: prod will come later. It could be a moving target yet. 
(10:07:27 AM) gac410: Exactly.    I have an apache with 10+ vhosts  (really)   that I've used for... well forever.     My dev process is  "git clean -fdx; git checkout <somebranch>,  ./pseudo-install developer   run my init script  (does a mess of tools/configure -save -set   commands to build up my env) 
(10:09:05 AM) gac410: Test bug on 1.1.9,   visit f119.myhost.com    Test on <branch>  ... visit foswiki.myhost.com    test on 1.1.4    visit f114.myhost.com    test on twiki, visit twiki.myhost.com ... etc. 
(10:09:17 AM) vrurg: configure does look like a small script. 
(10:09:37 AM) vrurg: Shall be no big deal to have it working.
(10:10:25 AM) vrurg: Ok, I see the direction to go.
(10:10:52 AM) vrurg: Unfortunately not gonna be able to work on it up until this Friday or even next Monday.
(10:11:14 AM) gac410: If we can get it stable enough ... I'd suggest we merge into master,  so that trunk.foswiki.org  runs the new code.    
(10:11:32 AM) gac410: (branching Release02x02 out first
(10:11:37 AM) vrurg: gac410: I don't think it's possible. 
(10:12:16 AM) vrurg: Not before a month or two of some join work.
(10:12:28 AM) vrurg: s/join/of joint/
(10:12:35 AM) MichaelDaum: Undefined subroutine &Foswiki::Configure::Load::readConfig called at tools/configure line 253.
(10:12:48 AM) MichaelDaum: what am I missing
(10:12:51 AM) vrurg: MichaelDaum: configure is totally untouched.
(10:13:11 AM) gac410: Right.  tools/configure needs to be rewritten.    The Configure::Load stuff is moved / relocated.
(10:13:23 AM) gac410: It needs to be a Foswiki::App I guess.
(10:13:31 AM) vrurg: readConfig is in Foswiki::Config class.
(10:14:04 AM) gac410: Right.   I already chased that path down  ... twice.    Renaming / fixing all the moved classes.   Still crashes.   
(10:14:09 AM) MichaelDaum: jsut ran pseudo-install.pl -A
(10:14:43 AM) vrurg: MichaelDaum: I'll take care of it. Me is using web to get LSC.
(10:14:44 AM) gac410: Right.   -A  uses tools/configure which is busted.   Which also means our automated tests would never work.   They use -A for their baseline config.
(10:15:06 AM) MichaelDaum: vrurg, thanks.
(10:15:50 AM) vrurg: Ok, I have to go. It was really heplful meeting.
(10:16:03 AM) vrurg: Thanks everybody!
(10:16:05 AM) MichaelDaum: do I use plackup to run foswiki.psgi?
(10:16:27 AM) vrurg: MichaelDaum: I run foswiki_debug.psgi using HTTP::Server::PSGI.
(10:16:43 AM) vrurg: Works lika a charm under Komodo which makes debugging much more fun.
(10:16:47 AM) MichaelDaum: any comandline for me to c&p
(10:18:01 AM) vrurg: just run foswiki_debug.psgi
(10:18:12 AM) vrurg: It starts the server on its own.
(10:18:18 AM) MichaelDaum: what is the diff between foswiki.psgi and foswiki_debug.psgi
(10:19:03 AM) vrurg: foswiki.psgi doesn't run from command line – needs a server to load it. And it doesn't initiate memory leak routines.
(10:19:24 AM) MichaelDaum: for performance measures I'
(10:19:31 AM) MichaelDaum: d rather use foswiki.psgi
(10:20:16 AM) vrurg: Absolutely though without CHECKLEAK in foswiki_debug set to true they'd behave similarly.
(10:20:34 AM) MichaelDaum: okay talking to 127.0.0.1:5000 I get an internal server error
(10:20:41 AM) MichaelDaum: Use of uninitialized value in list assignment at /home/www-data/foswiki_distro/core/lib/Foswiki/Users/BaseUserMapping.pm line 114
(10:20:48 AM) MichaelDaum: Use of uninitialized value $implPasswordManager in string eq at /home/www-data/foswiki_distro/core/lib/Foswiki/Users/TopicUserMapping.pm line 46
(10:21:15 AM) MichaelDaum: It seems to reuse FOSWIKI_HOME still pointing to my foswiki/master install
(10:22:09 AM) vrurg: Yes, the new code requires all Perl env being set externally.
(10:22:32 AM) gac410: localhost:5000   gives me a foswiki page with no css or js
(10:22:35 AM) MichaelDaum: http://127.0.0.1:5000/pub/System/ProjectLogos/foswiki-logo.png returns html
(10:22:59 AM) vrurg: gac410: this is what nginx or apache are needed as proxies – somebody has to serve /pub
(10:24:06 AM) MichaelDaum: let's move over to #foswiki
(10:24:10 AM) vrurg: Ok, my work is calling. Sorry, have to run now.
(10:24:17 AM) MichaelDaum: thanks vrurg
(10:24:25 AM) gac410: thanks all. 
(10:24:55 AM) vrurg: thanks people!
(11:10:34 AM) MichaelDaum is now known as MichaelDaum_
(11:25:54 AM) jast: sorry everyone, today was pretty full. there's a much better chance I'll be present for the next release meeting.
(11:26:29 AM) gac410: Oh... I won't   :(
(11:27:08 AM) jast: ah well, maybe another time
(11:27:34 AM) gac410: Forgot to mention it during the meeting.   Maybe someone else can host.   No reason not to meet anyway.
(12:27:07 PM) MichaelDaum_ is now known as MichaelDaum
(12:29:16 PM) MichaelDaum: jast, you can look up the logs on https://foswiki.slack.com/messages/release/

Topic revision: r3 - 08 Aug 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