Release Meeting: 02 Oct 2017

(08:47:44 AM) zak256 entered the room.
(09:01:54 AM) gac410: Hi everyone. Agenda at https://foswiki.org/Development/ReleaseMeeting02x02_20171002
(09:02:27 AM) gac410: Ready to start?
(09:03:31 AM) gac410: 1) Task Review
(09:03:37 AM) MichaelDaum: Hi there
(09:04:36 AM) gac410: https://foswiki.org/Tasks/Item14415 - Mostly fixed already. Uses nfkd sort for updating WikiUsers. But also noted that if a user becomes a non-WikiWord somehow, it breaks insertion. I'm thinking that needs to be more flexible.
(09:04:41 AM) gac410: Hi MichaelDaum
(09:04:49 AM) zak256: Hi all. Please consider me a passive reader here. Just curious to see what's going on.
(09:05:00 AM) gac410: sure ... everyone's welcome.
(09:05:53 AM) ***MichaelDaum reading Item14415
(09:07:01 AM) MichaelDaum: ... and reading the checkins
(09:08:50 AM) MichaelDaum: there's some password stuff in there as well? maybe assigned to the wrong Item task?
(09:09:10 AM) gac410: I think you've been running with the nfkd sorting patches for a while now. Only strangeness that I've seen, is that the greek alphabet sorts to the very end now. But it does work.
(09:09:30 AM) gac410: Y. I think I confused the tasks. :(
(09:09:35 AM) MichaelDaum: :)
(09:10:47 AM) gac410: Anyway, when parsing the WikiUsers list, I think it should also accept non-wikiwords. Otherwise a user rename can cause the list to prematurely terminate.
(09:10:57 AM) MichaelDaum: the changes are merged to Release02x01. so we can flag the task as waiting for 2.1.4 release, I guess.
(09:11:07 AM) gac410: 2.1.5 but yes.
(09:11:19 AM) MichaelDaum: y
(09:11:43 AM) gac410: oops.
(09:12:22 AM) MichaelDaum: it is a bugfix. in so far it is best to get it out as soon as possible.
(09:12:26 AM) gac410: And patch release.
(09:12:35 AM) gac410: not 'minor'
(09:14:02 AM) gac410: For Item14343 - TinyMCE ... This is just developer facing. I've waited long enough for CDot. I'm going to change the tinymce_dev directory in pub to be a "git submodule"
(09:15:19 AM) gac410: It might cause some pain to change branches between master (with a submodule) and a master derived branch (with a real directory) . Real directory will "block" the checkout
(09:15:20 AM) MichaelDaum: what does it mean for pseudo installed envs, as well as BuildContrib?
(09:15:42 AM) gac410: Nothing at all. We dont' use tinymce_dev that I can tell.
(09:16:08 AM) MichaelDaum: ah ok. so the sub module will only be there to test tinymce's dev branch?
(09:16:12 AM) gac410: According to cdot, he checked it in for his convenience.
(09:16:15 AM) gac410: yes
(09:16:39 AM) MichaelDaum: on which branch is this checked in?
(09:16:44 AM) gac410: As a submodule you'll then be able to use git checkout to switch the dev branch to whichever one you want.
(09:16:57 AM) gac410: hm looking
(09:17:42 AM) MichaelDaum: ah there it is. master
(09:17:45 AM) gac410: I didn't check it in. I've got a local branch
(09:17:55 AM) gac410: Oh. you mean cdots's tinymce_dev
(09:18:18 AM) MichaelDaum: y
(09:18:43 AM) gac410: I updated the docs in Development.TinyMCEPlugin to show how to go about updating tmce releases
(09:19:01 AM) MichaelDaum: anyway. I won't be messing around with tinymce_dev. this all is so shifting sands. hard enuf to get a foot on the ground.
(09:19:38 AM) MichaelDaum: I'd rather see it being replaced with ckeditor
(09:19:41 AM) gac410: okay good. Just don't be suprised if you check out an item branch and discover that when you try to go back to master, it' will have a collision with tinymce_dev
(09:20:05 AM) gac410: well that magnitude change is rather beyond me. :D
(09:21:10 AM) MichaelDaum: my worries are that our WysiwygPlugin is too much tailored towards tinymce's quircks. as such a html-tml roundtrip probably is needing thoughts. cdot might know more.
(09:21:52 AM) gac410: y indeed. There is a lot of tmce fiddling in wysiwyg
(09:22:22 AM) gac410: I think jast did a lot of work for m-a as they use ckeditor but it was too extensive to easily integrate
(09:22:24 AM) MichaelDaum: another issue I have with the current tinymce in foswiki is that I can't find how to insert a link to an attachment ... am I blind?
(09:22:52 AM) gac410: I'll try to find it after our meeting
(09:23:01 AM) MichaelDaum: m-a gives a shit about foswiki
(09:23:23 AM) gac410: You might not be. CDot might have missed something. And I KNEW I was going to trigger some angst :D
(09:24:11 AM) gac410: Okay. So anyway. I will remove tinymce_dev and convert it to a submodule. If you have issues switching branches you'll need to remove the tinymce_Dev directory
(09:25:02 AM) gac410: Another change for 2.2. I plan to remove the "Legacy" engine. The only place I found it used was in some batch scripts that would be just fine with CLI engine
(09:25:21 AM) gac410: It is documented as needed for pre-Foswiki-1.0 scripts
(09:26:33 AM) gac410: Rather than defaulting to Legacy, Foswiki.pm will just check: If web env then CGI engine, else CLI engine as the last resort.
(09:28:51 AM) gac410: https://foswiki.org/Tasks/Item14461 Is waiting for you MichaelDaum ... I've got proposed fixes to formfield parser. All my testing is good. Should I just check it into 2.1.5 It fixes the country code breaking on entities, and space after comma breaking multivalue fields.
(09:29:05 AM) gac410: formfields make me nervous
(09:29:50 AM) MichaelDaum: sorry for not having provided any feedback on this one before. the fixes look just fine.
(09:30:13 AM) gac410: Finally just a reminder .. .you were going to look at switching the cookie js engine in https://foswiki.org/Tasks/Item14301 Just making sure it doesn't fall through cracks.
(09:30:27 AM) gac410: Thanks. I'll get 14461 checked in
(09:30:48 AM) ***gac410 has been reviewing my huge stash log, and finding things I forgot to checkin :P
(09:31:22 AM) MichaelDaum: same here :o
(09:31:24 AM) vrurg: Hi everyone
(09:31:29 AM) gac410: howdy vrurg
(09:31:43 AM) MichaelDaum: I don't see us changing JQueryCookie anytime soon
(09:32:44 AM) MichaelDaum: these things have more impact than obvious as its api would change n stuff. same for JQueryValidate. the newer upstream version changed a lot. and so on goes the story.
(09:33:33 AM) MichaelDaum: Ive got a load of things changing for JQueryPlugin not yet checked in
(09:33:45 AM) gac410: okay. hm I think there were some other cleanup in the cookie changes. I'll review them all again and then set waiting for release. and drop the modernize cookie API from 2.1
(09:33:49 AM) gac410: er.. 2.2
(09:34:05 AM) MichaelDaum: e.g. remove some old jquery-x.x.x versions, add jquery-3.1.x flagged experimental.
(09:35:16 AM) MichaelDaum: I'll be creating items tasks for this stuff to massage it into git
(09:35:26 AM) gac410: okay great. Hm... That reminds me, need a task. I was thinking we need a checker to WARN if the selected jquery version is not the "default" version. So people don't miss changing that setting after upgrades. I always forget.
(09:35:49 AM) gac410: So maybe *I* need a checker, but maybe others do too :D
(09:35:58 AM) MichaelDaum: config checker magique
(09:36:19 AM) gac410: Any other tasks need escalating or review?
(09:36:37 AM) MichaelDaum: not for today
(09:37:14 AM) gac410: I know zak256 had a couple against EditRowPlugin, but that extension needs CDot.. The code just is too arcane for me. :(
(09:38:34 AM) MichaelDaum: let's move on to dev discussions
(09:38:38 AM) gac410: I'll move onto Proposals then. I've made 2 related security proposals yesterday. On is IMO really important. Change our PasswordReset process to NOT change the password but defer it to confirm using a secure token
(09:39:16 AM) gac410: That's been a outstanding task for years. You can DOS someone by repeatedly resetting their password
(09:40:11 AM) gac410: So I propose in core a new "Token" authentication. Password Reset generates a crypto token, which "logs you in with restrictions" gives you access only to ChangePassword.
(09:40:13 AM) MichaelDaum: yea this is actually a bit embarrassing as it affects the system for so long already.
(09:40:20 AM) uebera||: +1
(09:41:58 AM) gac410: So the token auth is a core change to LoginManager. I planned to make it somewhat flexible so that the token *could* be used to invite someone with a one-time login. But will not be implemented for now.
(09:42:41 AM) MichaelDaum: this sounds sensible
(09:43:19 AM) gac410: And my 2nd proposal is to get rid of our brain-dead rand() call to generate a byte string, and use a crypographically strong string from Bytes::Random::Secure
(09:43:34 AM) gac410: (If the module is installed - so it's an optional dependency)
(09:44:56 AM) gac410: Implement it as a Foswiki::randomString() call so that the generator is only seeded once on first use and is usable internally similar to our Encode/Decode internals.
(09:45:44 AM) gac410: whether it should be exposed to Func is still a question.
(09:45:57 AM) MichaelDaum: there are a couple of places we use rand() in the core ... according to grep
(09:46:38 AM) gac410: yes. The validation token, random passowrd generator, and a couple of others iirc
(09:46:51 AM) uebera||: Sounds sensible as well. IIRC, it's not too easy to completely deplete system entropy using a recent kernel nowadays.
(09:47:27 AM) MichaelDaum: cool module Bytes::Random::Secure
(09:48:05 AM) ***gac410 found hard way it is indeed. :P The RNG under B::R::S uses /dev/urandom which cannot block but can become degraded. You can force it to use /dev/random which does block
(09:48:41 AM) gac410: And running unit tests, does indeed block
(09:49:05 AM) uebera||: Did you try to install 'haveged'
(09:49:28 AM) uebera||: https://wiki.archlinux.org/index.php/Haveged ?
(09:49:32 AM) gac410: (when using Bytes Random Secure with blocking enabled. running PasswordTests
(09:49:40 AM) gac410: PHP ??? gah
(09:50:38 AM) gac410: ah.. never mind. php is the wiki not haveged
(09:50:41 AM) uebera||: (semi-related: When I need more entropy, you can nowadays get yourself one of these DVB-T receivers and just listen to unused bands. I have a number of links, and there's even a kernel module.)
(09:51:56 AM) uebera||: (does not get much cheaper. And some of these devices w/ USB interface fit inside a slim server chassis (minus the antenna))
(09:52:28 AM) gac410: Anyway, Password unit tests hang if I use BRS with blocking enabled, to generate the salt. That's one of the more important places to use a strong RNG. I think making the source of randomness configurable is sufficient.
(09:52:42 AM) gac410: Even dev/urandom will still be better than our current use of rand()
(09:53:13 AM) MichaelDaum: and thats as much as we should dig into this rat hole I guess as far as foswiki is concerned
(09:53:28 AM) uebera||: +1
(09:53:42 AM) MichaelDaum: next is ModernizeICONMacro
(09:54:04 AM) vrurg: uebera||: what if the band unexpectedly gets used? Or somebody would transmit dedicated signal specifically to target the DVB USB?
(09:54:05 AM) gac410: indeed. Oh... and I propose that the password script and manage hooks can be rewritten to a rest handler
(09:54:17 AM) gac410: Lets table RNG talks :D
(09:54:55 AM) gac410: Since the UI::Password will mostly be rewritten, moving it to a rest handler now makes sense ... the old manage script is crap.
(09:55:24 AM) MichaelDaum: UI::* modules definitely are too fat
(09:55:34 AM) MichaelDaum: they _aren't_ UI-ish
(09:56:03 AM) gac410: So the POST from ChangePassword, ChangeEmail and ResetPassword will become posts to REST handler ... and I still have no idea where to actually register the handlers
(09:56:34 AM) MichaelDaum: UI::* modules should call core features, not implement them by themselves... but thats another itch to be ignored for now.
(09:56:50 AM) uebera||: vrurg: The data is tested/'cleansed', of course, so you'll see a warning and need to wait longer. But it can at most render the additional source unusable, not compromise the system.
(09:57:33 AM) gac410: Okay. ModernizeICONMacro discussion I ran into this trying to figure out zak256 use of icon templates, and MichaelDaum pointed out that JQICON mostly does what we want.
(10:00:40 AM) gac410: Any discussion on https://foswiki.org/Development/ModernizeICONMacro
(10:01:33 AM) zak256: Hi. I want to add that JQICON does currently not support everything we need. I cannot set a title attribute for specific userdefined icons. I would prefer to have some kind of possibility to associate macro/icon names with the resulting image and possible additional parameters like title attribute.
(10:02:29 AM) zak256: Yes, the mentioned table in that topic would solve this.
(10:03:12 AM) MichaelDaum: zak256, %JQICON does have a title parameter.
(10:03:35 AM) gac410: MichaelDaum: he needs a default. The only way our current code addresse it is by using templates
(10:03:38 AM) zak256: Yes, but it has to be given everytime JQICON is used.
(10:03:58 AM) gac410: Same for alt, size, and any other attributes.
(10:04:57 AM) MichaelDaum: there is no title attribute by default. not even <img ...title="" />
(10:05:28 AM) gac410: The template solution Sven added is rather elegant, but really arcane for any normal users. But it's the only way to get a default for anything
(10:06:17 AM) MichaelDaum: right. I use a similar one in NatSkin as well: have specific UI icons template-able
(10:06:50 AM) MichaelDaum: but thats probably independent of the actual %xxxicon macro in use
(10:07:10 AM) MichaelDaum: or just plain <i clas="ma ma-xxx"></i>
(10:08:21 AM) gac410: For wiki applications. some ability to set a default alt= (for screen readers), and title= is important. Yes you can set it in every place you use the %ICON but it seems to me that for an applilcation or web it would be great if say a green checkbox could show "completed" instead of "ok"
(10:09:01 AM) MichaelDaum: alt defaults to the icon name as far as I can see
(10:09:04 AM) gac410: or whatever specific state a checkbox represents in the context of the applications.
(10:09:06 AM) gac410: Yes.
(10:09:22 AM) zak256: That's what we do. We have special icons for certain things and people should be able to use the tooltip to see what it means exactly.
(10:10:01 AM) vrurg: I didn't follow the icons discussion but is there any objection to setting these defaults in web preferences?
(10:10:48 AM) gac410: I was trying to think of a good way to represent a series of icons & defaults in preferences. Id' actually rather do that than have to parse every Icon topic.
(10:11:00 AM) zak256: vrurg: What defaults exactly?
(10:11:39 AM) MichaelDaum: zak256, actually I don't agree on the usability implications here: the icon is just decorating a button or a link ... and this is the one that should have a text or tooltip for uses to discover what the actions is supposed to do .... the icon in itself is just an icon
(10:11:58 AM) vrurg: zak256: It's not implemented yet. I'm just thinking of why should it all be done in templates instead of more obvious places.
(10:13:17 AM) zak256: MichaelDaum: I am just saying what we do here. We have tables with information, and instead of saying "OK" or "in progress" or "this is some state" we show an icon instead. This makes everything much more clear when browsing the table.
(10:13:39 AM) gac410: hm I think accessibility standards require that alt text should be context relevant. It's not necessarily a link.
(10:14:24 AM) zak256: the alt text is for cases where the icon cannot be displayed for some kind if I remember correctly
(10:14:28 AM) MichaelDaum: zak256, I'd rather make use of icons behind those one-char shortcuts we already have. such as %X%, %Y%, %T% etc ... configured in SitePrefs, DefaultPrefs, WebPrefs ...
(10:14:59 AM) MichaelDaum: yes, alt is required for any img tag. otherwise the html does not validate.
(10:15:26 AM) MichaelDaum: note however that %JQICON does not necessarily generate an img tag for font icons
(10:15:27 AM) gac410: Hm Those are on the list of big problems ... well, the 2-character ones. They collide with hex encoding %BB
(10:15:40 AM) zak256: Yes, we will have to define these extra macros then, if there will be no other alternative.
(10:16:24 AM) ***gac410 needs to google the <i font icon html. Can it support alt / title tags?
(10:16:52 AM) MichaelDaum: gac410, yes
(10:17:15 AM) MichaelDaum: %JQICON{"fa-user" title="your profile"}%
(10:17:29 AM) gac410: okay. good.
(10:18:03 AM) MichaelDaum: but, as I said above, better would be to write <a href="...">%JQICON{"fa-user"}% %WIKINAME%</a> ...
(10:18:21 AM) MichaelDaum: <a href="..." tooltip="your profile">%JQICON{"fa-user"}% %WIKINAME%</a> ... that is
(10:18:25 AM) MichaelDaum: arg
(10:18:29 AM) MichaelDaum: ^tootip^title
(10:19:23 AM) gac410: But what about huge table | %ICON{ok}% | ... no link, Where you want ok to say "whoopdeedoo! It's fixed"
(10:20:35 AM) vrurg: MichaelDaum: I made use of %JQREQUIRE{"ui::tooltip"}% for similar purpose.
(10:20:35 AM) gac410: I think I'm agreeing with you though. Better to do set FIXED = %ICON{ok title="whoopdedoo..."}%
(10:20:58 AM) vrurg: In my case it's a text (a PBX extension).
(10:22:01 AM) gac410: I'm very concerned that generally ICONs need to be really fast. We use lots of them. And parsing topics in the search path for | icon | settings may not be advisable.
(10:22:14 AM) MichaelDaum: Set FIXED = %JQICON{"tick" title="fixed task"}%
(10:22:35 AM) vrurg: gac410: +1
(10:22:37 AM) MichaelDaum: yea parsing topics is bad
(10:22:56 AM) zak256: I think I can work with that. And yes it should be fast.
(10:23:07 AM) MichaelDaum: I guess thats the way %ICON currently is implemented?
(10:23:29 AM) MichaelDaum: parsing the tables in DocGraphics?
(10:24:17 AM) gac410: I'm not sure. I think it just looks for an attachment. The tables are documentation.
(10:25:13 AM) gac410: The other potential issue with ICONTOPIC overriding the list. Is there any potential security issue there. Setting a random ICONTOPIC and then using ICON to access an attachment
(10:25:57 AM) gac410: JQICON is protected in that the list is coded in configure, and can't be overridden in a setting.
(10:26:26 AM) MichaelDaum: good point.
(10:26:59 AM) gac410: Checking ACLs of the topics would slow down the macro considerably.
(10:27:49 AM) gac410: But ICONTOPIC allows per-web / per-application override. And that's currently supported by ICON macro.
(10:29:03 AM) MichaelDaum: worth testing and filing a security task item in case you are right :(
(10:29:46 AM) gac410: Anyway, right now it's really easy to replace ICON with JQICON. Set ICON = %JQICON{"%DEFAULT%" alt="%alt{default=""}%" title="%title{default=""}%"}%
(10:30:37 AM) MichaelDaum: why do you default alt to the empty string? it defaults to the icon name internally ... which I find much better than the empty string
(10:31:03 AM) gac410: Empty string is taken as not defined, and the alt= is used ... I think.
(10:31:44 AM) MichaelDaum: ah ok. now that I look at the impl ...
(10:31:45 AM) gac410: Maybe a compromise, rather than ACL checking, a config setting: PermittedICONTopics = ( list of topics)
(10:32:14 AM) gac410: so you have your ICON search path, and permitted overrides controlled in configure.
(10:33:33 AM) gac410: better than allowing ICONs to come from any topic, but definitely faster than ACL checking.
(10:34:19 AM) gac410: MichaelDaum: anyone on slack? I'm thinking I should redact this part of the discussion from the logs when I post them to the meeting task. :(
(10:34:56 AM) MichaelDaum: nope
(10:35:06 AM) MichaelDaum: slack is desperately underused
(10:35:37 AM) gac410: thanks. Oh... someone asked me where we got our bidirectional slack <-> IRC module. Did you write that or is it available somewhere?
(10:36:37 AM) MichaelDaum: it is a fork of slack-irc available here https://github.com/MichaelDaum/slack-irc
(10:36:50 AM) gac410: Ah... Thanks!
(10:37:30 AM) gac410: Okay.. That was my 3 proposals. Does anyone have any others on the list that need discussion?
(10:37:31 AM) MichaelDaum: I am running it on my server.
(10:37:50 AM) gac410: okay thanks. I'll point it out to the people that were interested.
(10:37:52 AM) MichaelDaum: yes: I'd like to bring https://foswiki.org/Community/Fosdem2018 to your attention again
(10:38:30 AM) gac410: I'm on the wrong side of "the pond" for that event. But y this would be very good to support
(10:38:36 AM) MichaelDaum: up to now I am the only one from the foswiki community interested in coming to next year's fosdem & help out on the booth.
(10:38:52 AM) MichaelDaum: please add yourself to the list there just in case
(10:39:16 AM) gac410: There is no way I'll be able to travel to Europe for this.
(10:39:31 AM) vrurg: gac410: there're two of us. :(
(10:39:46 AM) MichaelDaum: also: we are planning to have a wiki party exchanging ideas among dokuwiki, tiki wiki and xwiki people.
(10:39:56 AM) gac410: Did you do an email to the foswiki_discuss email list?
(10:40:07 AM) MichaelDaum: yes I did.
(10:41:05 AM) gac410: Looks like the timing is right that it could be associated with a FoswikiCamp again.. ... Though our developers seem to be dwindling below critical mass :(
(10:43:03 AM) gac410: MichaelDaum: back to icons briefly, it used to be a recommendation that *any* images specify height & width so the browsers can render the page without blocking on the image downloads.
(10:43:29 AM) gac410: Should an updated ICON macro ensure that height x width are always in the generated html?
(10:43:50 AM) MichaelDaum: difficult question actually
(10:43:54 AM) uebera||: gac410, vrurg: You need one of Sheldon's robots to come to Fosdem2018 (http://www.hizook.com/files/users/3/Texai_Robot_BigBangTheory_1.jpg) :o)
(10:44:21 AM) gac410: LOL
(10:44:43 AM) MichaelDaum: :D
(10:44:50 AM) vrurg: uebera||: Didn't see the show, but got the idea! :D Do they rent any of those? :D
(10:45:06 AM) uebera||: vrurg: not to my knowledge, unfortunately.
(10:45:10 AM) gac410: It was a very funny episode
(10:45:25 AM) MichaelDaum: there might be a Snowden edition available as well, the one he used on his TED talk
(10:46:13 AM) MichaelDaum: https://www.youtube.com/watch?v=yVwAodrjZMY
(10:46:50 AM) gac410: Anyway ... Anything else to add to the agenda?
(10:47:12 AM) vrurg: BTW, I will have to leave any time now. For those interested in v3: extenions docs are basically done (though not sure they're well enough organized) and new specs/config code docs are alsmost done too.
(10:47:37 AM) gac410: cool
(10:47:53 AM) uebera||: great
(10:48:12 AM) vrurg: Anybody to join? ;)
(10:48:58 AM) gac410: Do you think we should put you on the agenda maybe on the 16th? For a walk-through of the architecture, and a "how to get started" review ... plackup, etc.
(10:50:19 AM) vrurg: gac410: I'm thinking of other way around. It's time to make a topic in the branch which will be totally dedicated to collect this kind of information.
(10:51:21 AM) gac410: My thought was to try to encourage all the devs to step through the new version with some sort of structure.
(10:51:26 AM) vrurg: I would give an intro on plackup but generally it'll consist of a single line: cd $FOSWIKI_HOME/bin; plackaup foswiki.psgi ;)
(10:52:08 AM) gac410: so git checkout your-branch;pseudo-install developer;plackup foswiki.psgi
(10:52:21 AM) vrurg: gac410: Ok, let's try it.
(10:52:22 AM) gac410: Don't we need a proxy to get css/js/images?
(10:53:10 AM) vrurg: gac410: Nah. It is recommended but otherwise served by Plack::Middleware::Static
(10:54:37 AM) vrurg: So, let's try doing the intro on 16th.
(10:54:58 AM) gac410: That's working okay here ... got my home screen up.
(10:55:10 AM) vrurg: Meanwhile I'm anyway often available on the channel.
(10:55:35 AM) gac410: well. bin/configure is dead :(
(10:56:11 AM) vrurg: And anybody planning to test must keep in mind that the infrastructure is severly damaged, I can't fix it due to lack of time. Many tests are broken. I.e.: the code is rather unstable in many respects.
(10:56:55 AM) vrurg: gac410: /configure?
(10:56:59 AM) vrurg: without bin
(10:57:03 AM) gac410: okay... bin/edit/Sandbox/FooToipic.
(10:57:46 AM) gac410: Ah... looks like bootstrap is causing bin/ to be added to the scripturl path
(10:58:33 AM) vrurg: Perhaps needs to be addressed. I generally was trying to get rid of /bin in url path for PSGI.
(10:58:50 AM) gac410: y. Probably bootstrap is defaulting it wrong for your release.
(10:59:23 AM) vrurg: Anyway, I didn't test a fresh checkout for months by now. Will do it as a part of preparing for the presentation.
(10:59:38 AM) vrurg: Ok, time to go. Will be back later today.
(10:59:40 AM) vrurg: Thanks all!
(11:00:14 AM) gac410: CU. Thanks.
(11:00:37 AM) gac410: Unless anyone has anything else? MichaelDaum uebera|| zak256 ... let's adjourn
(11:00:58 AM) uebera||: Maybe one short remark regarding t.f.o (translate.foswiki.org)?
(11:01:05 AM) gac410: Ah... yes
(11:01:11 AM) gac410: good ;point
(11:01:29 AM) uebera||: Until now, I was unable to find me a test import with which I could play (this is done on the command line).
(11:02:01 AM) uebera||: My objective until now is to familiarise myself with the tool before writing a nice e-mail to modell-aachen on transferring their instance.
(11:02:30 AM) uebera||: But alas, there seems to be no such resource. (I especially want to import a 'project' from an older version of Weblate)
(11:03:00 AM) uebera||: Given that it is not a 5min exercise to set it up, simulating this is a bit of a pain.
(11:03:31 AM) MichaelDaum: there is a data export tool available on the web interface
(11:03:33 AM) uebera||: Also, we need to look into all these "hooks" the system supports. I have no idea how it is linked to the foswiki development workflow at all.
(11:04:07 AM) gac410: There is a well known push hook in github that we just point to the new site.
(11:04:08 AM) uebera||: MichaelDaum: Either I have missed it until now or it is only visible once a project is available.
(11:04:19 AM) gac410: y, I've looked as well :(
(11:04:43 AM) gac410: I've looked on t.f.o ... I'm an admin there.
(11:05:41 AM) uebera||: Once we contact modell aachen, we should be able to move everything fast without them providing support (which they will be relunctant to do, and that's understandable to some extent). If the planned 2 step migration is not possible, maybe we can get a complete dump (filesystem, database).
(11:05:49 AM) gac410: The export URL on t.f.o points to RSS Feeds, github hooks, and statistics.
(11:06:12 AM) MichaelDaum: yea. not really a db dump.
(11:06:18 AM) gac410: I was hoping the backend django interface had a dump. but not that I could find
(11:06:51 AM) uebera||: Well, I have no ideas what a DB dump would contain besides the export project data (I'm thinking user accounts).
(11:07:08 AM) uebera||: (Need to peek at the [t.]t.f.o database first.)
(11:07:10 AM) gac410: user accounts, history? Disscussion /comments.
(11:07:27 AM) uebera||: Yes, it would be nice to retain that.
(11:08:11 AM) MichaelDaum: guys I have to go and get something to eat.
(11:08:24 AM) MichaelDaum: see you
(11:08:30 AM) gac410: okay ... thanks.
(11:08:30 AM) uebera||: With a full export, we can migrate on our own, although we need to bring up a container satisfying the dependencies for the instance first (should not be too difficult). And it's the fastest way modell aachen can cleanly get rid of their installation, so this is a possible scenario (if maybe not the optimal one)
(11:08:35 AM) uebera||: OK. cu.
(11:08:49 AM) MichaelDaum is now known as MichaelDaum_
(11:12:44 AM) gac410: Anyway... Release meeting adjourned. Let's pick up any translation discussion in the other channels.