| === jtv1 is now known as jtv | ||
| === Pendulum_ is now known as Pendulum | ||
| micahg | cjwatson: everything is confirmed published | 03:23 |
|---|---|---|
| wallyworld_ | StevenK: did you know RemoveArtifactSubscriptionsJob doesn't handle branches where access is revoked using the sharing ui? | 06:03 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| StevenK | wallyworld_: Uh, no. Guess I missed a callsite. :-( | 06:48 |
| === almaisan-away is now known as al-maisan | ||
| adeuring | good morning | 07:43 |
| === al-maisan is now known as almaisan-away | ||
| === matsubara is now known as matsubara-afk | ||
| adeuring | jelmer: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-1020443/+merge/115721 ? | 12:47 |
| salgado | I thought the comment box on a merge proposal would preserve the formatting, but it just ruined a review of mine :( | 12:47 |
| salgado | https://code.launchpad.net/~diogobaeder/ubuntuone-servers/consistency-check/+merge/115441/comments/248694 | 12:48 |
| salgado | has that changed recently? | 12:48 |
| salgado | actually, if I get the comment from that URL it looks right, but on https://code.launchpad.net/~diogobaeder/ubuntuone-servers/consistency-check/+merge/115441 it's not formatted | 12:48 |
| jelmer | adeuring: on it | 12:49 |
| adeuring | jelmer: thanks! | 12:49 |
| cjwatson | Could somebody allocate me a DB patch number? I would like to add "ALTER TABLE ArchivePermission ADD COLUMN distroseries INTEGER;" in order to support implementation of per-pocket queue admin permissions; feedback from the relevant stakeholders has convinced me that we may need to be able to grant some people access to admin e.g. quantal-proposed but not precise-proposed. | 12:56 |
| rick_h_ | cjwatson: will work on it, sec | 12:58 |
| rick_h_ | cjwatson 2209-27-1 allocated | 13:00 |
| cjwatson | rick_h_: Thanks | 13:01 |
| deryck | Morning, everyone. | 13:01 |
| rick_h_ | morning boss | 13:01 |
| deryck | adeuring, https://plus.google.com/hangouts/_/8a443b035ee300fdac4f1b58feadf013d81db8e7?authuser=0&hl=en | 13:32 |
| === almaisan-away is now known as al-maisan | ||
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| mgz | so, this looks like a good example | 14:14 |
| mgz | the current head of the qa queue is qa-bad | 14:15 |
| mgz | so, the normal thing would be to revert that change? is that generally left to the person who landed it? | 14:15 |
| jelmer | mgz: Yes, if they are around | 14:20 |
| jelmer | I guess generally it's left to the person doing the QA | 14:21 |
| mgz | so, you'd basically do `bzr lp-land --rollback=15645 lp:launchpad` then? or do you actually revert the change in a branch locally? | 14:23 |
| mgz | rollback sounds not like "merge the inverse of this change" but I assume it doesn't actually lose subsequent things in the queue | 14:24 |
| jelmer | mgz: yeah, merge the inverse of that change | 14:26 |
| jelmer | mgz: You'll actually have to revert the change locally and push a branch up for merging. | 14:27 |
| mgz | but do you need to actually do that and put up an mp? | 14:27 |
| mgz | meh. | 14:27 |
| mgz | so, is just tagging not fanciness. | 14:27 |
| jelmer | mgz: well, the tagging is important for the qa bot | 14:27 |
| jelmer | not sure if that qualifies as fanciness.. | 14:28 |
| cjwatson | You merge the inverse of that one change, not everything after it in the queue. | 14:29 |
| cjwatson | There's something about it on dev.lp.net somewhere. | 14:29 |
| rick_h_ | right, mgz what I did the other day was to grab the branch, diff -r with the rev and the one before to generate a patch to remove that rev | 14:29 |
| rick_h_ | then create a new branch from trunk, apply the patch, submit to pqm with bzr lp-lang | 14:30 |
| cjwatson | https://dev.launchpad.net/QA/QAForContinuousRollouts | 14:30 |
| rick_h_ | land that is | 14:30 |
| mgz | do you just merge the branch, or put it through review? | 14:30 |
| * mgz reads the page | 14:31 | |
| mgz | "get it reviewed, or review it yourself" | 14:31 |
| cjwatson | I think the general implication of that is that if you are a reviewer then this is the kind of change you can self-review. | 14:31 |
| jcsackett | mgz, cjwatson: correct--we allow self review for full reviewers on things like that. | 14:31 |
| cjwatson | I'm not a reviewer so I think if I were doing this I would get somebody to review it. | 14:32 |
| rick_h_ | mgz: yea, as long as you're only removing the one rev it's generally a self-review. | 14:32 |
| jcsackett | if you're not a full reviewer, well, i'm on call today. :-) | 14:32 |
| rick_h_ | put jcsackett to work! | 14:32 |
| rick_h_ | I don't have any giant JS branches today, he's going to feel lonely | 14:32 |
| mgz | okay, I don't expect StevenK will mind me doing this as practice | 14:32 |
| jcsackett | rick_h_: there's a somewhat easier way to do the rollback than the "create patch with diff, then apply" process, btw. | 14:32 |
| rick_h_ | jcsackett: I'm all ears | 14:32 |
| jcsackett | bzr merge . -r [revno-to-revert]..[revno-to-revert-1] | 14:33 |
| cjwatson | QAForContinuousRollouts recommends that. | 14:33 |
| rick_h_ | ah makes sense, one less step | 14:33 |
| * jcsackett nods. and when you're in qa triage, less steps are good. :-) | 14:33 | |
| mgz | hm, interestingly StevenK already did the rollback last night, but it doesn't show up on lpqateam | 14:49 |
| jcsackett | adeuring: looking at your branch in review--doesn't this need to be landed against db-devel, not devel? | 14:49 |
| adeuring | jcsackett: no, since there is not schema change or any other "serious impact", it can be landed in devel. Seehttps://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess | 14:50 |
| jcsackett | adeuring: ah, cool. thanks. | 14:52 |
| rick_h_droid | mgz is it in buildbot then? | 14:54 |
| mgz | nothing on pqm.launchpad.net | 14:55 |
| mgz | am I looking in the right place? | 14:56 |
| cjwatson | mgz: http://lpbuildbot.canonical.com/waterfall | 14:56 |
| cjwatson | ETA 1h54m | 14:56 |
| jcsackett | adeuring: the diff i see looks good, but the MP says there's a conflict in need of resolution. (the patch file appears to already exist). fix that up and i can stamp this r=me. | 14:57 |
| adeuring | jcsackett: argh... thanks for the heads-up! | 14:57 |
| jcsackett | adeuring: your welcome. | 14:58 |
| cjwatson | mgz: the flow as I understand it is devel -> buildbot (whenever it next starts a run) -> buildbot completes 5/6h or so later -> qastaging's buildbot-poller runs every 15m or so IIRC and picks that up -> qastaging.lp.net updates -> the deployment report notices shortly afterwards | 15:00 |
| adeuring | jcsackett: done | 15:00 |
| cjwatson | this is admittedly divined from observation :) | 15:00 |
| jcsackett | adeuring: awesome. i'm waiting on the diff to update. :-) | 15:00 |
| mgz | and everyone lands with a full test run anyway... | 15:01 |
| mgz | not sure what the double gating helps exactly. | 15:01 |
| jcsackett | mgz buildbot after ec2 picks up multiple revisions. makes sure if three of us start from the same branch and do something bad with another person's work things don't get broken. | 15:01 |
| jcsackett | (three being an arbitrary number, of course) | 15:02 |
| cjwatson | the test run is based on whatever was current at the time you started the test run, but what lands on devel is a merge based on whatever's current when the test run ends | 15:02 |
| cjwatson | and buildbot does sometimes fail as a result of that | 15:02 |
| mgz | ah, another the-test-suite-takes-5-hours adaptation | 15:02 |
| jcsackett | mgz: if you like. :-P | 15:03 |
| jml | mgz: exactly. | 15:06 |
| jcsackett | cjwatson: can you file and link bugs for both of your branches? neither seem like the sort of thing that should be landed with --no-qa. | 15:07 |
| jml | cjwatson: https://dev.launchpad.net/Trunk, https://dev.launchpad.net/Trunk/Glue | 15:07 |
| cjwatson | jcsackett: OK | 15:08 |
| cjwatson | jml: Ah, yes, I probably read those at some point | 15:08 |
| jml | mgz: although I think we were all complaining about the length of the PQM queue back when the test suite took 1hr. It was common to be waiting 16hrs or more for a branch to land | 15:08 |
| jml | mgz: so arguably, mean time to land is shorter with this setup. | 15:09 |
| rick_h_ | and when the parallel test guys save us we'll be awesome | 15:09 |
| jml | although it's very frustrating to have a change rejected because of someone else's mistake | 15:09 |
| mgz | when we completely hosed the bzr test suite so it took going on for an hour the pqm queue became a pain | 15:10 |
| jml | rick_h_: I would strongly recommend switching back to a more pqm-like model in that case | 15:10 |
| mgz | so the test suite was made fast again. | 15:10 |
| rick_h_ | mgz: yea, and the parallel guys are reporting sub-50min numbers. | 15:10 |
| jml | mgz: yeah. LP devs never did that. I got a bit sick of talking about it so I wrote <https://dev.launchpad.net/FasterTests>. It's probably a bit out of date. | 15:10 |
| mgz | will parallel testing be done both for the buildbot step and the I'm-just-checking-my-own-branch step? | 15:10 |
| jcsackett | adeuring: r=me, but you'll want to update the values in INSERT INTO LaunchapdDatabaseRevision to match the patch number. | 15:11 |
| jml | mgz: the pqm model scales poorly to large numbers of developers | 15:11 |
| adeuring | jcsackett: argh... not my best day. thanks! | 15:11 |
| mgz | jml: it mostly scales badly for NEWS files... | 15:11 |
| jcsackett | adeuring: it happens. :-P | 15:11 |
| jml | mgz: arguably a work-around would be to merge them all in, run the tests, and in case of failure try again but with half of the queue, ... | 15:11 |
| mgz | made me not want to ever write any, to avoid pointless conflicts | 15:12 |
| jml | mgz: that's Bazaar's fault, I think. | 15:12 |
| mgz | right, and never getting news merge working on pqm | 15:12 |
| jml | mgz: Twisted works around that by having one file per NEWS update, and building the NEWS file as part of the release process | 15:12 |
| mgz | yeah, that's very cute, and so twisted | 15:12 |
| jelmer | :-) | 15:13 |
| rick_h_ | there's always a work around :) | 15:13 |
| jml | mgz: I don't think it's a good work-around, but it's better than the pain of pointless conflicts. | 15:13 |
| jelmer | the custom bzr news merger has worked quite well for us | 15:14 |
| jml | I want to set up jenkins to have a pqm model for landing branches | 15:15 |
| jcsackett | cjwatson: i'm looking at your security upload branch. i'll confess to being unfamiliar with the processes around this. i assume without this check there are stil checks to keep just anyone from uploading to the pocket? | 15:15 |
| cjwatson | jcsackett: Much like -proposed/-updates, any upload to it would require manual approval by a queue admin | 15:16 |
| jcsackett | cjwatson: ah, dig. | 15:16 |
| jcsackett | thanks. | 15:16 |
| cjwatson | jcsackett: In fact, today, anyone with upload rights to Ubuntu could attempt to copy a package into it (and it'd be similarly held for approval) | 15:16 |
| cjwatson | Since copy permissions == upload permissions (I actually think copy permissions should be very slightly broader, but that's a different bug) | 15:17 |
| jcsackett | cjwatson: ok. so this is completely unnecessary, as there's a manual check anyway, and if someone were operating in bad faith for some reason they would have a way around it anyway. | 15:17 |
| cjwatson | I did ask the Ubuntu security team manager if he was OK with this, but he's on holiday this week | 15:17 |
| cjwatson | The history of that code definitely looks like a fossil though | 15:18 |
| cjwatson | I actually ran into it because I was trying to test something else on dogfood and it wouldn't let me upload to -security there :) | 15:18 |
| cjwatson | In practice we probably want to stage elsewhere most of the time anyway because that makes sure everything's built before we expose it to users. But that seems like a distro policy decision rather than something that should be hardwired into code. | 15:20 |
| jcsackett | cjwatson: that makes sense. thanks. | 15:20 |
| jcsackett | cjwatson: both your branches are r=me, but remember to file/link bugs so the qa can be tracked. :-) | 15:21 |
| jcsackett | ah, i see you already have on one. | 15:21 |
| cjwatson | yup, working on it. | 15:24 |
| cjwatson | thanks | 15:24 |
| mgz | meh, I should just fix this mailman thing | 15:24 |
| stub | adeuring: Whoops. I forgot to push my dbpatches change. | 15:44 |
| stub | ta | 15:44 |
| adeuring | stub: no problem,. I added a note about your patch ;) | 15:44 |
| === matsubara-afk is now known as matsubara | ||
| === al-maisan is now known as almaisan-away | ||
| SpamapS | Is there a minimum level of performance one should be able to expect from buildds (particularly PPA builders) ? | 16:38 |
| SpamapS | The juju test suite wants every test to finish in 5 seconds or less.. | 16:38 |
| SpamapS | but on many of the PPA builders that just doesn't happen | 16:38 |
| cjwatson | That sounds pretty wrong. | 16:39 |
| cjwatson | I mean, of the juju test suite. | 16:39 |
| SpamapS | Its just a default, but each test is meant to be very tiny | 16:39 |
| SpamapS | on my Core2Duo 2.5Ghz machine with crap disk, they all finish in under 2s reliably.. | 16:39 |
| cjwatson | I don't think it should be allowed to assume anything in particular. They're Xen instances, they could be timesliced off into oblivion for a while | 16:40 |
| SpamapS | cjwatson: nannyberry, in particular, seems to be quite a bit faster than all the rest | 16:40 |
| SpamapS | cjwatson: but, that said, I suppose we should just raise the test timeout to 20s for package builds (which is unfortunate as we will miss performance regressions) | 16:41 |
| mtaylor | SpamapS: I would suggest not using ppa builders as a place to test performance regressions | 16:41 |
| SpamapS | indeed, its not really a place to do that. :) | 16:41 |
| mtaylor | SpamapS: I know of this really neat software called jenkins ... | 16:42 |
| mtaylor | and then I'd suggest getting a bare metal machine that only runs your performance tests so that one performance test's output can be actually compared against another | 16:43 |
| mtaylor | but that might just be me | 16:43 |
| SpamapS | mtaylor: I heard jenkins is just cron on steroids | 16:43 |
| mtaylor | SpamapS: you could totally do cron | 16:43 |
| mtaylor | SpamapS: or you could use a combination of gearman and salt | 16:43 |
| SpamapS | which means it is strong but aggressive and moody ;) | 16:43 |
| mtaylor | to do queuing and remote command execution | 16:44 |
| cjwatson | Right, I agree. Performance tests in package builds are a mug's game. | 16:44 |
| mtaylor | but whatever you do, I would not use ppa builders for performance testing | 16:44 |
| SpamapS | well up until now they've been that just because of twisted trial's default 5s timeout | 16:44 |
| cjwatson | You could even register DEP-8 format tests (autopkgtest) and then your tests will be automatically run in jenkins. | 16:44 |
| * SpamapS is about to patch that away | 16:44 | |
| mtaylor | SpamapS: you could stop using twisted of course ... | 16:47 |
| SpamapS | mtaylor: we are! | 16:47 |
| SpamapS | -> go | 16:47 |
| * mtaylor facepalms | 16:47 | |
| mtaylor | SpamapS: don't you love it how you come here to ask a simple question and we all start kicking you? | 16:47 |
| SpamapS | what, a compiled language w/ static-only-linking isn't a good answer to "twisted is hard" ? | 16:47 |
| mtaylor | SpamapS: well, "twisted is overkill for the task juju needs to perform" would be my first answer to "twisted is hard" | 16:48 |
| SpamapS | I was feeling a bit doughy.. a good kicking will get me back into shape :) | 16:48 |
| mtaylor | SpamapS: so, my first suggestion would have been "remove twisted and replace it with normal python calls" | 16:48 |
| cjwatson | Gosh, that might have interfered with religion | 16:48 |
| cjwatson | ... was that my out loud voice? | 16:49 |
| mtaylor | oops. sorry about that | 16:49 |
| * mtaylor tries to stop interfering with religion | 16:49 | |
| * mtaylor stops pointing out assininery around twisted and go | 16:49 | |
| cjwatson | I certainly wasn't trying to stop you :) | 16:49 |
| jml | http://www.joelonsoftware.com/articles/fog0000000069.html | 16:56 |
| cjwatson | Yes, I want to sellotape that URL to my head at conferences sometimes | 16:59 |
| jml | :) | 17:01 |
| jml | I want to find a well-written article that explains that writing new software is almost always a worse idea than you think it is. | 17:02 |
| mgz | wouldn't bother with well written, just go for big letters | 17:05 |
| cjwatson | "programmers always want to throw away the code and start over" IME this is the bit where Joel missed a trick; it's far from always programmers who are the driving force behind rewrites ... | 17:05 |
| SpamapS | true, though it is generally the programmers who whine about the messy code and thus the business folk figure "well its probably time for a rewrite" | 17:10 |
| SpamapS | "this will make us more nimble" | 17:10 |
| rick_h_ | abentley: ping, do you have time to chat on this lp.client issue? | 17:17 |
| abentley | rick_h_: lunching. back in 30. | 17:18 |
| rick_h_ | abentley: ack | 17:18 |
| mgz | what's aaron's fancy script for generating lp merge proposals again? | 17:42 |
| rick_h_ | bzr lp-propose | 17:42 |
| mgz | as in, not just lp-propose, but the one that makes a little template too | 17:42 |
| abentley | rick_h_: back. | 17:45 |
| rick_h_ | abentley: cool, will toss a hangout your way | 17:46 |
| czajkowski | rick_h_: do you happen to know if you need multiple projects to have bug targets | 17:47 |
| rick_h_ | czajkowski: otp sec | 17:53 |
| czajkowski | rick_h_: cheers | 17:54 |
| rick_h_ | czajkowski: hmm, abentley can sanity check me, but to target something it could be a different distro, release, source package, etc. so not necessarily different projects | 18:10 |
| czajkowski | YokoZar: there is your answer | 18:11 |
| czajkowski | rick_h_: thank you | 18:11 |
| abentley | mgz: lp-propose, with the lpreview_body plug-in. | 18:12 |
| mgz | abentley: thanks, where's lpreview_body in lp? | 18:17 |
| YokoZar | rick_h_: could you clarify how I would do this for a private project? | 19:19 |
| YokoZar | *commercial project | 19:19 |
| barry | um, i think adding comments to bug tasks may be broken. i just got an error that says "Object:, name: u'acton'" | 19:39 |
| sinzui | Yokozar, I don't see your question. What is it? I know a lot about projects with private bugs and branches | 19:50 |
| czajkowski | sinzui: need multiple projects to have bug targets | 19:52 |
| czajkowski | 19:10 < rick_h_> czajkowski: hmm, abentley can sanity check me, but to target something it could be a different distro, release, source package, etc. so not necessarily different projects | 19:53 |
| sinzui | targeting rules are byzantine. In the case of a bug, a project can be retargeted to another project using ajax. Otherwise, expand the html form to select distro, package, or project | 19:56 |
| sinzui | series and series packages can only be retargeted to other series and series packages | 19:56 |
| YokoZar | sinzui: So, my full question is this: I currently have one commercial project registered. In order to use Launchpad bugs instead of our own independent tracker, I'd like to be able to have different components within (eg -server, -client). Do I need to register multiple projects for this (and pay for each one?) | 21:03 |
| sinzui | YokoZar: yes you do | 21:04 |
| sinzui | Lp does not understand components and shared repos | 21:05 |
| sinzui | YokoZar: we can create a project group for your project which will let you search all the bugs in all the projects. czajkowski or myself can create one once you have two projects to add to it | 21:06 |
| sinzui | YokoZar: also, it is okay to structure your projects so that only one of them contains the proprietary code. several projects groups mix public and private code. They commonly have a private server part, or the plugins are all proprietary | 21:08 |
| YokoZar | sinzui: I might not code-host on launchpad at all at the moment (we have stuff in github) | 21:08 |
| sinzui | understood | 21:09 |
| YokoZar | sinzui: but I do need things like private PPA and private bugs by default; I suppose I can confine the PPAs to one project | 21:10 |
| sinzui | YokoZar: if your not hosting code, consider one project and use bug tags to distinguish the components | 21:10 |
| sinzui | ppas are owned my teams, not projects. PPAs often contain packages based on many projects. | 21:11 |
| sinzui | YokoZar: one you add the proprietary license to your private project, you can enable private bugs, create private teams, and create private ppas, The team can be public, and you can still have a private ppas | 21:12 |
| sinzui | YokoZar: you might be tempted to create one project, with a series that represents each component. You can target bugs to the series. you can say a bug affects many series. You cannot retarget the series task from one to another, but you can delete the task and create an alternate task. | 21:17 |
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| YokoZar | sinzui: Thanks, I think that will work quite well for me | 23:00 |
| StevenK | Fail. http://sqlformat.appspot.com/ | 23:38 |
| StevenK | wgrant: Is http://pastebin.ubuntu.com/1101043/ a bong query for returning direct subscriptions? | 23:38 |
| wgrant | StevenK: Maybe. Does it work? | 23:51 |
| wgrant | Also, it's a bit odd to constrain both BS.bug and BTF.bug rather than joining them explicitly. | 23:52 |
| StevenK | wgrant: It does not seem to work, no. | 23:52 |
| wgrant | StevenK: Oh | 23:55 |
| wgrant | StevenK: The privacy condition is inverted | 23:55 |
| wgrant | AND NOT ( | 23:55 |
| wgrant | BugTaskFlat.information_type IN (1, 2) | 23:55 |
| wgrant | [...] | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!