IRC logs for #baserock for Friday, 2015-12-18

*** edcragg has quit IRC00:30
*** gtristan has quit IRC05:24
*** gtristan has joined #baserock06:09
*** gtristan has quit IRC06:11
*** gtristan has joined #baserock06:13
*** toscalix has joined #baserock07:58
*** toscalix has quit IRC08:27
*** CTtpollard has joined #baserock08:29
*** ctbruce has joined #baserock08:36
*** toscalix has joined #baserock08:42
*** tiagogomes has joined #baserock08:49
gtristanMorning !08:56
* gtristan fixed interesting lorry bug today:
gtristanNot sure it's an issue on the host where we run the lorry controller08:56
gtristanseems not to be, so it must be a relatively recent regression in hg-fast-export09:00
gtristanComparing with ... shows it at least worked a few months ago09:01
*** bashrc has joined #baserock09:07
pedroalvarezhm.. given that you are not using lorry in a baserock environment, I'd say this issue is present in your OS and not in lorry controller's host09:21
pedroalvarezI wonder which version are you running (of hg-fast-import)09:21
pedroalvarezi would guess yours is more recent09:21
gtristanpedroalvarez, something quite recent09:21
gtristandebian stretch (testing) here09:21
pedroalvarezthe workaround looks good to me.09:22
gtristanhg-fast-import has no --version option09:22
gtristanyeah I think it's "safe" anyway09:22
*** cyndis_ is now known as cyndis09:22
gtristanand will avoid possible issues were the lorry controller host to be upgraded09:22
pedroalvarezI agree09:28
pedroalvarezjjardon: that's cool, I shall test it09:29
pedroalvarezwow, gerrit is full of your patches gtristan09:30
pedroalvarezI should review 25 times each09:30
pedroalvarezgtristan: question, are you planning to install 2 different versions of webkit?09:35
pedroalvarezor is this not webkit at all?
pedroalvarezI take is only a new version09:37
pedroalvareza new version for the lorry, although the version is older09:37
pedroalvarezgtristan: could you please not create a different lorry for it, and just change existing one?09:38
pedroalvarezthe previous version lorried won't disappear09:38
gtristanpedroalvarez, it's infact an older version of the same API09:49
gtristanwell sorry badly phrased09:49
gtristanits the "old API" branch (webkit1) built from the same freaky svn repo09:49
gtristanpedroalvarez, I can take that approach yes, it will only mean that in that lorried git history... there will potentially be intermingled versions, starting with the latest stable webkit2 (2.10.x), followed by the latest stable webkit1 (2.4.x)09:50
gtristanSo potentially, there can be another release of *both* branches (say, if security fixes are backported to webkit1 API branch, which is totally plausible as many apps are still using the old API)09:51
gtristanpedroalvarez, so yeah, I have no problem changing that, just pointing out... what it means :)09:52
gtristando we preffer to have one lorry for each ? or one lorry with intermingled releases ?09:52
pedroalvarezIt will be easier to find the right version if we only have one lorry09:52
persiaUnless we have needs to run webkit from both branches in different systems09:53
pedroalvarezthat wouldn't be a problem09:53
pedroalvarez(from the lorry controller point of view)09:53
gtristanit's not really problematic to have them in the same git09:53
gtristanas you can build both from it09:53
gtristanjust a matter of preference really :)09:54
gtristanpedroalvarez, ok I'll change it :D09:54
gtristanno worry09:54
pedroalvarezthe belevolent dictator has spoken09:54
gtristanpedroalvarez, can we approve the other lorries in the queue ? there are a couple of them which need to be up so I can gitmodulize them09:55
rjekI have?09:55
pedroalvarezyes, I was doing so, but found webkit one, so I stopped reviewing09:55
pedroalvarezall of them depend on the webkit change09:55
gtristanpedroalvarez, I mean... the lorries do not depend on the webkit lorry09:57
gtristanI have for example, new lorries just pushed to gerrit today09:57
gtristanthey have to be actually lorried, before I can update the definitions branch with new refs09:57
pedroalvarezI'd say that you have put all the changes on the same branch, and sent them all toghether for review09:59
gtristanpedroalvarez, specifically, telepathy-idle, telepathy-gabble, have wocky as a submodule09:59
pedroalvarezthat makes gerrit think that latter commits depend on former commits09:59
gtristanand pidgin needs a downstream patch in order to build the latest stable against new gstreamer API10:00
gtristaneh ?10:00
gtristanpedroalvarez, the lorry changes are always all master10:00
gtristannote I am specifically talking about patches to 'lorries' repo10:00
pedroalvarezyes yes10:00
pedroalvarezmy question is, have you done all the commits to add all of these lorries on the same branch?10:01
pedroalvarezor have you created different branches to send every of them10:01
pedroalvarezso that every of the patches apply on master10:01
tiagogomesgtristan any special reason for adding pidgin? Is not part of the GNOME core apps10:03
pedroalvarezthe latter is too much work, so I;d say that what you have done is:10:03
pedroalvarez- clone lorries repo10:03
pedroalvarez- Add lorry1, commiit10:03
pedroalvarez- Add lorry2, commit10:03
pedroalvarez- ....10:03
pedroalvarez- Send for review10:03
pedroalvarezso gerrit thinks (and IMO is right) that lorry2 can't be merged until lorry1 is merged10:04
gtristantiagogomes, for a complete empathy UX10:06
gtristanpedroalvarez, all of the lorries are individual commits on master10:06
gtristanI havent been branching in lorries at all10:06
gtristanpedroalvarez, gerrit is on crack if it thinks that10:07
gtristanWhat, you think I should instead A.) Add lorry, B.) Commit, C.) Send for Review, D.) Return to A ???10:08
pedroalvarezwell, you haven't created a branch, but you have created the commits on the same checkout10:08
pedroalvarezno, your current approach is good10:08
gtristanof course, what, I should have separate checkouts of each ??10:08
pedroalvarezbut you can't expect to merge the last commit before one in the middle of the series10:09
*** ssam2 has joined #baserock10:10
*** ChanServ sets mode: +v ssam210:10
gtristanpedroalvarez, but there is no series10:11
tiagogomesEmpathy is not part of the core apps as well, unfortunately the developers of empathy didn't want to be an integral part of GNOME and be rebranded to just Chat10:11
gtristanI dont get it, how is there a series ?10:11
tiagogomesAs they wanted Empathy to be used outside the GNOME desktop as well10:12
gtristantiagogomes, I dont blame them for that at all10:12
gtristanthat should be the case for almost every GNOME module10:12
*** edcragg has joined #baserock10:12
gtristantiagogomes, whether empathy considers itself "gnome" or not, it is still considered a core part of GNOME according to:
gtristanbut anyway10:14
gtristanI think it's an important part of having an impressive GNOME desktop UX, and dont think it's really relevant10:15
tiagogomesNeither do I, sorry for disturbing you10:16
* pedroalvarez cries10:16
jjardontiagogomes: do they?10:17
pedroalvarezfailing to explain :/10:17
gtristanKill Gerrit.10:18
pedroalvarezlearn gerrit10:18
gtristanIt doesnt do all the fancy automated crap we "wanted" it to do10:18
gtristanand it only gets in the way.10:18
pedroalvarezit gives us the possibility to add the fancy automated crap10:18
gtristanThats not a logical argument10:19
pedroalvarezand this is not a gerrit problem10:19
jjardonAnd yeah, empathy is part of the core GNOME modules. it has not been in active development for a couple of years though10:19
gtristanpedroalvarez, Example: I could have implemented composite widget templates in GTK+ just in GtkWidget... But, the maintainers would not except that had I not ported each composite widget to actually use them10:20
gtristanpedroalvarez, point being, changes like this need to be unilaterally applied10:20
pedroalvarezthen, your workflow to send unrelated patch-series is not working10:20
gtristanYou dont implement a stumbling block in the hope that it will make things happen in the future, you implement it AND implement the features and apply it unilaterally.10:20
pedroalvarezwhat you have done now, is like if you had put all the commits on the same PR on github10:21
ssam2gtristan: you can still send patches via the mailing list if you find it easier10:21
ssam2gtristan: it's more annoying for us to merge them that way, though10:21
gtristanssam2, bugzilla, or storyboard-if-it-accepts-attachments, mailing list is not a way to track patches10:22
pedroalvarezgtristan: then what do you suggest?10:22
gtristanthe "gerrit was a replacement for the mailing list" is not a valid argument, *nobody* does patch reviews on mailing lists10:22
pedroalvarezbaserock for delta/* repos10:23
gtristanpedroalvarez, Ok, you said my approach was a valid one (see above, separate commits for each lorry)... tell me then, if that's not the case *what* is the correct approach ?10:23
gtristanAll of the lorry commits are to be considered separate and orthogonal to definitions commits, they are not even the same repo10:24
gtristanThe requirement however, is that the lorry commits actually get applied, before I can even submit for review the upcoming definitions branch10:24
pedroalvarez- clone repo10:24
pedroalvarez- do changes related to feature 1 (n commits)10:24
pedroalvarez- send for review10:24
pedroalvarez- go to a clean checkout10:24
pedroalvarez- do changes related to feature 2  (m commits)10:24
pedroalvarez- send for review10:24
gtristanAre you *fucking* serious ?10:25
gtristanSorry but that is a disaster10:25
pedroalvarezplease, moderate language10:25
pedroalvarezcan you compare it to other workflows in other patch trakers?10:26
* gtristan goes to eat10:26
gtristanpedroalvarez, yes sure, I can use git-bz to send patches to bugzilla, I can create branches if I'm a "committer" (not a maintainer, note the difference) and have someone approve it in a bug report10:26
gtristanI can use git am to generate the patch sets and attach them to bugs for review10:27
gtristanIn smaller/insignificant change cases (i.e. documentation fixes, lorry files, etc), as a committer I can get my patches reviewed on IRC, even, and just have the maintainer give me an OK10:29
gtristan(only cases which do not really merit properly being documented in a bug tracker)10:30
pedroalvarezso this is just a: we have to move to bugzilla?10:30
pedroalvarezI personally don't want patches utracked10:31
gtristanThis is a "gerrit is totally screwed" and "it's a replacement for a mailing list" is just not a valid argument10:31
gtristan*because* bugzilla, because we are in 2015 and we have better ways of doing things than mailing list reviews10:31
gtristanpedroalvarez, even documentation fixes ?10:31
gtristanright now, I'm sorry but baserock sources are horribly untracked10:32
gtristanI can *not* do a git annotate on the sources, find the commit log and find pages of discussion documenting why the critical 2 line change was introduced10:32
gtristanI can however do that, with most projects10:32
pedroalvarezbecause they use bugzilla?10:33
gtristanBecause they use *a bug tracker*10:33
ssam2gtristan: sure you can .. with
ssam2oh, I see what you mean10:33
pedroalvarezI'm sorry, I don't want to continue with this10:33
gtristanssam2, right, commits should refer to the bug which discusses the change10:33
ssam2yeah it would be nice to have links between code and bugs.10:33
ssam2i try to link to ml discussions in commit messages if one is relevant10:34
pedroalvarezI'm happy with gerrit right now, and I wouldn't want to move to something else10:34
rjekCommit messages often include a "fixes #1234" for tracking to a bug report.  I don't see why a commit message can't include "discussed <message id of thread>"10:34
*** locallycompact has joined #baserock10:34
gtristanrjek, that is a possible approach yes, but it's more clunky than using a bug tracker; because looking at the history of a change in a mailing list is not great, searching a mailing list is not great for tracking the interrelatedness of various other bugs, either10:35
* rjek normally just pastes the message ID into google and it finds a public archive10:36
*** gtristan has quit IRC10:40
* persia reads a bit of backscroll and opines that there can be significant value in separating the bug tracker from the patch tracker11:09
* SotK agrees with persia11:09
SotKI suggest that workflow for fixing a bug would be 1. File bug in storyboard, 2. Discuss in storyboard comments, 3. Send patch to Gerrit and link the story in commit message, 4. Review on Gerrit, 5. Merged with Gerrit11:11
SotKyou can view the discussion via the link in the commit message, and the review process using the change-id11:12
persiaOne of the largest benefits to this is that it unconflates the user view and the developer view of the issue.11:13
persiaSome user issues require several different development activities.11:13
persiaSome developer activities affect several different user issues.11:13
persiaSome users have a hard time consuming developer discussion about the technicalities of fixes, and many users get annoyed with messages like "there is a fix available, just use it!" when a patch is being reviewed, and needs adjustment for little things (e.g. whitespace fixes), or when a patch isn't safe to apply except as part of a general series or topic (which is hard to represent in a bug tracker without confusing different user issues)11:15
persiaThat said, one needs to have close integration between the bug tracker and patch tracker, so that folk that care are able to easily follow the status of things.11:16
*** gtristan has joined #baserock11:33
* gtristan reads on
gtristanpersia, the problem I have with the bug tracker <--> gerrit <--> git commit log approach is basically linking it all is an overhead, getting people to properly mark the bug ID in a commit message has always been tricky, policy-wise11:38
gtristanthat said I can see the "user" perspective11:38
gtristanhonestly, even in small 2 or 3 person projects I've always used a bug tracker, and admit that I dont care as much about the user except that they actually file the reports, even without (or "before") users, bug tracking is essential to documenting project development11:40
gtristanSorry for my "outburst"11:42
gtristanThis is a topic which has annoyed me for a while, I dont think gerrit is up-to-task to be honest, I dont see the point of having it if it's not doing the amazing things it was chosen for, either.11:43
gtristans/up-to-task/up to the task/ rather11:43
* gtristan finds himself more often working around gerrit's short comings than appreciating anything that it actually does11:44
*** paulsherwood has quit IRC11:45
*** paulsherwood has joined #baserock11:45
jjardonHi, is there a way in definitions to express "run configure commands of this chunk only in armv7lhf architectures"12:00
radiofreethat would be nice12:00
persiagtristan: I'd say that even for projects with up to 8 active developers the separation is less necessary.  For projects with tens of developers, it becomes important, and at hundreds of developers critical.12:01
gtristanpersia, separation of bug tracking and patch review ?12:02
persiagerrit is usually described as "the least bad of the patch tracking solutions".  I have yet to meet anyone (including gerrit developers) that acutally likes it.12:02
persiagtristan: Yes.12:02
gtristanpersia, curiously, do you have a real world example ? Im curious to see that12:02
persiaIn Baserock, nothing is consuming the gerrit event streams, so we're not getting any of the automation which does things like validate the association between gerrit and a issue tracker, validation of code format or functionality, etc.12:03
gtristanI mean, of a project that uses gerrit and gets good mileage from it (or splits bug tracking and code review in some other way)12:03
jjardongtristan: hey, thanks for the drm patch review: with that i was able to start a GNOME wayland session and seems to work okish here (I do not see the mouse pointer but maybe that's related with other issue)12:04
gtristanpersia, right, my argument was that it should not have been applied without that, i.e. regarding unilateral changes12:04
radiofreegtristan: qt?12:04
toscalixgtristan: kde uses gerrit and bugzilla. Is that the kind of example you were askin for?12:04
toscalixyes, qt12:05
radiofree,n,z even12:05
gtristantoscalix, Yes, I'm curious how that works12:05
* gtristan opens link12:05
ssam2jjardon: no way to specify that except using the shell `if` and $MORPH_ARCH, at present12:05
gtristantoscalix, Do "users" really file bugs, btw ?12:06
gtristantoscalix, and would you say that it's an overhead to track discussion in a gerrit AND bug report instead of having that in the same page ?12:06
toscalixgtristan: kde in that regards is pretty much like gnome12:06
SotKgtristan: OpenStack use Gerrit and Launchpad (some parts use StoryBoard instead of Launchpad)12:06
gtristanin other words, users do not file bugs12:06
radiofreeqt uses jira for the bug tracking
radiofreewhich they link to gerrit12:07
radiofreei tried to find one that worked, but gave up, but see the "gerrit" tab
toscalixgtristan: in a big project, where you have to maintain several versions of the same "product", conversations about bugs and development are different. So it makes sense to use different tools.12:08
toscalixthe point with gnome and kde is that.... they take little care about previous/old versions12:08
toscalixso in that context... almost every activity is development12:09
toscalixso your view makes sense12:09
persiaI've seen lots of groups use jira+gerrit.12:09
persiaTo be fair, KDE does maintain two ABIs all the time, but the response to most bugs against the old ABI is "upgrade".12:09
* gtristan is looking for issues in,n,z where a patchset was actually discussed12:10
gtristanand new patchsets uploaded in response to maintainer comments12:10
jjardonssam2: ok, thanks12:10
toscalixpersia: yep12:10
radiofreegtristan: yeah, qt actually seems like a terrible example here12:10
gtristani.e., how do I see the whole picture, of why something was changed multiple times before landing12:10
persiaAlso, we had a session about this sort of thing at one of the Baserock meetups, where we decided to use mantis+gerrit, but were overridden by the fact that someone got storyboard running about 15 minutes after a small subset of us had decided on mantis, and before we were able to announce the decision at the end-of-day wrapup.12:11
persia(that said, I happen to personally like Storyboard, so I'm not opposed to what happened: I mostly only wish we had newer Storyboard in Baserock)12:11
gtristanI am not against storyboard (I have yet to see it really), but I am certainly against the version of storyboard in baserock :-/12:12
persiaIn an ideal world, one sees the whole picture, from the developer perspective, in the patch tracker.  The issue tracker only indicates that a solution (or partial solution for multi-task bugs) is under review.12:12
gtristanthe fact that baserock is years into development, and that we have a total of 65 bugs filed, is quite telling12:12
ssam2we have several older attempts at having a bug tracker which are full of dead and obsolete bugs12:13
ssam2some internal to Codethink12:13
persiaTo be fair, most of that is because bugs being sent to the mailing list was the old model, and nobody every tried to capture all the old ones and put them in Storyboard.12:13
gtristanpersia, one part of this ideal world I have a hard time with, is, only a subset of the issues which require tracking have an associated patch12:14
persiagtristan: Yes.  As noted, the implementation used in Baserock is a poor example.12:14
persiaI like what OpenStack is doing with Launchpad+Gerrit, but ever since Malone became only one component of Launchpad, I've found it is less useful as an issue tracker.12:15
gtristanThis link mentions LibreOffice, I think they are pretty organized, wonder how that is working for them12:16
gtristanJust spent some time talking in #libreoffice-dev...12:40
gtristanHere is a good example:
gtristanThe commit message of course links appropriately to:
gtristanThat could of course equally link to storyboard12:41
gtristanOf course, this is the opposite ideal world, *most* discussion actually happens in the bug tracker12:42
gtristanand gerrit is used at the latest phase, when a patch is submitted for the issue12:42
gtristanwhere hardly any discussion happens, but at least the commit links to the bug report12:42
*** tristan_baserock has joined #baserock13:01
* tristan_baserock types from empathy in Baserock GNOME VM13:01
gtristanAha !13:01
radiofreeheh, irc in baserock!13:03
* tristan_baserock tries XMPP google chat13:04
tristan_baserockawesome jjardon13:06
*** tristan_baserock has quit IRC13:06
*** tristan_baserock has joined #baserock13:06
jjardongtristan: nice! :)13:06
* tristan_baserock reaches jjardon from baserock VM :)13:07
tristan_baserockintegrated notifications work :D13:08
Zarahm, does baserock have a code of conduct yet? can't find anything.13:14
radiofreei don't think so13:16
Zara:/ should probably fix that. I've been pretty impressed with the way people approach discussion in openstack; maybe we can grab theirs.13:20
jjardonwe have this one in GNOME:
*** tristan_baserock has left #baserock13:27
persiagtristan: Thanks for the example.  I actually think that is a good example: all the useful user-facing discussion happened in the issue tracker.  The first version of the patch happened to be correct and landed.  Where it matters more is when a patch that is not in the right format, or fixes the bug in a way that breaks other things, or is coded in the wrong coding style, etc. lands for an issue, where these sorts of things can be discussed in the14:04
persiapatch tracker, without confusing the archive of the user-facing issue with details of the implementation of the fix.14:04
*** gtristan has quit IRC14:05
persiaWhen I was more involved in Ubuntu, sometimes the user-facing issue would be clear and obvious and well-reported, so that anyone capable could fix it in 5 minutes, but it wasn't high priority, so it would be marked "low-hanging fruit", which newcomers were encouraged to attempt.  The problem was that the process of mentoring the newcomer to get a consumable patch required a fair number of revisions, and having that in Malone, so that the user was14:05
persiapart of the virtual mailing list for the discussion caused significant complaint.14:05
persiaAnd it's too late at night for this conversation :(14:05
*** toscalix has quit IRC15:06
*** toscalix has joined #baserock15:09
pedroalvarezwell, now is running latest :)15:43
pedroalvarezpersia: ^^15:43
persiapedroalvarez: excellent!  Is this a snapshot, or does it track the output of Storyboard CI?15:44
pedroalvarezdon't get the question15:45
pedroalvarezis not going to be auto-upgraded15:45
pedroalvarez(if that was the question)15:45
persiaThat was the question :)15:45
ssam2it is vastly better!! pedro brings us an early Christmsa!15:46
ssam2*christmas even15:46
pedroalvarezthe first instance of storyboard with email support15:46
tiagogomesI can't login, should I be able to?15:47
*** edcragg has quit IRC16:09
*** ctbruce has quit IRC16:55
*** ssam2 has quit IRC16:58
*** CTtpollard has quit IRC17:10
*** toscalix has quit IRC17:23
*** bashrc has quit IRC17:58
*** locallycompact has quit IRC18:19
*** tiagogomes has quit IRC18:47
*** gtristan has joined #baserock19:13

Generated by 2.15.3 by Marius Gedminas - find it at!