[12:55] <Satoris> Anyone else have 4 finger swipe for the dash broken in Unity-2D?
[13:06] <bregma> I'm assuming touchpad?
[13:08] <Satoris> Magic trackpad.
[13:08] <Satoris> s/dash/panel/
[13:11] <Satoris> I get 4 finger touch events through XInput.
[14:00] <Satoris> Unity-2D's bug list seems to indicate that they are reworking 4 finger swipe gesture code as we speak.
[14:14] <tvoss> migrating utouch-jobs to production jenkins, grail, frame and geis are done, evemu to go
[14:15] <bregma> where is the production jenkins located?
[14:15] <cnd> jenkins.qa.ubuntu.com?
[14:15] <Satoris> Bug filing, QA script tuning, randomage.
[14:15] <cnd> I'm still trying to dig out of a ton of X patches that I'm working on for ubuntu and upstream
[14:16] <cnd> it seems that I still don't have touchscreens working quite right
[14:16] <tvoss> cnd, bregma: Results from production jenkins are exported to the public instance
[14:17] <dandrader> my stand-up report: Improving port of unity code to geis v2 API. Making it use regular recognizer (no atomic gestures) and accept()/reject() gestures.
[14:18] <Satoris> cnd: where did you get the sortable multi column kernel report HTML? The code in Arsenal only prints bug id, title and series.
[14:18] <bregma> I'm beavering away on the grail config stuff
[14:19] <cnd> Satoris, I don't know where the code lives, I just noticed it on qa.ubuntu.com
[14:19] <cnd> Satoris, I suggest asking bjf in #ubuntu-kernel
[14:20] <cnd> tvoss, when I try to get to the code coverage, jenkins can't find the source code
[14:20] <cnd> https://jenkins.qa.ubuntu.com/job/ps-utouch-grail-daily-amd64/1/cobertura/_home_ubuntu_jenkins_workspace_ps_utouch_grail_daily_amd64_pbuilder_setup_work_trunk_src_v3/atomic_recognizer_cpp/
[14:20] <tvoss> cnd,
[14:20] <cnd> do you know why that would be?
[14:21] <tvoss> I would guess that the job-publisher plugin does not take into account that it would need to copy the overall source code to provide that annotated view
[14:21] <bregma> hey -- do we need to have a call today (in 10 minutes)?
[14:21] <cnd> bregma, I assume so
[14:21] <cnd> but olli's not online...
[14:21] <Satoris> He's gone until wednesday.
[14:21] <bregma> he's not physically available
[14:22] <cnd> oh ok
[14:22] <cnd> well, then I guess not
[14:22] <cnd> Satoris, tvoss, bregma, dandrader: have you all done peer reviews and the review of olli?
[14:22] <cnd> dandrader, I dunno if you had to do it
[14:22] <tvoss> cnd, ack
[14:22] <Satoris> What is the "review of Olli"?
[14:23] <cnd> Satoris, you have to review your mgr
[14:23] <bregma> I haven't done my taxes yet, either
[14:23] <cnd> bregma, Satoris: these reviews were due last wednesday
[14:23] <Satoris> Allhands does not give me a link to do that.
[14:23] <bregma> right, I'll get right to it
[14:23] <cnd> hmm... maybe you missed it
[14:23] <dandrader> cnd, I think I'm out of it since I'm a newcomer
[14:24] <cnd> Satoris, it should be in your tasks
[14:24] <bregma> check all outstanding tasks, its not always obvious
[14:24] <Satoris> Allhands is not allowing me to log in. Grumble.
[14:25] <Satoris> But last I checked, my outstanding tasks did not have that.
[14:25] <cnd> tvoss, how will we do one-shot builds?
[14:25] <Satoris> Logged in, no manager review task that I can see.
[14:26] <tvoss> cnd, still on staging. Migrating that service is still up to discussion :/
[14:26] <cnd> ok
[14:26] <cnd> tvoss, that doesn't really need to be moved
[14:26] <cnd> but it would be nice to be able to email launchpad
[14:26] <cnd> and we need to figure out why geis is always failing...
[14:26] <tvoss> cnd, ack ... larry is on that, I motivated it with a mail to the mp
[14:27] <cnd> heh
[14:27] <tvoss> the example mailing to the merge-proposal
[14:38] <cnd> Satoris, btw, I found something on friday
[14:38] <cnd> instead of searching for all bugs for specific upstreams, we can use the canonical-utouch meta project
[14:38] <cnd> sorry, canonical-multitouch
[14:38] <cnd> https://bugs.launchpad.net/canonical-multitouch
[14:39] <Satoris> That does not list bugs in e.g. Unity-2D.
[14:39] <cnd> no, we still have to search for them
[14:39] <cnd> right now we have three searches:
[14:39] <cnd> 1. ubuntu packages structurally subscribed by utouch-bugs
[14:40] <cnd> 2. all other ubuntu bugs subscribed by utouch-bugs
[14:40] <cnd> 3. all upstream bugs in a list of packages
[14:40] <cnd> we can replace 3 with all bugs against canonical-multitouch
[14:40] <cnd> so we don't have a static list that must be updated any time we make a new project
[14:41] <Satoris> What is the list of packages that canonical-multitouch provides and why are they not already in 1?
[14:41] <cnd> 1.  is ubuntu packages, canonical-multitouch is for the upstreams of those packages
[14:43] <Satoris> Which are all our projects, right?
[14:44] <cnd> probably, but not necessarily
[14:45] <cnd> for example, we may not have a package for a project yet
[14:45] <cnd> but we may have bugs for it
[14:45] <cnd> to track development
[14:46] <Satoris> The query 1 I currently have does not make any distinction between packages and projects. It takes them all.
[14:46] <cnd> what do you mean?
[14:46] <cnd> I know it only searches for bugs against ubuntu packages because otherwise it would timeout
[14:47] <cnd> unless I'm remembering wrong
[14:47] <Satoris> What timeouts?
[14:47] <bregma> for query 1, isn;t the project 'ubuntu'?
[14:48] <cnd> launchpad times out if the query takes too long
[14:48] <cnd> bregma, right
[14:48] <Satoris> I have never had that issue...
[14:49] <cnd> Satoris, try searching for *all* bugs structurally subscribed by utouch-bugs
[14:49] <cnd> not bugs against the ubuntu project
[14:49] <cnd> it will timeout
[14:50] <Satoris> cnd: as far as I can tell, get_touch_bugs.py already does that. Line 106.
[14:50] <Satoris> Sorry, line 108.
[14:51] <cnd> Satoris, that only gets direct subscriptions
[14:51] <Satoris> Or is structural subscription somewhere else.
[14:51] <cnd> the issue is when you attempt to get structural subscriptions for all bugs
[14:52] <cnd> we don't really query launchpad that way because it times out
[14:52] <Satoris> And you can subscribe to packages, but not to projects?
[14:52] <cnd> you can subscribe to both
[14:52] <cnd> but you can't query based on structural subscriptions effectively because lp times out
[14:53] <Satoris> The other scripts do this by querying tags.
[14:53] <cnd> we have the canonical-multitouch project, so we can use that
[14:53] <cnd> that way we don't have to mess with tags
[14:53] <Satoris> Anyway, I think this is getting way too complicated. We don't create new projects or packages very often. We can just keep them in a list.
[14:54] <cnd> Satoris, how is it complicated?
[14:54] <cnd> I mean, it's already somewhat complicated because lp has issues
[14:54] <cnd> but I don't see how this development makes it "too" complicated
[14:55] <Satoris> To clarify: we want a list of bugs in a) certain projects/packages and b) where utouch-bugs is directly subscribed, right?
[14:55] <cnd> yes, where certain projects is canonical-multitouch upstream, and any ubuntu packages that utouch-bugs is structurally subscribed to
[14:56] <Satoris> And this list of projects changes how often?
[14:57] <cnd> not too often, but why does that matter?
[14:57] <Satoris> Because the time we have spent discussing this is already greater than the amount of time to manually update the list from here to eternity.
[14:58] <Satoris> If LP interface has issues, why use it?
[14:58] <Satoris> Do the simplest possible thing first and only if it is not good enough should you look into more complex solutions.
[14:59] <cnd> I'm trying to make it simpler
[14:59] <Satoris> There are scripts already in Arsenal to query for bugs in a list of packages. We could just use those.
[14:59] <Satoris> If the list is static.
[15:00] <cnd> Satoris, we need the data formatted in ways that other scripts aren't providing, afaict
[15:00] <cnd> we want to see the different tasks of a bug, including the upstream and the ubuntu packaging bugs
[15:00] <Satoris> If we want the tree thing, yes. But those are not sortable.
[15:01] <Satoris> Since we are the upstream and packagers, they are really not that different.
[15:02] <cnd> Satoris, they are because we need to track what has been fixed upstream vs in ubuntu
[15:02] <Satoris> There are two different problems here. 1) what bugs to query and 2) how to present this information.
[15:03] <Satoris> Is there a case where we would fix a bug in Ubuntu and not immediately apply the same fix to trunk?
[15:03] <cnd> Satoris, it's the other way around
[15:03] <cnd> we might have bugs fixed upstream and not in ubuntu yet
[15:03] <cnd> usually
[15:04] <Satoris> But if it is a bug that we are going to fix in Ubuntu, why would we not immediately push it out?
[15:04] <cnd> because you don't make a release for every bug you fix
[15:04] <cnd> releases take time, and we sometimes need to test them more
[15:05] <cnd> such as for SRUs
[15:05] <bregma> feature freezes
[15:05] <bregma> release freezes
[15:05] <Satoris> If it is not tested enough to go out as an SRU, it should not go to trunk.
[15:05] <Satoris> The situation would of course be different if we were not our own upstream.
[15:06] <cnd> Satoris, I don't understand why you are pushing back
[15:06] <bregma> bugs are reported in Ubuntu that are not necessarily reported against the upstream package, too
[15:06] <bregma> we can't always rely on seb for fixing that
[15:07] <Satoris> cnd: the other scripts do not care about bug tasks, only bugs. That makes them simpler than what we are trying to do. Since we are doing more complicated stuff we need to have a good reason for it.
[15:07] <cnd> Satoris, we do have a good reason for it
[15:07] <cnd> and it's not just utouch
[15:08] <cnd> tedg,  was complaining about this exact same issue for his projects
[15:08] <cnd> this has uses throughout PS
[15:08] <Satoris> That's good. Does he have a good description on what he needs? More input is always better.
[15:09] <cnd> I think if we can figure something out that works well for us we then have a good starting point
[15:10] <tedg> I'm sure what the question is exactly, but I'm happy to bitch if needed ;-)
[15:10] <Satoris> I'll leave for today. Please send me an email that outlines what the HTML page should show, how it should be formatted and so on. I currently don't have a clear vision on what you are trying to achieve.
[15:11] <cnd> Satoris, I don't have a great idea either
[15:11] <cnd> we have to experiment
[15:11] <cnd> I think you are getting close
[15:11] <cnd> the sortable web page you sent me today works pretty well
[15:11] <cnd> it just needs the information for the ubuntu packaging task too
[15:11] <Satoris> Hmm, it should be there already...
[15:11] <cnd> secondarily, we should be using canonical-multitouch to search for upstream bug reports
[15:12] <Satoris> My bad, it's not. I'll add it.
[15:13] <Satoris> cnd: the main problem (which I forgot to mention) is that those mako files need a completely different form of JSON, the generator of which is only inside one of the get-bug-foo scripts. And it is intertwingled with everything else.
[15:14] <cnd> Satoris, could you refactor it to make it better?
[15:14] <Satoris> get_touch_bugs.py can not generate it.
[15:15] <Satoris> cnd: now we get into the issue that Arsenal does not have good library design behind it. Code is copypasted. Getting that fixed is a group effort or we just go into madness.
[15:15] <cnd> Satoris, you can start it
[15:16] <Satoris> Perhaps. But not today. I'm off, see you tomorrow. ->
[15:19] <cnd> I'll biab