19:00:10 <wumpus> #startmeeting
19:00:10 <lightningbot> Meeting started Thu Sep 19 19:00:10 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:22 <jonasschnelli> hi
19:00:25 <jonatack> hi
19:00:25 <instagibbs> hi
19:00:29 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
19:00:37 <warren> diegobz and glezos are here from Transifex
19:00:43 <achow101> hi
19:00:46 <glezos> hi all :)
19:00:53 <moneyball> Hi
19:00:53 <luke-jr> I'm finally able to make it :P
19:00:53 <wumpus> welcome diegobz and glezos
19:01:08 <fanquake> hi
19:01:20 <warren> hi
19:01:24 <sipa> hi
19:01:50 <wumpus> proposed topics for today are: 1) making better use of transifex 2 ) what to do with change output creation with bech32 (instagibbs)  3) android GUI (fanquake)
19:01:52 <luke-jr> should we start with Transifex topic?
19:01:54 <wumpus> yes
19:02:03 <wumpus> #topic Making better use of transifex
19:02:39 <warren> glezos: diegobz: you had a few points of advice?
19:03:06 <glezos> Happy to be able to help all and answer any Qs. Some recommendations for better use of Transifex is to develop a Glossary to improve consistency. Also, to make sure that the existing Translation Memory (past translations) are ones of good quality.
19:03:10 <wumpus> so I've only recently gained admin of the transifex org and there's a whole lot of new options but haven't been able to do much yet
19:03:51 <glezos> Finally, as admins, you can look at the "Translation Checks" section in the Org Settings, where Transifex can auto-check for mistakes by translators which an break the build process (e.g. broke a variable)
19:04:03 <wumpus> glezos: thanks, is that glassary something we can configure on transifex itself, or is it something external?
19:04:22 <glezos> in Transifex, it's part of the org itself, and available to everyone in the org
19:04:28 <luke-jr> ah, so it can notice a %s vs %1 mismatch?
19:04:40 <luke-jr> or "% 1"
19:04:49 <glezos> yes.
19:04:49 <wumpus> oh that'd be useful, we have a script right now to check that, but having it integrated with instant feedback would be much better
19:05:01 <glezos> There is a whole section on Translation Quality in the documentation site with screenshots and examples: https://docs.transifex.com/
19:05:08 <luke-jr> yeah, the script can only discard the translation entirely
19:05:52 <glezos> @wumpus ideally you want to the checks to happen during translation so they get fixed right away. You can configure each translation check to raise a warning (allows translation save) or an error (blocks save)
19:06:20 <wumpus> so this glossary is something created by the org, and contains important words for the domain of the application (in this case, things such as block, transaction, wallet, etc)
19:06:33 <wumpus> glezos: good to know
19:06:33 <luke-jr> glezos: is it likely to be a problem that we have mixed placeholder styles?
19:07:02 <glezos> Yes. And you can have multiple glossaries (for each project, for example, if you have multiple projects) or share the same glossary across projects (all configurable on the org level)
19:07:42 <luke-jr> I think right now we have multiple "projects" for each branch?
19:07:45 <achow101> ba
19:07:51 <achow101> oops
19:07:51 <wumpus> we have one project, multiple resources
19:07:55 <luke-jr> ah
19:08:41 <luke-jr> is it possible to add translations marked as "incomplete" until a real translator can get to it? sometimes strings change subtly and I can kind of guess a change to the prior translation, but would want a real translator to provide a new one eventually
19:09:21 <wumpus> luke-jr: glezos: yes so some  messages have %1 %2 ... style, some have %s style, what is important is that it's consistent within a message
19:09:33 <luke-jr> and sometimes if we simply append a parenthesis to a string "a (b)" for example, we could leave "a" translated and add " (b)" in English as an incomplete message
19:10:04 <glezos> luke-jr, for something like that, we have a step called "Review". Empty → Translated → Reviewed. This way, you can choose, for example, to use the Transifex Client to only pull reviewed translations
19:10:26 <wumpus> once we get a lot more review going on, that'd make sense
19:10:50 <luke-jr> glezos: so no stage between empty and translated? or a way to provide a string with "empty" status?
19:11:10 <warren> we need to establish per-language teams with known reliable team leaders
19:11:17 <luke-jr> "<german text> (<english text>)" needs more than mere review
19:11:26 <kanzure> hi
19:11:35 <glezos> luke-jr no in-between stage, no
19:11:43 <wumpus> warren: might make sense to do a notification on transifex to ask for people to come foreard
19:12:09 <warren> If they were active in past years it's a good sign maybe they should be a leader.
19:12:29 <wumpus> yes, has anyone been keeping track though?
19:12:45 <warren> dunno, I would assume transifex has the data of who did what
19:12:46 <luke-jr> does Transifex even keep records of who did what?
19:12:51 <wumpus> yes they do
19:13:15 <wumpus> there's information on a per-message level at least, who translated it
19:13:25 <glezos> wumpus you can do that using the Discussions and Announcements features, which notifies all teams. https://www.transifex.com/bitcoinorg/teams/10848/discussions/ https://www.transifex.com/bitcoinorg/bitcoinorg/announcements/
19:14:06 <glezos> wumpus correct. Also, there is a Reports feature at the top, which you can dig out historical activity information.
19:14:23 <wumpus> glezos: nice!
19:14:38 <glezos> (come to think about it, I think the Reports are not available in the open source plan...)
19:14:47 <warren> glezos: (note this is "bitcoin", "bitcoin.org" is separate)
19:15:17 <glezos> oops, thank you warren.
19:15:20 <glezos> sorry about that.
19:16:42 <wumpus> ok, anyone with further questions about transifex? this is the time
19:17:05 <promag> wumpus: topics += qml (sorry for the interruption)
19:17:11 <glezos> We have a Community site for any async questions, https://community.transifex.com
19:17:18 <warren> glezos: can you show examples of what the reports look like?
19:17:49 <luke-jr> glezos: is it possible to get the raw historical author data via CLI?
19:17:52 <glezos> warren: yes, https://docs.transifex.com/tracking/reports
19:18:19 <glezos> luke-jr no, but reports can be exported as a CSV from the web app
19:18:59 <luke-jr> but not if we don't have access to reports ;)
19:19:27 <luke-jr> re [19:14:38] <glezos> (come to think about it, I think the Reports are not available in the open source plan…)
19:19:36 <glezos> indeed. ;)
19:20:14 <luke-jr> (and if the raw data can't be exported, it's kind of vendor lock-in ☹)
19:20:18 <warren> glezos: this is a unique project in that here is no central entity to pay for services, I suppose one of the supporting companies or non-profits could pay for a service but that's outside the scope of these developer meetings.
19:20:40 <glezos> happy to help y'all out though with the reports and share the data
19:22:25 <wumpus> ok, I think it's time to move to the next topic -- thanks a lot glezos  and diegobz for being here and helping with answers and suggestions
19:22:32 <glezos> you bet
19:22:55 <wumpus> #topic what to do with change output creation with bech32 (instagibbs)
19:23:10 <instagibbs> so this is wrt #16884
19:23:11 <gribble> https://github.com/bitcoin/bitcoin/issues/16884 | wallet: Change default address type to bech32 by instagibbs · Pull Request #16884 · bitcoin/bitcoin · GitHub
19:23:11 <wumpus> link: https://github.com/bitcoin/bitcoin/issues/15560#issuecomment-531796601
19:23:31 <luke-jr> why would default type affect that?
19:23:54 <instagibbs> it doesn't necessarily, we could mimick the other direction of course
19:24:38 <instagibbs> The original motivation IIRC was something like we want to mimick the destination if they use bech32 because privacy and cheaper anyways
19:24:51 <instagibbs> we didn't mimick legacy output destinations
19:25:05 <luke-jr> Core doesn't support Lightning, so should just be using p2pkh by default, so I'm going to recuse myself from this topic since it has IMO flawed premises
19:25:37 <wumpus> so with a different default it'd simply be as if the user chose a different address type, right?
19:25:44 <instagibbs> so you should agree with me, if user specifies p2sh-pwpkh change itshould just do it :P
19:25:48 <instagibbs> it uses more weight
19:26:13 <wumpus> it seems we don't have many people here today with an opinion on this today
19:26:19 <instagibbs> specific change up for q anyways: https://github.com/bitcoin/bitcoin/pull/16884/commits/eaab744a5058fd954c2c4985237941e99e30f062
19:26:24 <instagibbs> in case someone sees this and wants to complain in the PR
19:26:25 <instagibbs> :)
19:26:55 <instagibbs> we can move on
19:27:02 <wumpus> yes
19:27:12 <wumpus> #topic High priority for review
19:27:47 <wumpus> let's do this topic as every work, though, it might be better to focus on things tagged 0.19 now than specifically tagged ones
19:28:02 <fanquake> ^
19:28:06 <MarcoFalke> agree
19:28:08 <wumpus> (because rc1 is planned for oct 1)
19:28:08 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/37
19:28:28 <fanquake> Also sanity testing 0.17.2 binaries when available.
19:29:06 <wumpus> yes, 0.17.2 code signatures were put up shortly ago
19:29:28 <luke-jr> rc2*
19:29:34 <MarcoFalke> Added 0.19 as blocker to high prio
19:29:36 <wumpus> rc2, yes, rc1 was DOA
19:29:42 <MarcoFalke> (its a note in the project board)
19:29:52 <wumpus> MarcoFalke: thanks!
19:31:20 <wumpus> ok, that concludes this topic
19:31:44 <fanquake> Might want to do #16713 first instead of Mobile GUI, if anyone has an opinion. cc MarcoFalke
19:31:46 <gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
19:31:46 <wumpus> #topic android QML GUI (fanquake)
19:32:28 <wumpus> I don't really think this is the best time to discuss this, because of 0.19 coming up, seems more of a future topic, but maybe it makes sense to discuss
19:32:30 <wumpus> oh
19:32:34 <jonasschnelli> Looks like this is worth exploring...
19:32:46 <jonasschnelli> I also don't know what to discuss on that topic
19:33:08 <wumpus> dunno either, maybe better to keep it to github for now: #16883
19:33:10 <gribble> https://github.com/bitcoin/bitcoin/issues/16883 | WIP: Qt: add QML based mobile GUI by icota · Pull Request #16883 · bitcoin/bitcoin · GitHub
19:33:18 <jonasschnelli> Yes. Agree.
19:33:30 <wumpus> #topic Ignore old versionbit activations
19:33:38 <wumpus> #16713
19:33:40 <gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
19:33:48 <MarcoFalke> Can't we switch the existing GUI to qml, so that there is only one for all devices (convergence, 2019, buzzword, ...)
19:33:50 <wumpus> I think we need to merge one of these before 0.19 to prevent false positivs
19:33:55 <wumpus> MarcoFalke: in the long term, yes
19:34:25 <MarcoFalke> my take on #16713 is in one of the comments
19:34:27 <gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub
19:34:43 <wumpus> it wasn't made easier by there being two competing PRs, and I kind of lost track
19:34:50 <MarcoFalke> I think sdaftuar had some different thoughts on it
19:34:56 <wumpus> yes :)
19:35:04 <MarcoFalke> Unsure if he is here rn
19:36:00 <wumpus> so maybe we want to do some quick low-impract change for 0.19 just to get rid of the undesired warnings, then for 0.20 go for a better solution
19:36:00 <MarcoFalke> silence means ACK, right?
19:36:09 <luke-jr> MarcoFalke: decisions are not made at meetings
19:36:16 <luke-jr> (for just this reason)
19:36:20 <wumpus> I think he's joking ...
19:36:55 <luke-jr> MarcoFalke: (re QML) I'm not sure a mobile UI and desktop UI have enough overlap
19:37:29 <jonasschnelli> MarcoFalke: mobile devices have different use cases. You can't just "scale" the desktop UI.
19:37:51 <wumpus> but they could definitely share code
19:38:03 <jonasschnelli> for sure
19:38:06 <wumpus> and have some QML in the desktop GUI, they just wouldn't be exaclty the same
19:38:16 <luke-jr> would be nice to unify RPC and GUI transaction logic too
19:38:35 <jonasschnelli> isn't that mostly the case?
19:38:38 <luke-jr> no
19:38:46 <luke-jr> we have 3 copies of the almost-same logic
19:38:51 <wumpus> in any case, I think we ran out of topics
19:38:55 <jonasschnelli> indeed
19:39:21 <wumpus> mayebe we can bring up instagibbs' topic again next week if there's more people interested in discussing it
19:39:23 <wumpus> #endmeering
19:39:25 <wumpus> #endmeeting