[General] qTox Meeting: The Second

[Zetok Zalbavar]

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

Maintainers present:
* TheSpiritXIII  (a.k.a. DaSpirit)
* tux3  (late to the party)
* zetok

Maintainers absent with notification of absence:
* sudden6  (had to leave just before the party)

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


Short summary:

• there were cat pics to get the party started
• zetok got access to weblate, now translations from it will be properly
managed (often updates to & from weblate, etc)
• translations from weblate were pulled in, and as much as possible was
used (yes, qTox just got a few new languages)
• qTox repo now has guards on `master` & `stable` branches, which will
prevent accidental force-pushes to them (just in case)
• OBS at some point will be used for Linux repositories packages for the
distros that don't package qTox yet


Don't miss the cat pics on the next meeting ;)

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


[19:24:37] * DaSpirit has quit (Read error: Connection reset by peer)
[19:53:15] * tux3 (~tux3 at unaffiliated/tux3) has joined
[19:53:15] * ChanServ gives channel operator status to tux3
[19:57:23] * DaSpirit (~DaSpirit at unaffiliated/daspirit) has joined
[20:09:08] <zetok> hm
[20:09:14] <zetok> tux3: o/
[20:09:30] <tux3> hai
[20:11:18] <vindelschtuffen> hi tux3, how have you been?
[20:12:03] <tux3> vindelschtuffen, good, thanks. And you?
[20:13:30] <zetok> [07:42:28] <oranges> I think if you chose to go with
OBS we should simply redirect people
[20:13:30] <zetok> [07:42:35] <oranges> no reason to mirror
infrastructure that is already there
[20:13:30] <zetok> [07:42:51] <oranges> if I had a choice I would do that
[20:13:30] <zetok> [07:42:56] <oranges> just let me know what you do choose
[20:13:46] <zetok> tux3: anyway; translations?
[20:14:20] <tux3> zetok, well you started something with weblate yesterday?
[20:14:35] <zetok> yes and no
[20:15:56] <zetok> tux3: is it possible to add me to weblate management?
[20:16:39] <zetok> tux3: also, I've ~wasted 3 days waiting for you; if I
had the access translations would have been merged by now, and weblate
would have been properly handled
[20:16:46] <zetok> access to qTox repo, that is
[20:17:06] <zetok> tux3: here you have a great example of why not having
qTox under an org is shitty
[20:18:09] <tux3> zetok, so, how does one add someone to weblate management?
[20:18:30] <zetok> no idea – if not doable, too bad
[20:18:53] <tux3> Hm, I found an ACL, try connecting to
hosted.weblate.org w/ your github account
[20:18:59] <zetok> it's already there
[20:19:16] <zetok> https://hosted.weblate.org/user/zetok/
[20:19:35] <tux3> Ok, you should be owner of all of "Tox" on weblate now
[20:19:57] * Bill_MI has quit (Quit: Bye...)
[20:20:09] <zetok> ok, I see
[20:20:52] <zetok> ok
[20:21:11] <zetok> tux3: it's set to pull changes for gh repo on commit
to repo, right?
[20:21:57] <tux3> zetok, I think so
[20:22:03] <zetok> ..
[20:22:19] <zetok> you know, all repo hooks are visible in settings
[20:22:30] <zetok> if there's no weblate one, then it's not set
[20:22:39] <tux3> Oh! Oh
[20:22:41] * Bill_MI (~Bill at d14-69-45-181.try.wideopenwest.com) has joined
[20:23:13] * zetok calls it "a waste of time"
[20:24:14] <zetok> tux3: in any case; I'm going to merge PR with changes
from weblate that I could get – after that weblate will need to be reset
to match current master
[20:24:24] <tux3> Hrm, the weblate doc is confusin
[20:24:37] <tux3> They have a billion different hook endpoints
[20:24:56] <nurupo> oh, tux3 is here
[20:25:01] <tux3> nurupo, hi
[20:25:02] <nurupo> was just writing email to you
[20:25:13] <nurupo> will copy-paste it in here instead then
[20:25:29] <zetok> ye of little faith
[20:27:54] <zetok> tux3: also, while you're at changing settings, change
guards on qTox repo
[20:27:57] <tux3> zetok, okay I got the stars to align, the weblate hook
should be setup correctly
[20:28:00] <tux3> Guards?
[20:28:07] <zetok> yep
[20:28:14] <tux3> Protected branches?
[20:28:23] <zetok> yep
[20:29:17] <tux3> Fair enough, for stable and master
[20:29:29] <zetok> + travis
[20:29:44] <nurupo> >Hi there, So, zetok has asked us to make a mailing
list dedicated solely to qTox at lists.tox.chat (https://lists.tox.chat).
[20:29:44] <nurupo> >I have asked him about the scope of the ml, because
it sounds like qTox ml would overlap with the Support ml and Development
ml. As a user having issues with qTox and seeing Support and qTox mls,
it would be very confusing which one to use, so the qTox ml should have
some distinctive scope, such that it could be named qTox-<foo> ml. All I
could get out of zetok was that the qTox ml should be for general
discussion, which isn't very specific
[20:29:44] <nurupo>
(https://gist.github.com/nurupo/bf2cf7fe51885115b9b6b7d9a36478a7). I
mean, it could work, we have to discuss it, but there is some obvious
overlap with other mls. So, I was just wonderting if you happen to have
any input on that.
[20:29:47] <tux3> zetok, But what if travis fails?
[20:29:48] <nurupo> tux3: here ^
[20:30:41] <zetok> nurupo: "a general ML for qTox that users of other
clients may consider a spam"
[20:30:48] <zetok> tux3: that's your problem to watch out for
[20:31:23] <tux3> nurupo, As I understood it the qtox ML wasn't mainly
for providing support, so users should still go to the Support ML. The
qTox ML could be renamed qTox-dev to avoid confusion I suppose
[20:31:27] <zetok> tux3: generally, no commits should go on master if
they at least don't build
[20:31:58] <tux3> zetok, yeah but I remember travis failing for stupid
reasons several times and it would suck to freeze the repo because of that
[20:31:59] <zetok> tux3: and if there's a problem with travis itself,
then it's up to repo maintainer to fix the settings/travis
[20:32:16] <tux3> zetok, I never signed up for maintaining travis :/
[20:32:43] <zetok> tux3: no, but you could turn off the setting until
travis gets fixed
[20:32:55] <zetok> https://github.com/zetok/tox ← I do that with it, it
works
[20:33:06] <zetok> I had to turn travis check 0 times
[20:33:13] <zetok> same goes for the repo with Tox spec
[20:33:24] <tux3> Or, maintainers could just not merge PRs where travis
fails. Unless it's a travis problem
[20:33:28] <zetok> requires travis, 0 times that it actually had to be
turned off
[20:33:45] <zetok> tux3: yeah, and instead maintainers themselves push
broken stuff
[20:34:18] <zetok> tux3: either case, it's just a check for something
that should pass tests anyway
[20:34:44] <tux3> Yeah but we don't need a hard software block to follow
a policy :/
[20:34:45] <tux3> If maintainers can't be trusted to check that stuff
even compiles, then travis won't save us
[20:35:11] <zetok> policy is a bullshit – hard block does it right
[20:35:24] <tux3> You can't replace people with checkboxes
[20:35:40] <zetok> no, I can add checkboxes to help people not push
broken stuff on master
[20:36:10] <tux3> Travis helps people not push broken stuff, if people
ignore travis either 1) they have a good reason 2) they made a mistake
and need talking to
[20:36:50] <zetok> checkbox is simpler & less time consuming than
talking to – it outright points out "you're doing it wrong!"
[20:37:09] <nurupo> travis builds succeeded is a very poor metric
though. ideally you should have a test suite written out, with many test
cases, that automatically test if a PR broke anything. like toxme friend
additon test, message sending test, file transfer test, etc. non-ideally
it could be done manually, but it's a lot more time consuming and harder
to verify that -- someone other than the person making PR would need to
do that (a tester) as the PR person could just
[20:37:09] <nurupo>  be lazy and lie about it
[20:38:09] * Bill_MI has quit (Quit: Bye...)
[20:38:29] <zetok> https://travis-ci.org/zetok/tox/jobs/128527981#L844 :)
[20:39:00] <nurupo> those are unit tests
[20:39:11] <nurupo> what i'm talking about are integration tests
[20:39:20] <nurupo> and automated ui tests
[20:39:29] <nurupo> those are harder to make
[20:39:52] <nurupo> tux3: btw, you didn't reply to the OBS email
[20:40:00] <zetok> hum
[20:40:08] <tux3> nurupo, sorry, I've been a bit overwhelmed with mails
lately..
[20:40:27] <zetok> nurupo: actually, I think that I have at least 1
integration test
[20:40:54] <zetok> and for UI code I have tests too
[20:41:04] <nurupo> tux3: didn't know anyone else other than me and
GitHub writes to you :)
[20:41:09] <zetok> (UI – string formatting)
[20:41:16] <tux3> nurupo, I wish :)
[20:41:17] <vindelschtuffen> tux3, I'm well, thank you
[20:41:20] <nurupo> zetok: UI -- visual
[20:41:38] <zetok> text is visual
[20:41:45] <zetok> and it's certainly an interface
[20:41:49] <tux3> nurupo, we're trying to officialize the OBS community
builds, because our current packages have problems
[20:41:58] <nurupo> tux3: also, we are getting A LOT of complains about
qTox not being in Ubuntu 16.04 package repository
[20:42:17] <tux3> nurupo, .. the official Ubuntu repos or the tox.chat
repos?
[20:42:32] <zetok> tox.chat
[20:42:40] <zetok> obviously
[20:42:52] <tux3> Obviously, but I though we did support Xenial, lemme check
[20:43:01] <nurupo> tux3: some people are complaining every other day,
asking why qTox developers don't provide packages and if it cares about
the users (or it's just dying out)
[20:43:15] <nurupo> hm
[20:43:20] <tux3> nurupo, hence why we're happy to move to the OBS builds
[20:43:22] <nurupo> the pkg repo has 0 packages
[20:43:42] <tux3> Oh yeah, we stopped at wily
[20:44:17] <zetok> nurupo: then tell people that packages are provided,
and it's just tox.chat providing broken stuff
[20:44:29] <zetok> problem fixed.
[20:44:49] <tux3> So. I don't know if it's worth it to create the whole
bunch of xenial builds or just redirect people to OBS at this point..
[20:44:53] <nurupo> ><tux3> nurupo, we're trying to officialize the OBS
community builds, because our current packages have problems <-- i'm
curious, what problems?
[20:45:16] <tux3> nurupo, they are pretty much unmaintened since I don't
have time for them, and they don't work well for some people
[20:45:22] <zetok> nurupo: tux3 is the problem
[20:45:24] <tux3> As well as not existing at all for Ubuntu Xenial
[20:45:29] <nurupo> ><zetok> nurupo: then tell people that packages are
provided, and it's just tox.chat providing broken stuff <-- ok, we will
tell that qTox developers don't want to provide ubuntu 16.04 packages
[20:45:39] <tux3> nurupo, slow down.
[20:45:46] <nurupo> zetok: problem solved :P
[20:45:56] <zetok> nurupo: as always, lies and deception, nothing less
expected from Tox committee member
[20:46:34] <nurupo> ><tux3> nurupo, they are pretty much unmaintened
since I don't have time for them, and they don't work well for some
people <-- what doesn't work exactly though? i'm thinking of using
pbuilder for my Qt projects, so it would be useful for me to know
[20:47:08] <tux3> nurupo, oh it's not pbuilder's fault, it's mostly
bad/outdated build scripts/config
[20:48:28] <tux3> So about moving to OBS, I wanted to mirror OBS
packages on pkg.tox.chat so we wouldn't have to mess with people's
source.lists, but turns out that's a pain to do
[20:48:32] <nurupo> ><zetok> nurupo: as always, lies and deception,
nothing less expected from Tox committee member <-- well, saying that
"tox.chat" provides broken stuff sounds like that the Tox committee
members provide broken stuff, when it's all managed and provided by qTox
developers. there is no deception, i'm just avoiding the confusion, as
people think that we are the ones managing qTox packages
[20:49:11] <tux3> So it kinda sounds more reasonnable to just send
people over to OBS now
[20:49:27] <zetok> nurupo: again, lies and deception – the only one
managing the builds are you & tux3, no other qTox developer are involved
[20:49:41] <nurupo> *ok, we will tell that qTox developers don't want to
provide ubuntu 16.04 packages in tox.chat package repository
[20:49:50] <zetok> nurupo: if you want clarity, just say `tux3`
[20:49:55] <nurupo> i think that might have fixed the issue you were
having ^
[20:50:42] <zetok> dunno about that
[20:50:48] <nurupo> okay, i will say that only tux3 doesn't want to
provide ubuntu 16.04 qtox packages
[20:50:49] <zetok> I wouldn't care if it worked
[20:51:17] <zetok> anyway, time for translations \o/
[20:51:42] <nurupo> ><tux3> nurupo, oh it's not pbuilder's fault, it's
mostly bad/outdated build scripts/config <-- oh, then it wouldn't affect
me much
[20:52:15] -qtox-git-spam/#qtox- [qTox] zetok closed pull request #3259:
Translations from weblate (master...transl) https://git.io/vwxmb
[20:52:35] <nurupo> tux3: what stops you from assigning maintainers of
build scripts / configs to jenkins? or just having a build script in the
git repo, that way there is no need to access jenkins at all
[20:52:55] <zetok> lol
[20:52:57] <tux3> nurupo, I don't know anyone who wants to maintain
those packages
[20:53:10] <nurupo> tux3: and how does OBS solves this?
[20:53:33] <tux3> Somebody maintains them, and they work for all
relevant distros out of the box
[20:53:49] <nurupo> oh, so a openSUSE maintainer does the job?
[20:53:54] <nurupo> *an
[20:54:04] <nurupo> that's pretty cool
[20:54:11] <tux3> I don't know if it's an OpenSuse maintener, but it's
someone from the communit
[20:54:25] <zetok> *abbat*
[20:54:30] <nurupo> the OBS community?
[20:54:38] <tux3> What zetok said.
[20:54:57] <zetok> nurupo: really, you should know the great people
[20:55:03] <nurupo> oh, i see. the guy just doesn't like Jenkins and
likes OBS more
[20:55:09] <zetok> …
[20:55:14] <tux3> nurupo, to be fair OBS is pretty cool.
[20:55:22] <nurupo> tux3: it is
[20:55:29] <nurupo> tux3: they also support a lot of target distros
[20:55:36] <nurupo> i was looking into it the other day
[20:55:46] <tux3> zetok, so weblate is spamming my mail with "qTox merge
failures", are you on it or should I investigate?
[20:55:52] <nurupo> zetok: nah, i know abbat
[20:55:55] <zetok> tux3: "on it"
[20:56:00] <tux3> Awesome
[20:56:11] <zetok> tux3: or rather, I'm waiting until it finishes with
resetting to current master
[20:56:34] * tux3 thinks .ts pull requests weren't that bad after all
[20:56:48] <zetok> tux3: then I'm going to unlock it, so that people
could make some use of updated files & get better translations for qTox
[20:56:50] <nurupo> zetok: if i'm not mistaking him with another buy
whose nickname starts with "a", he is the guy wotking at Yandex internet
company in Russia and posting about Tox on Russian IT blogs, maintaining
community builds and a python tox bindings
[20:56:58] <zetok> tux3: no, they were *horrible*
[20:56:58] <nurupo> great guy
[20:57:20] <tux3> zetok, well, let's have both
[20:57:44] <zetok> tux3: yes, I'm not saying that contributing
translations via PR shouldn't happen
[20:57:57] <zetok> tux3: just saying that from translator PoV it's a
horrible experience
[20:58:36] <tux3> Yeah I can see how sending PRs is pretty bad for
someone who isn't a dev :)
[20:59:02] <tux3> But those fancy solutions are always a pain to set up..
[20:59:30] <zetok> btw, I'm going to be squashing translation PRs,
because of stuff like that:
https://github.com/fr3ts0n/AndrOBD/commit/70f3e132ee2972dd7b7d59d65e40532489cdcf34
[20:59:38] <zetok> s/PRs/commits/
[21:00:08] <tux3> I want to blame Java on this one, but fair enough
[21:00:26] <nurupo> actually, i think i was mistaking about him working
in Yandex, that was soem other guy
[21:08:32] <zetok> tux3: is the travis guard set?
[21:08:42] <tux3> zetok, hell no :)
[21:08:45] <zetok> why?
[21:09:23] <tux3> I want people to think, not be limited by stupid
software restrictions
[21:09:38] <zetok> that's not being limited
[21:09:52] <zetok> they're forced to think on how to make it work at
least on travis
[21:10:19] <zetok> people are lazy, and without some stimuli they
default to not thinking
[21:10:43] <tux3> Merging pull requests is not the time to be lazy
[21:10:43] <zetok> also, "thinking" in this case is a waste of time
[21:11:25] <zetok> if it builds on travis, then its at least worth time
for review; doesn't build – PR submitter knows what to do, or should ask
for help
[21:11:38] <zetok> s/its/it's/
[21:12:03] <tux3> We already have travis for that, no need to force it
[21:12:06] <tux3> If people are so lazy they can't check the BIG RED
BOLD travis failure, then how do I know they won't merge bugs, blatant
security vulnerabilies, or crap that doesn't even run?
[21:12:09] <zetok> ><tux3> Merging pull requests is not the time to be lazy
[21:12:44] <tux3> This is the one time you need to be paying attention,
when random people want to put their code in qTox.
[21:12:54] <zetok> also it's about "merging" own PRs, which people have
to do, given that there's not enough active people with write access &
time for review
[21:13:19] <nurupo> tux3: so, is it right to say that you will remove
all Linux builds of qTox from Jenkins once you have OBS figured out,
keeping only Windows builds on it?
[21:14:13] <tux3> nurupo, probably! Or at least delete the release
builds and keep some debug builds disabled.
[21:14:19] <zetok> tux3: and if you haven't noticed, people are lazy
about reviewing the stuff they have written themselves, and this is not
going to change, so at least there could be some protection
[21:14:33] <zetok> because "it should have worked"
[21:15:10] <tux3> zetok, if you're so lazy the code you wrote and are
trying to merge doesn't even compile, AND you ignore travis and merge it
anyways, then go on, merge it and see if I'm happy about it
[21:15:26] <zetok> ha.
[21:15:35] <zetok> you're too busy being away
[21:15:52] <tux3> I'll come back just to take care of you, don't you
worry ;)
[21:16:10] <nurupo> zetok: so, you are fine with tux3's decision of
qTox-dev mailing list?
[21:16:20] <zetok> tux3: I won't, my commits are usually ~perfect ^^
[21:16:27] <tux3> zetok, why, of course they are!
[21:16:38] <zetok> tux3: the use-case is other people
[21:17:16] <zetok> nurupo: dunno, I don't want to make this list feel
exclusive to people
[21:17:34] <zetok> and naming it -dev would make it so
[21:17:52] <tux3> zetok, it's simple, if other people are really that
stupid, then let them ignore Travis and we'll catch them. If they
aren't, then there's no problem. The worst that can happen is we'll have
to revert a commit.
[21:18:04] <nurupo> tux3: reviewing commits is fun. my tox client got a
6k or so lines PR, with many many new files and entities. never go time
to review the thing :\
[21:18:14] <tux3> nurupo, I love when that happens..
[21:18:49] <tux3> Almost as fun as having to rebase a pull request of
100 conflicting commits and you need to fix the same damn stupid
conflicts every commit...
[21:18:57] <zetok> ↑ don't
[21:19:08] <zetok> that's why I've added `PR-rebase-required` ^^
[21:19:16] <tux3> lol
[21:19:21] <zetok> make them suffer, you got other, working PRs to
review/merge
[21:19:50] <tux3> True enough
[21:20:25] <nurupo> zetok: well, then maybe you should talk about the
mailing list among the qTox committee members and come to some
conclusion, if there is uncertainty
[21:20:37] <zetok> tux3: ↑ ?
[21:20:41] <zetok> DaSpirit: ↑ ?
[21:21:07] <nurupo> i will be bringing up the qTox ml during our
meetings as qTox-dev, unless you want me to postpond brining it up until
you got it sorted out
[21:21:32] <tux3> Imho call it qTox-dev and be done with it, it's not
the one for user support, and if people just want to chat about their
life, they can go on IRC
[21:21:49] <tux3> We'll be using this ML for qTox development/meetings
so it fits
[21:21:53] <zetok> hm
[21:21:58] <zetok> ok
[21:22:14] <zetok> nurupo: yeah, that's fine with me
[21:22:27] <tux3> nurupo, can it be done?
[21:29:25] * tux3 has quit (Quit: Leaving)


-- 

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/20160507/7642c016/attachment.sig>