[General] qTox meeting #3

Sat May 14 20:29:44 UTC 2016

qTox meeting 2016-05-14, #qtox @ freenode

Maintainers present:
* sudden6
* TheSpiritXIII  (a.k.a. DaSpirit)
* zetok

Maintainers absent without notification of absence:
* agilob (2nd absence without notification)
* antis81 (2nd absence without notification)
* tux3 (1st absence without notification

Short summary:
* CoC might be at some point added

Not much, since tux3 was absent.

In other news, there's a new mailing list `qTox-dev`.  Every qTox
maintainer should subscribe to it.

Log from the meeting (log time UTC+1):
########################################################################

[18:53:34] <sudden6> hi, everybody
[18:54:12] <ovalseven8> Hi sudden6 :)
[18:57:35] * stvlker (~stvlker at unaffiliated/stvlker) has joined
[19:01:07] <zetok> :3
[19:01:20] <zetok> https://i.imgur.com/1Dr0bAl.jpg :3
[19:01:24] <zetok> https://i.imgur.com/nzu7jNj.jpg :3
[19:02:24] * zetok wonders whether tux3 will be late again
[19:05:03] <zetok> what do you think about getting some sort of Code of
Conduct into place?
[19:05:56] <sudden6> not much, I think people behaving like decent
persons don't really need a code of conduct
[19:06:05] <zetok>
https://github.com/tux3/qTox/issues/2218#issuecomment-219132319
[19:06:28] <zetok> I think that installgen2 was trying to point out that
CoC is missing
[19:07:39] <zetok> so I'm wondering whether something should be done
about it
[19:07:40] <sudden6> I think he was trying to troll
[19:07:53] <zetok> that too
[19:07:55] <Impyy> typical installgen2
[19:10:00] <sudden6> a code of conduct won't stop trolls, it will only
invite them to troll more IMHO
[19:10:16] <zetok> yes, a bad CoC will do that
[19:10:36] <zetok> e.g. like the one genesis proposed
[19:11:33] <sudden6> link?
[19:11:59] <zetok> uh
[19:12:08] * zetok goes to look through logs
[19:12:18] <zetok> s/look/grep/
[19:13:26] <zetok> http://contributor-covenant.org/version/1/3/0/
[19:15:03] <zetok> I think that there might exist an implementation of
CoC that won't be bad, so if there's interest in it, I'd look into that
[19:15:42] <zetok> primary things to look into are Rust's and Gentoo's CoC
[19:16:01] <sudden6> mhm, I don't think it's a bad idea to have one
[19:16:28] <sudden6> but on the other side it makes me sad we need to
have one :(
[19:17:02] <zetok> um
[19:17:20] <zetok> I don't think that we /need/ one /yet/
[19:17:55] <zetok> it's just that when time will come, I'd like to be
prepared
[19:18:00] <sudden6> yes, but in the case we will need one, it's better
to already have one
[19:18:08] <zetok> :)
[19:18:29] <sudden6> else there'll be "you just invented that,
because... " arguments
[19:19:05] <sudden6> some much energy unneccessarily wasted because of
trolls
[19:20:20] <sudden6> about https://github.com/tux3/qTox/pull/3294 and
3293 why are they both open?
[19:20:39] * zetok was just writing an answer to that
[19:20:51] <sudden6> ^^
[19:21:18] <ovalseven8> CoCs are one of the most overrated things
[19:22:53] <zetok> sudden6: replied
[19:23:59] <sudden6> I still don't understand it
[19:25:15] <sudden6> 3294 does contain translation and code changes,
which isn't like we normally do it
[19:25:32] <zetok> err
[19:25:35] <sudden6> 3293 only code
[19:25:46] <sudden6> which would be ok
[19:25:47] <zetok> no, 3294 contains *translation*
[19:26:00] <zetok> once 3293 gets merged, that is
[19:26:16] <zetok> "duplicated" commits will simply "disappear"
[19:26:41] <sudden6> so after 3293 is merged you will rebase 3294
[19:26:45] <sudden6> ?
[19:26:46] <zetok> yep
[19:26:59] <zetok> + add a commit with update of all translations
[19:27:35] <sudden6> this makes it really complicated
[19:27:43] <sudden6> (at least for me)
[19:28:18] <sudden6> why didn't you make the translation updates alone a
separate PR?
[19:28:30] <zetok> they depend on the other PR
[19:29:10] <zetok> sudden6: um, don't worry about 3294 – I'll take care
of it myself once 3293 is merged
[19:29:16] <sudden6> yes, but I think if a PR depends on another PR, it
shouldn't contain the other PRs commits
[19:29:27] <zetok> eh
[19:29:29] <zetok> it doesn't
[19:30:23] <sudden6> huh? gh shows 3 commits for 3294, the first 2 are
already in 3293
[19:30:45] <zetok> gh will show 1 commit in 3294 once 3293 gets merged
[19:32:18] <sudden6> yes, once it's merged, but now it's showing all 3,
which I think is confusing, since when I review it, I basically review
the same changes twice
[19:32:53] <zetok> b-but you don't have to review it :(
[19:32:58] <zetok> only 3293
[19:33:22] <zetok> unless you want to, then you don't have to review
commits from 3293 anyway
[19:33:38] <sudden6> my thought was, it changes code, I have to review it
[19:33:48] <zetok> >.<
[19:33:59] * zetok wonders if [WIP] would have helped
[19:34:17] <sudden6> I would prefer it if, translation PRs only
contained commits changing ts files
[19:34:42] <sudden6> I think this would make it much easier to review
translation and code
[19:34:52] <zetok> :(
[19:35:07] <zetok> sorry, I just kinda don't get how it makes the review
harder
[19:35:32] <zetok> i.e. code commits are the same
[19:37:00] <sudden6> yes, but it's hard to notice that
[19:37:48] * zetok notes to himself that not everyone checks commit
hashes & messages
[19:38:01] <sudden6> I interpret "depends on ..." like I have to merge
that first, not that this PR also contains the mentioned changes
[19:42:36] <zetok> well, 3293 has to be merged before 3294
[19:44:21] <sudden6> uhm, I think it would be the same if I merged 3294?
[19:44:26] <zetok> nope
[19:44:33] <zetok> I mean
[19:44:36] <zetok> ugh
[19:45:01] <zetok> you could do that
[19:45:14] <zetok> but then I'll have to make yet another PR for
updating translation files
[19:45:35] <sudden6> ↑ and that's why I don't like this all :)
[19:46:01] <sudden6> anyway, 3293 can be merged
[19:46:05] <zetok> ok
[19:46:14] <zetok> what about https://github.com/tux3/qTox/pull/3305 ?
[19:46:27] <sudden6> uh wait, just spotted somethin
[19:46:30] <zetok> (also IIRC contains changes affecting translations)
[19:46:33] <mgoodwin> My calls are dropping after about ~9 -> 15 minutes
or so
[19:46:44] <mgoodwin> Audio cuts out actually, not drop
[19:46:57] <mgoodwin> it stays connected but there is no more sound on
either side
[19:47:08] <zetok> mgoodwin: https://github.com/tux3/qTox/issues/2926
[19:47:18] <ovalseven8> Let's say it this way: qTox A/V should be
rewritten from scratch
[19:48:04] <mgoodwin> That's me, the last commenter
[19:48:08] <mgoodwin> xenithorb
[19:48:22] <mgoodwin> (5 hours ago)
[19:48:53] <mgoodwin> I did a more recent test right now and no one was
on the audio tab
[19:51:01] <zetok> sudden6: should I change that?
[19:51:12] <mgoodwin> I also tested WAN/LAN so I don't think it's a
internet issue at least (could be a local firewall issue but I doubt it)
[19:51:15] <sudden6> I'm still researching
[19:51:22] <zetok> k
[19:52:49] <sudden6> google says we should use nullptr since c++11
[19:54:51] * zetok goes to add commit
[19:55:19] <sudden6> 3305 is fine
[19:56:38] <mgoodwin> zetok: O'
[19:56:49] <mgoodwin> I'd like to help with this sound cutout bug *
[19:56:54] <mgoodwin> What can I do?
[19:57:36] <sudden6> I think you would need some c++ skills for that
[19:58:07] <mgoodwin> Are the specifics of the bug known then? No more
logs necessary?
[19:59:33] <sudden6> mgoodwin: probably not, but at this stage it's hard
to tell what is needed :(
[19:59:36] <mgoodwin> Side note, doesn't seem like the "reset to default
settings button does anything"
[20:01:34] <sudden6> mgoodwin: the way I would go for it, is to try
reproduce the bug and use the debugger to find out if it's a qtox or
toxcore problem
[20:01:38] <zetok> sudden6: um, note that I didn't test that last commit
[20:02:57] <sudden6> zetok: this shouldn't change anything, nullptr is
just a nice name for 0 most of the time
[20:03:15] <sudden6> if it compiles it's fine
[20:03:50] <zetok> yep, compiles
[20:04:03] <sudden6> then it's alright
[20:04:22] <zetok> real    0m14.768s
[20:04:23] <zetok> :D
[20:04:29] <sudden6> #3215 what do you think about that?
[20:04:48] <sudden6> 48 cores? xD
[20:04:57] <zetok> nah, just 8
[20:05:22] <zetok> + CCACHE + cached files
[20:05:42] <sudden6> I don't trust this caching stuff
[20:05:54] <sudden6> tends to cause issues if I don't do a clean build...
[20:06:01] <zetok> dunno about that
[20:06:07] <zetok> never happened for me
[20:06:27] <zetok> and I've been using it to compile qTox for years by now
[20:06:55] <zetok> about the PR – it has "changes-required" ?
[20:07:10] <sudden6> yeah, I think of completely closing it
[20:07:38] <zetok> (in other words – I usually don't test things that
need changes, since I'd need to re-test them once they get changed)
[20:07:45] <sudden6> I more meant the idea of it tough
[20:07:59] <zetok> idea doesn't sound bad
[20:08:21] <zetok> dunno about the implementation though
[20:08:40] <sudden6> the implementation is only meh
[20:08:58] <sudden6> would need a lot more work to do it properly
[20:09:03] <zetok> well, I'd leave it open – perhaps they'd want to fix
things :)
[20:09:26] <sudden6> ok, do we have a limit for "stale" PRs yet?
[20:09:52] <zetok> no, and I wouldn't really want to have one
[20:10:09] <sudden6> why?
[20:10:23] <zetok> unless it would be something like 1 year, or some
other reasonably long time period
[20:10:35] * Lord_Vlad has quit (Read error: Network is unreachable)
[20:10:43] <zetok> encouragement & visibility
[20:11:20] * Lord_Vlad (~Vlad at 2a02:a03f:30ea:500:6e6a:e95d:3c36:62db)
has joined
[20:11:21] <sudden6> I don't know, if a PR doesn't recieve any attention
during say 30 days it's probably pretty outdated already
[20:11:45] <zetok> PR submitter may feed discouraged when their PR will
get closed for being "stale" – perhaps they don't have time in their
life to fix/improve things quickly, but they would find the time in a
month or 2
[20:12:40] <zetok> as for visibility – open PRs that need changes are
visible to people who would want to contribute, and if they want to help
with some functionality that is implemented in PR but needs some fixes,
they have a easy way to see those PRs
[20:12:47] <sudden6> good point, tough most of the time PR submitters
don't even care to mention they have no time
[20:13:11] <ovalseven8> Main qTox developer doesn't care as well ;)
[20:13:27] <zetok> ovalseven8: b-but sudden6 cares?
[20:13:27] <sudden6> well, he cares, but has no time
[20:13:35] <zetok> ↑
[20:13:38] <zetok> ;D
[20:14:03] <ovalseven8> ok, ok ;)
[20:14:04] <sudden6> also zetok has 100+% uptime on IRC
[20:14:28] <zetok> sadly that's just my znc :f
[20:15:09] <sudden6> speaking about time, I'll leave for today
[20:15:16] <zetok> bai
[20:15:22] <sudden6> see you soon
[20:15:28] <zetok> sudden6: btw, merge if you can?
[20:15:30] <ovalseven8> Good night
[20:17:10] <sudden6> zetok: yes tomorrow
[20:18:04] <zetok> ok

-- 

Kind regards,
Zetok Zalbavar
----
My Tox ID:
29AE62F95C56063D833024B1CB5C2140DC4AEB94A80FF4596CACC460D7BAA062E0A92C3424A0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tox.chat/pipermail/general/attachments/20160514/5b9678ae/attachment.sig>