| lifeless | afk - hospital visit | 00:57 |
|---|---|---|
| rockstar | wallyworld, hi | 01:36 |
| wallyworld | rockstar: hello, just have to deal with a little domestic issue. can i ping you shortly? | 01:41 |
| rockstar | wallyworld, sure. | 01:41 |
| wallyworld | thnks | 01:41 |
| rockstar | wallyworld, although there is a Michigan game on tonight, so I might be a bit distracted... ;) | 01:41 |
| wallyworld | rockstar: skype? | 01:52 |
| thumper | rockstar: http://pastebin.ubuntu.com/517782/ | 01:53 |
| thumper | devel is not very happy right now | 01:53 |
| * thumper tries windmill tests locally | 02:01 | |
| wallyworld | thumper: what was the failure message? | 02:02 |
| thumper | wallyworld: full errors here - https://lpbuildbot.canonical.com/builders/lucid_lp/builds/274/steps/shell_6/logs/summary | 02:02 |
| rockstar | thumper, yeah, I think all windmill tests should be disabled. | 02:03 |
| rockstar | wallyworld, sure. | 02:04 |
| thumper | rockstar: and replaced with what? | 02:04 |
| rockstar | thumper, well, with jstestdriver, but for now, just not replace it. | 02:19 |
| rockstar | thumper, basically, windmill tests aren't telling us what they're supposed to be telling us. | 02:19 |
| rockstar | I mean, what good is a test that randomly decides it's broken? Might as well have no tests at all. | 02:19 |
| === Ursinha is now known as Ursinha-afk | ||
| mwhudson | it's a mean thing to say, but the status of the windmill tests makes me glad not to be a fulltime lp developer any more :/ | 02:54 |
| rockstar | mwhudson, yeah. :( | 03:13 |
| beuno | thumper, we're using jstestdriver in ubuntu one and landscape | 03:20 |
| thumper | beuno: and how's that working for you? | 03:20 |
| beuno | hopefully, that knowledge will go back with rockstar and he can migrate LP, if it makes sense | 03:20 |
| beuno | thumper, they are reliable tests, that I can tell you :) | 03:21 |
| * thumper wants reliable tests | 03:21 | |
| beuno | also, there's a nice way of TDDing with javascript | 03:21 |
| beuno | which I have been meaning to send an email about for months | 03:21 |
| beuno | my new plan is to talk to rockstar, and let him be the messenger and take all the credit | 03:21 |
| rockstar | beuno, :) | 03:21 |
| rockstar | Yeah, the fact that _GMAIL_ gets tested with jstestdriver indicates to me that it's very robust. | 03:22 |
| beuno | they moved away from browsers clicking stuff | 03:22 |
| beuno | it didn't scale and they spent more time chasing false positives than actual problems | 03:23 |
| * thumper votes to slaughter windmill with prejudice | 03:23 | |
| thumper | beuno: I don't want to have six months of windmill pain before we get something reliable | 03:24 |
| thumper | beuno: please send email :-) | 03:24 |
| beuno | thumper, I will have rockstar locked up in a third world country for a week, I'll make sure someone does so | 03:25 |
| thumper | beuno: what? Florida? | 03:25 |
| beuno | more country | 03:25 |
| beuno | buenos aires | 03:25 |
| rockstar | thumper, yeah, this is where I'm stuck as well. We have no resources to maintain windmill, but we also have no resources to switch. | 03:26 |
| rockstar | I would make it a personal vendetta if branch merge queues weren't already my personal vendetta. :) | 03:28 |
| thumper | lifeless: what are your thoughts on killing windmill and instating jstestdriver? | 03:34 |
| thumper | lifeless: we need to do something | 03:34 |
| thumper | lifeless: because what we have right now is a pile of smelly doggy do-do | 03:34 |
| rockstar | thumper, I think it's just a matter of getting jstestdriver in sourcedeps, creating a layer, and then migrating the windmill tests. | 03:34 |
| thumper | no disrespect meant to dogs | 03:34 |
| lifeless | thumper: I've no opinion | 03:37 |
| lifeless | I hear terrible things about all the browser test drivers | 03:37 |
| thumper | lifeless: no opinion given that windmill is causing most of our test failures? | 03:38 |
| lifeless | given the heavyweight nature of these things, I'd like us, should we do it, to do it full on | 03:38 |
| thumper | I can't imagine that you have no opinion, sorry | 03:38 |
| lifeless | thumper: causing or showing | 03:38 |
| lifeless | the windmill threads stuff is now sorted | 03:38 |
| lifeless | see - hudson went green | 03:38 |
| thumper | lifeless: but buildbot is broke | 03:39 |
| lifeless | devel or db-devel ? | 03:39 |
| thumper | devel | 03:40 |
| thumper | well, both actually | 03:40 |
| lifeless | WindmillTestClientException: {u'suite_name': u'Inline bug page subscribers test', u'result': False, u'starttime': u'2010-9-22T1:26:51.618Z', u'params': {u'id': u'subscribers-links', u'timeout': u'20000'}, u'output': None, u'endtime': u'2010-9-22T1:27:11.722Z', u'method': u'waits.forElement'} | 03:42 |
| lifeless | looks like a legitimate error to my naive eye | 03:42 |
| thumper | I ran the test locally from devel and it was fine | 03:43 |
| lifeless | busy machine ? | 03:43 |
| thumper | so, no... I don't think it is legitimate | 03:43 |
| thumper | even a busy machine shouldn't take 20 seconds to do that | 03:43 |
| lifeless | so, if we're getting spurious failures, we should fix them | 03:44 |
| lifeless | *that* I have an opinion on | 03:44 |
| lifeless | I simply don't know enough about the windmill design / implementation to have an opinion on *it* | 03:44 |
| rockstar | lifeless, thumper, I think having mindshare in javascript testing with the rest of the web properties at Canonical is of value as well. | 03:45 |
| thumper | rockstar: agreed | 03:45 |
| thumper | my question is how to transition | 03:46 |
| rockstar | lifeless, windmill will fail tests on random I/O issues. | 03:46 |
| thumper | should we just say to each team: do it, and do it now! ? | 03:46 |
| lifeless | rockstar: it can be nice to share war stories, but unless we make lp -massively- simpler to work with, I doubt that there will be much direct cross pollination | 03:46 |
| thumper | rockstar: how random? | 03:46 |
| rockstar | lifeless, the big issue is that the way to fix the spurious test failures is to fix it in windmill. | 03:46 |
| lifeless | is that particularly hard? | 03:46 |
| lifeless | Understand that I have -no- loyalty to windmill | 03:47 |
| thumper | it is if you don't know where the problem is | 03:47 |
| rockstar | lifeless, it is in that no one has any understanding of windmill. | 03:47 |
| lifeless | As I say, I simply don't know enough about its guts to comment | 03:47 |
| lifeless | rockstar: do -we- have that understanding of jstestdriver? | 03:47 |
| * thumper forces a build just to see if they are transient | 03:47 | |
| rockstar | lifeless, well, maybe not anyone on Launchpad, but Landscape, lazr-js, and U1 all use it. | 03:47 |
| rockstar | lifeless, I know enough to write tests in it, since lazr-js uses it, and I use lazr-js. | 03:48 |
| lifeless | rockstar: by which I mean the LP team; most of the teams at canonical are pretty flat chat - we shouldn't *expect* that they can fix issues we may encounter | 03:48 |
| lifeless | anyhow, as I say | 03:48 |
| lifeless | I don't have an opinion other than: if we're going to do it, do it as a dedicated focus. | 03:48 |
| lifeless | have two different test drivers around at once for firefox scares me | 03:49 |
| lifeless | rockstar: one thing that would make a compelling difference to me is parallel testing | 03:49 |
| rockstar | lifeless, actually, I think we just need to kill windmill. It'll remove test coverage, but like I said, if you can't rely on the tests, are they really tests? | 03:49 |
| lifeless | rockstar: mmm | 03:49 |
| lifeless | I can understand the feeling | 03:50 |
| lifeless | but false positives are not false negatives | 03:50 |
| lifeless | AIUI the issue we have is false positives, not false negatives. | 03:50 |
| lifeless | Which means our tests fail spuriously, but they don't pass when they shouldn't. | 03:50 |
| rockstar | lifeless, yes, but test failures drastically reduce our productivity and velocity. | 03:53 |
| lifeless | they do | 03:53 |
| lifeless | and we should fix that | 03:53 |
| lifeless | risk assessment | 03:53 |
| lifeless | lets say that the windmill tests cover 35% of our js code | 03:53 |
| lifeless | and that 10% of js landings hit valid windmill failures | 03:54 |
| lifeless | and that thats 5 landings a month | 03:54 |
| lifeless | that would say that 65% of js could be broken without safeguard, and that of the 355 coverage we have we catch a bug every two months | 03:55 |
| lifeless | and that a bug a month gets through to be caught later (e.g. by users) | 03:55 |
| rockstar | I can't think of a single thing that would be unusable without javascript. | 03:55 |
| lifeless | rockstar: when it breaks, people get unhappy | 03:56 |
| lifeless | it can break in many ways | 03:56 |
| lifeless | I don't know what those figures would be | 03:56 |
| lifeless | but I can't really agree *or* disagree about the relative merits of the test coverage we have vs the velocity cost that it has without some close observation - or figures /like/ those. | 03:57 |
| lifeless | I agree its a problem | 03:57 |
| lifeless | and that we should fix it | 03:57 |
| lifeless | and that that will help our velocity a lot - its why I've fixed the new threads issue with windmill | 03:57 |
| rockstar | lifeless, did you fix it, or just not consider it a test failure? | 03:58 |
| lifeless | rockstar: did you see my email about this? I detailed most fo it | 03:59 |
| lifeless | one thing I didn't mention in my email was that WindmillLayer *already* had an *explicit* code path to disable the thread checks: it wasn't working. | 03:59 |
| wallyworld | lifeless: rockstar: i have tried to land branches 5 or 6 times this week and have had "failures" due to windmill | 04:17 |
| wallyworld | i have just now "solved" a different windmill issue which has consumed waaaay to many hours of my time | 04:18 |
| wallyworld | the sooner it goes bye bye, the better IMHO | 04:18 |
| wallyworld | we don't have 10000s of windmill tests. surely we can introduce jstestdriver, write new tests using that, and migrate windmill ones as drive bys or whatever as time permits | 04:20 |
| beuno | I smell a joint sprint | 04:21 |
| beuno | lazr-js: the revenge of the tests | 04:21 |
| beuno | also, bed | 04:21 |
| * beuno waves | 04:21 | |
| lifeless | wallyworld: yes, threads were fixed lastnight | 04:22 |
| wallyworld | beuno: /me smells a big, steaming pile of excrement and it's called windmill :-( | 04:22 |
| wallyworld | \o/ | 04:22 |
| wallyworld | lifeless: it's not just the threads issue. there other nasty things at work too | 04:23 |
| lifeless | sure | 04:23 |
| wallyworld | if you add up my time, thumper's time, rockstar etc etc, and the future time we will surely waste and the scalability problems with the browser driven approach; the common tools/mindshare issue - surely a case can be made to swtich | 04:24 |
| lifeless | sure | 04:26 |
| lifeless | I'm not disputing that | 04:26 |
| rockstar | I don't think anyone is saying "Windmill is great." I think we're just proposing different solutions. | 04:27 |
| wallyworld | i don't have much hair left to pull out :-) | 04:30 |
| lifeless | james_w: https://code.edge.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057 | 04:37 |
| lifeless | james_w: can we land? no? | 04:37 |
| * StevenK wonders how to easily get failing tests out of a subunit stream | 04:52 | |
| lifeless | subunit-filter | subunit-ls | 04:53 |
| bac | lifeless: i talked to james_w about some approved-but-not-landed branches a couple of weeks ago. he indicated there was no hold up except his lack of time. | 05:04 |
| bac | thanks for following up. | 05:04 |
| lifeless | it may be worth just doing the changes and landing them | 05:09 |
| lifeless | StevenK: did that help? | 05:11 |
| StevenK | lifeless: Hm, did which? | 05:12 |
| lifeless | a16:53 * StevenK wonders how to easily get failing tests out of a subunit stream | 05:12 |
| lifeless | 16:54 < lifeless> subunit-filter | subunit-ls | 05:12 |
| StevenK | lifeless: Yes, it did, thanks. | 05:12 |
| lifeless | k | 05:12 |
| lifeless | jml: http://bzr.bz | 05:33 |
| * StevenK grumbles at failures in buildbot | 05:45 | |
| lifeless | StevenK: hows hudson | 05:46 |
| StevenK | From my scrollback: | 05:47 |
| StevenK | [02:56] < LPCIBot> Yippie, build fixed! | 05:47 |
| StevenK | [02:56] < LPCIBot> Project devel build (142): FIXED in 4 hr 1 min: | 05:47 |
| StevenK | https://hudson.wedontsleep.org/job/devel/142/ | 05:47 |
| StevenK | But since devel is failing, stable isn't getting anything and therefore db-devel isn't | 05:48 |
| lifeless | yeah | 05:48 |
| lifeless | stuckage | 05:48 |
| wallyworld | \o/ i finally got a branch through ec2 without spurious windmill failures! | 06:59 |
| lifeless | jml: cool | 07:03 |
| lifeless | bah | 07:03 |
| lifeless | wallyworld: cool | 07:03 |
| lifeless | wallyworld: so regarding 'add js, remove windmill lazily' | 07:04 |
| lifeless | wallyworld: I don't see this as a good strategy | 07:04 |
| lifeless | wallyworld: because the problem isn't with *new* windmill tests, its primarily with windmill itself / existing tests. | 07:04 |
| lifeless | wallyworld: I could see 'add jstestdriver, sprint (virtual or otherwise) on migrating' | 07:05 |
| wallyworld | lifeless: the problems this week for me were with a new test | 07:05 |
| lifeless | wallyworld: but adding a new thing which has its own failure modes and leaving the old one around indefinitely just means we're paying two sets of overhead | 07:05 |
| wallyworld | i don't think we should have *both* windmill and jstestdrive - i just want one framework that is fit for purpose | 07:06 |
| lifeless | right, me too | 07:06 |
| wallyworld | if that means we introduce jstestdriver and allow a bit of slack to migrate existing windmill tests, so be it :-) | 07:06 |
| lifeless | mmm | 07:07 |
| lifeless | that worries me | 07:07 |
| wallyworld | well, we can't let it become technical debt which is never repaid | 07:07 |
| lifeless | previous attempts at that ... are still incomplete. | 07:07 |
| lifeless | I certainly won't stop anyone doing this | 07:07 |
| wgrant | Leaving technical debt around is the Launchpad Way™ :( | 07:07 |
| lifeless | I just think its illadvised | 07:07 |
| wallyworld | yes, so we would need buy in from the teams that they see it as a very good thing so would be motivated to help get in and fix it | 07:08 |
| wallyworld | wgrant: oh no, not just the launchpad way. on my last job, there were 4 1/2 gui frameworks in use | 07:08 |
| wgrant | wallyworld: That is... impressive. | 07:08 |
| wallyworld | and i do mean 1/2, cause one of them was only ever 1/2 finished | 07:08 |
| wgrant | ... | 07:08 |
| wallyworld | what a noob i am - what does ... mean? you want more info? | 07:09 |
| lifeless | wallyworld: its a verbal pause | 07:10 |
| wgrant | Depressed silence, I guess. | 07:10 |
| wallyworld | lifeless: there's not *that* many windmill tests to migrate. it would only take each of us taking on one or two test classes each, maybe 4 hours work, and it would be done | 07:10 |
| lifeless | wallyworld: if the story were 'windmill is ok, want new shiny', I'd be like 'ok rad' | 07:10 |
| lifeless | wallyworld: great! organise it! | 07:10 |
| wallyworld | ok. i'll get some hard facts first. i'll talk to ohers about jstestdrive so i understand the scope a bit better | 07:11 |
| lifeless | wallyworld: my specific concerns are: | 07:12 |
| lifeless | - another half finished migration | 07:12 |
| lifeless | - not resolving the problems | 07:12 |
| wallyworld | +1 | 07:12 |
| lifeless | - and adding in a new set | 07:12 |
| lifeless | these are all variations on a theme | 07:12 |
| wallyworld | yes, and at this stage, to my mind at least, we are in the "we have a problem, lets consider options" stage | 07:13 |
| wallyworld | where option 1 is still keep windmill but fix it | 07:13 |
| wallyworld | but given the obstacles to that and the other drivers for something better, imho we need to take the next step of scoping option 2 | 07:14 |
| wallyworld | once the cost is understood, we can make an informed decision | 07:14 |
| wallyworld | and we also should include as part of it all migrating one or two tests to dip our toes in the water and fully understand hpw it would play out | 07:15 |
| lifeless | sure, but on a branch :) | 07:16 |
| wallyworld | huh? why would it be any other way? | 07:17 |
| lifeless | wallyworld: I've seen some mad shit in my time | 07:17 |
| lifeless | wallyworld: I didn't mean to insult | 07:17 |
| wallyworld | lifeless: no problem, i didn't take it as an insult. just swalllowing the bait :-) | 07:18 |
| thumper | hah | 07:55 |
| thumper | all those windmill failures were transient | 07:55 |
| thumper | due to our spurious test failure rules | 07:55 |
| thumper | we should disable windmill | 07:55 |
| StevenK | s/isable/elete/ | 07:56 |
| wgrant | I thought that was meant to be fixed :( | 07:56 |
| wgrant | Like three times now. | 07:56 |
| wgrant | In the last two days. | 07:56 |
| StevenK | wgrant: It was mostly impacting hudson | 07:56 |
| * thumper shrugs | 07:56 | |
| thumper | but I'm please buildbot is green | 07:56 |
| StevenK | Same, I can land stuff now | 07:56 |
| StevenK | Except PQM still thinks we are in testfix. Bleh | 07:57 |
| * StevenK kicks it | 07:59 | |
| StevenK | Or won't PQM come out of testfix until db-devel is fixed? | 08:04 |
| lifeless | it should have come out by now | 08:05 |
| * StevenK tries to land again | 08:06 | |
| StevenK | Still fails with testfix | 08:07 |
| adeuring | good morning | 08:37 |
| StevenK | lifeless: I guess I'm right, since pqm is still in testfix | 08:43 |
| jml | lifeless: StevenK: there's a short, indefinite period of time between submitting a testfix and coming out of testfix iirc | 09:02 |
| wgrant | I recall something about it polling every 15 minutes. | 09:05 |
| wgrant | But I could well be wrong. | 09:05 |
| jml | dev.launchpad.net/Trunk/Glue iirc | 09:07 |
| wgrant | "(Builbot's built-in "Force Build" button doesn't work for us for rather boring reasons). | 09:07 |
| wgrant | " | 09:07 |
| wgrant | That sounds very obsolete. | 09:07 |
| StevenK | jml: The devel build was sucessful about an hour ago. That isn't enough to drag us out of testfix? | 09:08 |
| jml | wgrant: it doesn't work for us | 09:08 |
| jml | StevenK: probably | 09:08 |
| jml | wgrant: we use a different, custom button | 09:08 |
| wgrant | jml: Ahh, I see. | 09:08 |
| StevenK | jml: So I should submit a branch as a testfix? | 09:09 |
| jml | StevenK: I don't know. | 09:09 |
| StevenK | Why does our PQM configuration have to be such a black hole? | 09:09 |
| mrevell | Morning | 09:13 |
| wgrant | StevenK: It's a rockstar conspiracy. | 09:13 |
| wgrant | StevenK: To make us use Tarmac and merge queues. | 09:13 |
| jml | mrevell: morning | 09:17 |
| lifeless | StevenK: its in a branch, just need it pushed to lp (private) | 09:19 |
| lifeless | StevenK: but this stuff is in BB anyway | 09:20 |
| StevenK | lifeless: It still doesn't explain if buildbot needs both devel and db-devel built sucessfully before we are out of testfix or if we need to be pushed out of testfix manually | 09:21 |
| lifeless | I was told that when bb starts a build it takes us out of testfix | 09:21 |
| lifeless | that may have been a misstatement | 09:21 |
| lifeless | so why aren't we building db-devel ? | 09:22 |
| StevenK | Hell, I don't even know if devel => stable has happened | 09:22 |
| lifeless | bzr pull | 09:22 |
| lifeless | or missing | 09:22 |
| jml | transparency! | 09:22 |
| lifeless | or whatever, can tell you that | 09:22 |
| jml | it's not even a river in Egypt | 09:23 |
| lifeless | http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html | 09:23 |
| jml | lifeless: that looks interesting. unfortunately, I have to go and have a driving lesson. | 09:24 |
| lifeless | jml: what are you learning to drive? | 09:24 |
| jml | lifeless: automobiles | 09:24 |
| StevenK | lifeless: stable is missing 11 revs -- 11765 to 11775 | 09:24 |
| StevenK | jml: Manual or automatic? | 09:25 |
| jml | manual. | 09:25 |
| jml | good bye. | 09:25 |
| lifeless | 11775 passed lpbuildbot | 09:25 |
| lifeless | so it should have pulled them | 09:25 |
| StevenK | jml: Enjoy! | 09:25 |
| lifeless | https://lpbuildbot.canonical.com/builders/lucid_lp/builds/275 | 09:25 |
| StevenK | lifeless: Does prase run the poller? If so, could the lucid upgrade killed it? | 09:26 |
| lifeless | I didn't think praé was lucid yet | 09:27 |
| StevenK | It was upgraded yesterday | 09:27 |
| lifeless | ok | 09:27 |
| * lifeless is suprised pqm kept working | 09:27 | |
| lifeless | StevenK: thanks for noticing this | 09:28 |
| StevenK | Well, it hasn't clicked off testfix mode, so maybe it isn't working? | 09:28 |
| * lifeless boggles at launchpad-users | 09:30 | |
| === almaisan-away is now known as al-maisan | ||
| lifeless | (lucid on prae did break lp buildbot polling) | 09:44 |
| lifeless | appears fixed now | 09:44 |
| bigjools | there's nothing like a stable dev environment | 09:55 |
| wgrant | Even Hudson is happy now. Things have to be going better :) | 09:55 |
| lifeless | grah | 10:13 |
| lifeless | my ec2 test runs are not sending failure mails | 10:13 |
| lifeless | or success mails | 10:13 |
| lifeless | grah grah | 10:16 |
| * lifeless sends it to pqm | 10:16 | |
| lifeless | nothing like breaking it 16 hours before I fly | 10:17 |
| wallyworld | lifeless: i'm having the same issue, but only for one particular branch | 10:26 |
| bigjools | lifeless: I need to book some time with you and discuss the scalability of PPAs. The increasing number of them is putting some strain on us. | 10:37 |
| lifeless | are you @ UDS ? | 10:37 |
| bigjools | yes | 10:37 |
| lifeless | lets do it there? | 10:37 |
| bigjools | sounds good | 10:37 |
| bigjools | thanks | 10:37 |
| lifeless | kk | 10:37 |
| bigjools | process-death-row is taking 1h17m :/ | 10:38 |
| wgrant | ! | 10:38 |
| wgrant | What's it doing? | 10:38 |
| bigjools | scanning a bazilion PPAs | 10:38 |
| wgrant | That sounds like a stupid bug, not a real scalability issue. | 10:39 |
| bigjools | possibly | 10:39 |
| bigjools | but we also need to address the publishing cycle | 10:39 |
| * bigjools brb | 10:39 | |
| wgrant | Yes, but that's also stupid bugs. | 10:39 |
| wgrant | I think we should make the code not suck before we decide we have a serious scalability issue. | 10:41 |
| wgrant | For starters it could not iterate over EVERY PPA EVER. | 10:47 |
| wgrant | And then issue a probably unoptimised query. | 10:48 |
| wgrant | And then commit around 20000 times. | 10:49 |
| wgrant | I bet you could remove the archive-driven approach and reduce it to two queries to identify all the publications that need work. | 10:52 |
| wgrant | And that would take a few seconds. | 10:52 |
| wgrant | Not 4500. | 10:53 |
| wgrant | Or we could fix the data model slightly and make dateremoved work sanely and then trivially query the archives that require consideration. | 10:55 |
| lifeless | +1 | 11:20 |
| lifeless | but devil will be in the details | 11:20 |
| === al-maisan is now known as almaisan-away | ||
| bigjools | always | 11:27 |
| bigjools | but the scalability issue remains nonetheless | 11:27 |
| bigjools | lifeless: can the feature flag work cope with changes to existing pages that I don't want to release, but I do want to land? | 11:28 |
| wgrant | They do. | 11:28 |
| bigjools | I guess I need to read about FFs then | 11:33 |
| bigjools | urg, this is going to be painful | 11:39 |
| wgrant | It's not just a matter of guarding a couple of sections of the page? | 11:39 |
| bigjools | StevenK: given that all your IDS stuff has landed, I am thinking that my changes to +addseries don't need to be behind a feature flag | 11:40 |
| bigjools | wgrant: see https://dev.launchpad.net/LEP/DerivativeDistributions and you tell me :) | 11:40 |
| bigjools | a lot of the existing stuff was cleaned up as well as new bits | 11:40 |
| bigjools | but like I said, I think it can just land. | 11:40 |
| bigjools | wgrant: actually I'd like your opinion on something | 11:42 |
| wgrant | Hmmm. | 11:42 |
| bigjools | Distroseries has a parent_series which we can use to work out if something is derived or not (if the parent_series's distro is different) | 11:43 |
| bigjools | however this doesn't help for us making Ubuntu derived from Debian | 11:43 |
| wgrant | The distroseries parent thing in that spec is screwed. | 11:43 |
| wgrant | Will not work at all. | 11:43 |
| wgrant | You need two parents. | 11:43 |
| bigjools | such a delicate way of putting it | 11:43 |
| wgrant | Heh, sorry. | 11:44 |
| bigjools | the mockup was reviewed many times by many people | 11:44 |
| wgrant | It certainly can't work for Debian->Ubuntu. And I don't see how it can work for OEM. | 11:44 |
| wgrant | Unless OEM wants to restart from scratch every time. | 11:44 |
| bigjools | explain? | 11:44 |
| wgrant | An Ubuntu series' parent is the previous Ubuntu series. | 11:45 |
| wgrant | But it needs derivation features from a Debian series. | 11:45 |
| wgrant | For the OEM case, s/Ubuntu/OEM/, s/Debian/Ubuntu/ | 11:45 |
| bigjools | yes | 11:46 |
| bigjools | this we are aware of | 11:46 |
| wgrant | Unless you want to fork, you need to inherit from within your own distro then use the new derivation UI from some other distro. | 11:46 |
| wgrant | The proposed model does not support that. | 11:46 |
| bigjools | which model? | 11:47 |
| wgrant | I guess the spec may not actually mean parent when it says parent. | 11:48 |
| bigjools | there are 2 types of parent, it's a little ambiguous | 11:48 |
| bigjools | but the "parent" in the mockup refers to the derived parent | 11:49 |
| wgrant | Ahh. | 11:49 |
| wgrant | And that's separate from the current model's parent? | 11:50 |
| bigjools | well, don't confuse what's in the model currently with what's on the mockup | 11:50 |
| bigjools | we're using the mockup to drive the model | 11:50 |
| bigjools | the model may have to change | 11:50 |
| bigjools | it may not | 11:50 |
| bigjools | I am pondering whether to add a "derived_from" column to distroseries | 11:51 |
| wgrant | bigjools: I'm not sure how best to term them. | 11:54 |
| wgrant | We do need a new column. That much is certain. | 11:55 |
| bigjools | I think you are right. | 11:55 |
| StevenK | You didn't say that to me last night when I said I think we do. | 11:55 |
| StevenK | :-P | 11:55 |
| bigjools | StevenK: I didn't say much at all did I? :) | 11:56 |
| * bigjools brb | 11:56 | |
| wgrant | derived_from seems fairly bad, but I can't think of anything better. | 12:00 |
| wgrant | It's ambiguous :( | 12:00 |
| deryck | Morning, all. | 12:01 |
| bigjools | wgrant: derived_from_series ? | 12:03 |
| bigjools | howdy deryck | 12:03 |
| wgrant | bigjools: But it's derived from both. | 12:03 |
| bigjools | wgrant: both what? | 12:04 |
| wgrant | bigjools: Natty is derived from both Maverick and Sid. | 12:04 |
| wgrant | So calling one 'parent' and one 'derived_from_series' isn't awfully unconfusing. | 12:04 |
| bigjools | wgrant: not really, it's derived from something way back, and its parent_series is maverick | 12:05 |
| wgrant | Well, it's still derived from Maverick, even if that's not what Soyuz calls it. | 12:06 |
| bigjools | wgrant: we are using derivation explicitly to mean "copied from a different distro" | 12:06 |
| bigjools | natty is not derived from maverick, it's just a continuation of the series | 12:07 |
| bigjools | consider them point releases if you like | 12:07 |
| wgrant | In the Soyuz sense of the term, sure. | 12:07 |
| wgrant | derived_from_series is fine, but something that doesn't use an ambiguous word would be better. | 12:08 |
| bigjools | what's ambiguous for you? | 12:08 |
| wgrant | bigjools: Now I have been informed of the limited Soyuz-specific definition of the word 'derivation', nothing. | 12:10 |
| wgrant | But anyone else reading the schema is likely to be terribly confused. | 12:10 |
| bigjools | wgrant: we have to make these definitions for that very reason | 12:10 |
| bigjools | the whole project is called "Derived Distributions" for gawd sake :) | 12:10 |
| wgrant | True. | 12:11 |
| bigjools | as long as the meanings are well documented and not terribly confusing I think it's ok | 12:11 |
| wgrant | I am thinking of some Registry dev coming along and wondering WTF is the difference between parent and derived_from_series. | 12:11 |
| wgrant | But then again this may be the two hours of sleep talking, so you could just ignore me. | 12:12 |
| bigjools | heh | 12:12 |
| bigjools | The interface docstrings should make it very clear, I hope. | 12:12 |
| wgrant | Point. | 12:12 |
| wgrant | So, with that clarified, I have retracted my long-held view that the spec is insane. | 12:13 |
| wgrant | yay. | 12:13 |
| bigjools | heh | 12:19 |
| wgrant | I was operating under the assumption that "parent" meant "parent". | 12:19 |
| bigjools | it does mean, however, that the spec is not clear enough | 12:19 |
| bigjools | I may clear up the ambiguity with s/parent/derived parent/ or something. | 12:20 |
| wgrant | I think that would be good. | 12:20 |
| bigjools | I am still a little worried about making this work for Ununtu though | 12:21 |
| wgrant | I may take a more detailed look at that spec tomorrow. | 12:21 |
| bigjools | Ubuntu, even | 12:21 |
| wgrant | And work out how it would work for Ubuntu. | 12:21 |
| bigjools | the Linaro workflow will be quite different | 12:21 |
| wgrant | Howso? | 12:21 |
| wgrant | I know the Ubuntu one, but not really the Linaro one. | 12:21 |
| wgrant | Does the Linaro one exist yet? | 12:21 |
| bigjools | I doubt they'll derive once, and keep releasing new series | 12:21 |
| wgrant | They'll re-derive each series, then copy some stuff up? | 12:22 |
| bigjools | we are also only making the differences stuff work through packagesets | 12:22 |
| bigjools | I suspect so, but someone like james_w will help clarify that | 12:22 |
| === matsubara-afk is now known as matsubara | ||
| jml | that reminds me | 12:56 |
| jml | I've been meaning to ask how visible packagesets are in the UI and how customizable they are | 12:56 |
| jml | let me rephrase | 12:56 |
| jml | if we wanted to start displaying aggregated bug information for Ubuntu & other distros, with packages grouped by an expert according to some heirarchy, what structures do we already have? | 12:57 |
| bigjools | jml: packagesets are only exposed via the API | 12:58 |
| wgrant | They're also exposed on +queue. | 12:59 |
| wgrant | But that's it.l | 12:59 |
| bigjools | "exposed" | 12:59 |
| wgrant | Heh. | 12:59 |
| === Ursinha is now known as Ursinha-afk | ||
| * bigjools -> fud | 12:59 | |
| bigjools | have we got any pages where pop-up help is working? | 13:48 |
| mars | gmb, ping, I have a MP for the feature flag work, 'Work in Progress' until I add something Martin P. wanted in it. With that, I'll put it up for review | 14:15 |
| bigjools | sinzui: I'm starting to redesign the distroseries:+addseries page to work with derived distros. I've got a few questions about how to arrange the form fields if you have a moment? | 14:20 |
| gmb | mars: Okay, thanks. | 14:39 |
| === adeuring1 is now known as adeuring | ||
| LPCIBot | Project devel build (143): SUCCESS in 3 hr 47 min: https://hudson.wedontsleep.org/job/devel/143/ | 14:57 |
| === almaisan-away is now known as al-maisan | ||
| === Ursinha-afk is now known as Ursinha | ||
| === salgado is now known as salgado-physio | ||
| sinzui | bigjools, yes I can talk. Sorry about the delay | 15:53 |
| bigjools | sinzui: hi | 15:54 |
| sinzui | bigjools, mumble? | 15:55 |
| bigjools | sinzui: here is fine so others can pitch in if they want | 15:55 |
| bigjools | sinzui: I'm trying to decide on how to model the parent distribution so it meets Ubuntu's needs and the Linaro needs | 15:56 |
| bigjools | sinzui: there's effectively 2 parents now | 15:58 |
| sinzui | bigjools, the form currently suggests every series of every distro. Do you want to restrict it to Ubuntu, or Ubuntu supported/development series | 15:59 |
| bigjools | sinzui: the one we derived from and the one we "branch" from | 15:59 |
| bigjools | that is part of what I'm fixing yeah | 15:59 |
| bigjools | so what I need to work out is what to present on the form and how to model it | 16:00 |
| bigjools | sinzui: https://dev.launchpad.net/LEP/DerivativeDistributions | 16:02 |
| bigjools | sinzui: we don't need to present the parent series on the form if the distro already has a series, we implicitly branch from the previous series | 16:02 |
| sinzui | bigjools, Right, that is true for Ubuntu, but in the case of a partner, they may choose a previous series or want to "rebase" from an Ubuntu series? | 16:06 |
| sinzui | bigjools, I image a lot of partners may only want to work with LTS series | 16:06 |
| bigjools | sinzui: that's fine, it would be the initial derivation | 16:06 |
| bigjools | any time a 2nd, 3rd, 4th series is added we don't support it being "derived" from anything other than the previous series | 16:07 |
| sinzui | So that means partners will be creating multiple distros, possibly for the same client? | 16:08 |
| * persia would very much expect that to happen | 16:08 | |
| * sinzui ponders each OEM customer sku having a distro with only one serie | 16:09 | |
| sinzui | s | 16:09 |
| bigjools | sinzui: that's entirely possible | 16:09 |
| bigjools | and I suspect the majority case | 16:09 |
| sinzui | bigjools, I suspect that OEM hopes that each customer will have one or two distros, and each sku is a series. Bugs can be seen to affect multiple series | 16:11 |
| bigjools | james_w: around? | 16:11 |
| james_w | yes | 16:12 |
| bigjools | sinzui: so my current thinking is to change that "parent series" drop down so that it only appears when truly deriving, and also make it only present Ubuntu series. | 16:12 |
| bigjools | james_w: hi - we're just chatting about how the new distro series form will look | 16:13 |
| bigjools | james_w: can you check the immediate scrollback and see what you think? | 16:13 |
| james_w | bigjools, what you are saying sounds about right to me | 16:15 |
| jml | mars: there's a conflict in your feature flags branch. if you want to fix it I'll be happy to review | 16:15 |
| james_w | though I feel I'm going to be overlooking some of the subtleties | 16:15 |
| sinzui | bigjools, 1. I agree. 2. there is a bug stating that parent series can be done in cases when the distro is not based on Ubuntu (fedora or fedora derivatives). If we do this change. We should mark the bug as wont fix...distros are Ubuntu or possibly Debian based only | 16:15 |
| bigjools | james_w: that's also my worry | 16:15 |
| sinzui | bigjools, This later assertion is true now. We only support Debian/Ubuntu sourcepackagenames | 16:16 |
| bigjools | james_w: sinzui: what this means is that we can't support ubuntu deriving from debian for now | 16:16 |
| bigjools | for a start debian doesn't have packagesets | 16:16 |
| bigjools | and the difference calculations are based around those | 16:17 |
| sinzui | We also do not have a complete set of Debian sourcepackagenames | 16:17 |
| bigjools | right | 16:17 |
| mars | jml, sure. I was just running rf-get to fix it | 16:18 |
| james_w | that should be something that is fixed somehow IMO | 16:18 |
| jml | mars, cool | 16:18 |
| sinzui | So with this change we can be honest and say Launchpad support Ubuntu | 16:18 |
| james_w | only allow deriving from Ubuntu> what about deriving from derivatives? | 16:18 |
| bigjools | good point | 16:18 |
| james_w | If Ubuntu can't derive from Debian then I would be worried about whether the feature is usable | 16:19 |
| bigjools | it will be usable for the more simple cases | 16:19 |
| sinzui | james_w, in the case of Debian sourcepackagenames, we wait for the next sync from Debian to get the new names | 16:20 |
| james_w | I don't think not having all the sourcepackagenames is a big issue is it? | 16:20 |
| james_w | at the next sync new packages will be imported in to Debian, and then show up as eligible for syncing | 16:21 |
| james_w | bigjools, what in particular makes Debian/Ubuntu complicated? Just packagesets and sourcepackagenames? | 16:21 |
| bigjools | sinzui, james_w: I think what we need for ubuntu is to make the +addseries form take another parameter that lets you specify which of the parent distro's series you are syncing from | 16:21 |
| sinzui | +1 | 16:22 |
| bigjools | james_w: it's because of the fact that ubuntu actually derived from debian a long time ago | 16:22 |
| james_w | before you said that wouldn't be needed for Debian/Ubuntu, you would just add a relationship to warty, and it would work. Has that changed? | 16:22 |
| bigjools | james_w: it's not need to specify the parent series in the same distro, because we only support the immediately preceding one | 16:23 |
| mars | jml, fix pushed | 16:23 |
| jml | mars: ta | 16:23 |
| bigjools | but it would be useful to specify to series in the distro we derived from | 16:23 |
| bigjools | s/to/the/ | 16:23 |
| james_w | right, and you said you weren't doing that before? | 16:23 |
| bigjools | right | 16:24 |
| james_w | parent series: where packages are copied from at i-f-p time? | 16:24 |
| james_w | derived series: where packages can be synced from later? | 16:24 |
| bigjools | yep - that's always series-1 | 16:24 |
| james_w | is parent series used for anything else than copying packages at the start? | 16:25 |
| james_w | ordering? | 16:25 |
| jml | mars: are we good to start using Python 2.6 features yet? | 16:25 |
| bigjools | yep - it's most useful for difference comparing | 16:25 |
| jml | mars: last I heard we still had one more thing to fix | 16:25 |
| bigjools | err | 16:25 |
| bigjools | let me re-state | 16:25 |
| bigjools | parent series does not need to be specified, ever, we only support the previous one | 16:25 |
| bigjools | derived series is what you want to compare and sync against | 16:26 |
| james_w | ok | 16:26 |
| mars | jml, we were just discussing that. Do you remember what the 'one more' thing was? praesodium was the big one, and it looks like it is upgraded! | 16:26 |
| james_w | so, two things come to mind: what changes at the edge case when you create a first series | 16:26 |
| sinzui | bigjools, thanks! that explanation of how initialization works is helpful | 16:26 |
| jml | mars: no, I don't. I'd have to search my mail, same as you :) But I think it was just praes. | 16:27 |
| james_w | and what is the difference between the parent and the derived series for most of the life of the series? | 16:27 |
| mars | jml, pity, should have talked to lifeless and mthaddon yesterday. They're probably getting ready to fly now. Maybe we could hammer it down on Monday. | 16:28 |
| james_w | edge case> there is no parent series that can be inferred. At that point do you want to be able to specify a parent series from another distro? | 16:28 |
| bigjools | james_w: parent is NULL for the first series | 16:29 |
| jml | mars: that would be good. | 16:29 |
| sinzui | james_w, right which is what happens with a new distro. Series are not require BTW. our nasty fedora and gentoo records do not have series | 16:29 |
| jml | mars: I only ask because of the namedtuple use in your branch. | 16:29 |
| mars | yeah, that was optimistic (same as my earlier Py2.6 listmail) | 16:29 |
| bigjools | james_w: its presence on the database isn't really useful | 16:29 |
| mars | jml, I can strip it out if we really want to get this landed | 16:30 |
| jml | mars: fair enough. | 16:30 |
| james_w | bigjools, ok, so if I create jamesbuntu, which is to be an Ubuntu derivative, my first series won't have a parent, and so be empty to start? | 16:30 |
| * sinzui uses "nasty" to mean it looks operational in Lp, but it is not and users are very confused | 16:30 | |
| bigjools | james_w: yes, but the new form will allow you to specify where you want it initialized from | 16:31 |
| james_w | I'm wondering if parent/derived is a useful distinction, and whether it is really a list of parents. | 16:31 |
| bigjools | so derived_series will be natty, or whatever | 16:31 |
| bigjools | james_w: it's entirely useless AFAIAC | 16:31 |
| bigjools | sinzui: is parent_series used in registry for anything useful? | 16:32 |
| sinzui | bigjools, no | 16:32 |
| james_w | so, jamesbuntu maverick parents: [maverick], jamesbuntu natty parents: [jamesbuntu-maverick, natty]? | 16:32 |
| sinzui | bigjools, I think it was a field to remind someone what to use when running the initialization scripts | 16:33 |
| bigjools | heh | 16:33 |
| bigjools | james_w: I don't understand what you're trying to express there | 16:33 |
| james_w | bigjools, just trying to work out if parents can be a list without loss of generality | 16:34 |
| bigjools | james_w: there's only one useful parent, that's the series you're syncing from/comparing with | 16:35 |
| james_w | because it seems to me that it would make some of the questions we are asking entirely redundant | 16:35 |
| bigjools | I think so | 16:35 |
| james_w | bigjools, why can't that be more than one series? Comparing nattty with maverick could also be useful. | 16:35 |
| james_w | seeing what are SRU candidates, noting which SRUs need to be merged in to natty... | 16:36 |
| bigjools | james_w: I see it could be useful, I'm not sure if what we've done so far will work like that :/ | 16:37 |
| jml | mars: From 'test_fixture_deletes_existing_values', I gather that using a second FeatureFixture in a test reverts whatever changes were made by first one. | 16:37 |
| jml | mars: Is this correct? | 16:37 |
| mars | jml, yes. Fixtures have a subtle trait of nuking the database before setting anything new | 16:38 |
| mars | jml, err, feature flags have that trait | 16:38 |
| james_w | ISTM that a parent/derived distinction is entirely useless, raises lots of odd questions, and also limits what you can do, so I want to confirm that and advocate for removing it if possible | 16:38 |
| jml | mars: so this is a property of feature flags, rather than the new helper? | 16:39 |
| mars | yes | 16:39 |
| james_w | bigjools, any particular reason, or just that the assumption is baked in from very early on in Launchpad's development? | 16:39 |
| jml | mars: hmm. ok. I guess it's out-of-scope for your branch. I find that kind of surprising, and am not sure it's a desirable behaviour. | 16:39 |
| bigjools | james_w: baked in from the previous discussions around https://dev.launchpad.net/LEP/DerivativeDistributions | 16:40 |
| mars | jml, lib/lp/services/features/rulesource.py:104: store.execute('DELETE FROM FeatureFlag') | 16:40 |
| mars | jml, in setAllRules() | 16:40 |
| jml | mars: thanks. | 16:40 |
| james_w | bigjools, damn | 16:40 |
| james_w | I should have fought for this louder and sooner | 16:41 |
| === beuno is now known as beuno-lunch | ||
| bigjools | james_w: the UI stuff is all based around the diffs from the thing you derived from | 16:41 |
| bigjools | and that is all mostly done | 16:41 |
| james_w | bigjools, well, I presume the code could in theory diff any two series? | 16:42 |
| bigjools | james_w: in theory yes | 16:42 |
| * jml butts in | 16:42 | |
| james_w | (diffing arbitrary series would have its uses too) | 16:42 |
| sinzui | bigjools, how does this affect a project like batlix. It is a derived distro (a remix) It cannot current use Lp to build itself. Baltix's first series is a derivative of Debian, later series are derivatives of Ubuntu | 16:42 |
| jml | also, the code isn't probably not going to get any easier to change | 16:42 |
| * bigjools sees jml's butt | 16:42 | |
| bigjools | sinzui: it would not be any different from the other distros I think | 16:43 |
| james_w | jml, any particular insights, or are you just waving your butt around? :-) | 16:44 |
| jml | just general ones, like "I'd rather we do something good even if that involves re-doing work" | 16:45 |
| bigjools | define good | 16:45 |
| jml | let me catch up with the actual content of the discussion though :) | 16:45 |
| sinzui | bigjools, batlix is an IDerivativeDistro. Will the rules change when create a distro or a series to distinguish between Ubuntu, a partner, a community that remixes Ubuntu, a community that wants a distro that is not based on Ubuntu | 16:45 |
| bigjools | sinzui: I've no idea what IDerivativeDistro is! | 16:46 |
| sinzui | Read the __init__ in the distro model | 16:46 |
| bigjools | sinzui: initially, we're only letting certain people use this stuff since it has massive performance implications | 16:46 |
| sinzui | It basically means it is crippled. No soyuz, not mirrors, no packages | 16:46 |
| bigjools | ok | 16:47 |
| sinzui | bigjools, IDD was created during 3.0 to ensure the distro pages works for ubuntu, but did not break when used with batlix and gentoo | 16:48 |
| bigjools | right | 16:48 |
| bigjools | sinzui: how is the decision made if it's IDerivativeDistro or not? | 16:48 |
| sinzui | bigjools, self == lpceleb.ubuntu | 16:49 |
| bigjools | sinzui: /o\ | 16:49 |
| sinzui | bigjools, I think there is an XXX saying this will have to change one day | 16:49 |
| bigjools | ok | 16:49 |
| sinzui | bigjools, there is exactly 1 place that need to change | 16:49 |
| bigjools | that's good, I guess :) | 16:50 |
| sinzui | however, I think we need to ask if we are going from two tiers of service to three tiers | 16:50 |
| bigjools | I certainly have three tears right now | 16:50 |
| === matsubara is now known as matsubara-lunch | ||
| sinzui | does baltix get packages now? can satanic-ubuntu use Lp to make it's remixes? | 16:50 |
| jml | two elephants and a cymbal fall off a cliff | 16:51 |
| jml | ok. caught up now I think. | 16:51 |
| jml | wow, this sounds an awful lot like bzr branches | 16:51 |
| jml | why don't we do it that way? | 16:51 |
| jml | (list of parents, left-hand parent is special) | 16:52 |
| sinzui | bigjools, I described how users are remixing ubuntu in a blog post last month I think. They need to use project groups, projects, and teams. I propose that we rename the baltix class of project to IRemixDistribution so that there is no confusion in the code | 16:53 |
| james_w | +1 | 16:54 |
| bigjools | seems fair | 16:54 |
| jml | I also think we should keep aiming to supporting the concept of Ubuntu as a Debian derivative, and Launchpad as fully functional for Debian derivatives | 16:58 |
| persia | So, semantically, I'd like to preserve the idea that "Derivative" implies rebuilds of stuff and "Remix" implies just adding random stuff. | 16:58 |
| jml | but I'm still not clear on exactly what the cost of that is relevant to the derivative distro LEP work | 16:58 |
| jml | (I know there's other registry bugs, but one thing at a time) | 16:58 |
| sinzui | jml, So batlic gets archives, builds, and mirrors? | 16:59 |
| jml | sinzui: baltix? why not? | 16:59 |
| bigjools | persia: does a new Ubuntu series fit outside of those two for you? | 16:59 |
| jml | sinzui: maybe not mirrors though. Are we doing mirrors for linaro? | 16:59 |
| persia | bigjools, Yes, very much so. | 16:59 |
| bigjools | persia: great, that's how I see it too | 17:00 |
| persia | The words that are important to be are "Release", "Flavour", "Remix", Derivative". | 17:00 |
| sinzui | jml, I think the real blockers are archives, builds, and translations. The mirror script is not broken by the mirrors that were wrongly registered | 17:00 |
| persia | s/be/me/ | 17:00 |
| * sinzui saw no reason to remove mirrors since nothing was visibly broken | 17:01 | |
| persia | "Release" is each Ubuntu series, "Flavour" is something with packagesets, "Remix" is a "Release"+ a PPA or equivalent (or maybe not). "Derivative" rebuilds masses of stuff, changes lots of things, etc. | 17:01 |
| bigjools | I like that | 17:02 |
| bigjools | sinzui: this is something we can use in the UI | 17:02 |
| sinzui | jml: I am cautiously +1 on permitting any community to have a derivative. Packages and bug fixes are usable by the Ubuntu community | 17:04 |
| jml | sinzui: well, I think there are two distinct questions: should Launchpad be capable of such? should we allow such as a matter of policy? | 17:04 |
| sinzui | persia, I agree with your definitions | 17:04 |
| bigjools | sinzui: we need to be careful, we can't let just anyone start creating derivatives that generate huge numbers of database rows | 17:05 |
| jml | sinzui: I don't really have a strong opinion about the second question, but I will answer a firm "yes" to the first. | 17:05 |
| persia | bigjools, Note that "remix" sometimes means specific things in terms of the Ubuntu trademark license, for remixes of Ubuntu: you might want to seek wider clarification before using it in the UI. | 17:05 |
| jml | and indeed you'll want to do user testing to get input from non-persias. | 17:05 |
| sinzui | bigjools, yes, that is what I am cautious about. | 17:05 |
| bigjools | we can let them register the distro itself as a particular type of course. | 17:06 |
| bigjools | perhaps we need a new type of series where we can flag it as being managed by LP/Soyuz | 17:06 |
| jml | bigjools: perhaps it's just a matter of whether it has an associated archive or not | 17:07 |
| bigjools | jml: maybe, I'd need to think through the consequences | 17:07 |
| bigjools | because the new derived stuff will need to create an archive somehow for certain derived distros | 17:08 |
| bigjools | (given permissions) | 17:08 |
| jml | bigjools: sure, I'm not strongly advocating that particular solution, just that we also should think carefully about adding new types. | 17:09 |
| bigjools | agreed | 17:09 |
| bigjools | but sometimes it's good to be explicit | 17:09 |
| jml | or in this case, new types of types | 17:09 |
| jml | james_w: I'm sorry, I've lost the thread of conversation where you were talking about fighting for a particular change earlier. | 17:10 |
| james_w | jml, you mean you aren't sure which change I was talking about in particular? | 17:11 |
| jml | james_w: yes, and I'm also not sure where the conversation about that change went after that :) | 17:11 |
| james_w | jml, we paused for your butt :-) | 17:11 |
| jml | james_w: a wise move. | 17:12 |
| james_w | jml, I was referring to having a list of parents, though looking back I was never as explicit about it as I believed | 17:12 |
| bigjools | sinzui: I want to remove "title" as a DB column | 17:12 |
| bigjools | it should be generated I think | 17:12 |
| jml | james_w: ok yeah, that sounds like a great idea | 17:12 |
| jml | bigjools: why can't we have a list of parents? | 17:13 |
| sinzui | bigjools, +1 | 17:13 |
| mars | jml, thanks for the review feedback | 17:13 |
| jml | mars: my pleasuer. | 17:13 |
| jml | mars: except, correctly spelled. | 17:13 |
| bigjools | jml: it never came up in the initial discussions and noodles has now finished the main differences UI page | 17:13 |
| sinzui | bigjools, I was contemplating the removal of .title from views and templates in December. We may need to do that sooner :) | 17:13 |
| bigjools | which deals with differences with one parent | 17:14 |
| jml | and now we're going to have to dig a £13bn pound tunnel underneath London to change it? | 17:14 |
| bigjools | sinzui: I removed it from my mockup a while ago :) | 17:14 |
| james_w | well, there's two slightly different things, having >1 derived parent, and making the parent series less of a special case | 17:14 |
| james_w | the former definitely came up | 17:14 |
| sinzui | bigjools, I would like an lts field. it can be a bool, but to support other distros, it should be a text field. We want to show users "Ubuntu 10.04 LTS" | 17:15 |
| bigjools | the parent series is not used anywhere | 17:15 |
| james_w | as for the UI, I presume it would be feasible to do comparison against one parent at a time? | 17:15 |
| james_w | n-way diff of archives is hard enough to think about, let alone do a UI for | 17:15 |
| bigjools | exactly :) | 17:16 |
| jml | james_w: right. | 17:16 |
| bigjools | we could do *something* as a comparison against more parents | 17:16 |
| mars | Anyone else noticed that testr has started dumping "configs/testrunner_12345/" directories into the configs dir? | 17:16 |
| jml | I thought we had to have something like a three-way comparison to handle the MoM case? | 17:16 |
| bigjools | jml: I don't think it would require a Jubilee Line extension | 17:16 |
| mars | It makes --strict bzr commits really annoying | 17:16 |
| james_w | plus, Mark specifically said he was interested in multiple derived parents, so delivering that would be plus. | 17:17 |
| bigjools | we do a 3-way right now in the UI | 17:17 |
| jml | bigjools: ok, so maybe we could find the funding somehow. :) | 17:17 |
| jml | (incidentally, crossrail is making my life slightly more inconvenient) | 17:17 |
| bigjools | jml: right :) | 17:17 |
| james_w | jml, yeah, we need 3 way, but going beyond THIS, OTHER and BASE is mighty complicated | 17:17 |
| jml | sure. | 17:18 |
| jml | james_w: I guess there too we can look to bzr for precedent | 17:18 |
| bigjools | I think that we could add something in to do arbitrary parents | 17:18 |
| bigjools | it just needs loads more data in the DB to be generated | 17:18 |
| james_w | though 2-way diff with multiple series wouldn't be too hard | 17:18 |
| jml | james_w: insofar as it allows N parents, and blesses the left-most, and basically only has UI for 2 parents | 17:18 |
| james_w | as in listing the versions that each has | 17:18 |
| jml | bigjools: perhaps there are ways around that. | 17:19 |
| james_w | jml, right, allowing for diffs against any of the parents on demand, but not trying to show all of the diffs in "log -p" etc. | 17:19 |
| bigjools | jml: not with the current schema | 17:20 |
| bigjools | we're about to start work on the backend that works out what the differences are between series | 17:20 |
| jml | bigjools: schemas can be changed | 17:21 |
| bigjools | jml: anything can be changed, how much time have you got? | 17:21 |
| jml | bigjools: for this project, quite a bit. | 17:22 |
| bigjools | jml: well I have at least one interested party breathing down my neck :) | 17:23 |
| jml | bigjools: I'm not worried about that so much. | 17:24 |
| * james_w -> lunch | 17:26 | |
| jml | bigjools: we have an SLA, and if we can deliver useful things incrementally so much the better. But I don't think we need to aim lower if the only motivation is a deadline. | 17:26 |
| bigjools | jml: I don't think that's ever been the case. | 17:27 |
| jml | bigjools: cool :) | 17:27 |
| cody-somerville | +1 :) | 17:30 |
| * jml retreats into shell to do end-of-week stuff | 17:32 | |
| === salgado-physio is now known as salgado | ||
| === benji is now known as benji-lunch | ||
| === matsubara-lunch is now known as matsubara | ||
| === beuno-lunch is now known as beuno | ||
| bigjools | good night people, see you at UDS | 18:05 |
| LPCIBot | Project devel build (144): SUCCESS in 3 hr 28 min: https://hudson.wedontsleep.org/job/devel/144/ | 18:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=664327] API: | 18:26 |
| LPCIBot | IHasTranslationImports.getTranslationImportQueueEntries. | 18:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=maris, henninge][ui=salgado, | 18:26 |
| LPCIBot | sinzui][bug=663436] Move most of the OAuth doctests into unit tests. | 18:26 |
| LPCIBot | Make it possible to request a temporary integration of one's | 18:26 |
| LPCIBot | desktop into the Launchpad web service. | 18:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=664380] Add the PPA name to the Subject of | 18:26 |
| LPCIBot | the reject message sent. | 18:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=608621] Fix the InitialiseDistroSeriesJob | 18:26 |
| LPCIBot | cronscript to actually work. | 18:26 |
| lifeless | moin | 18:29 |
| jml | g'night all | 18:39 |
| === benji-lunch is now known as benji | ||
| LPCIBot | Project db-devel build (91): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/db-devel/91/ | 18:54 |
| deryck | mars, ping (when you're back). | 19:00 |
| dobey | what's the normal procedure for getting a ~vcs-imports branch updated to point to the right place? file a 'question' on lp? | 19:11 |
| persia | Yes | 19:12 |
| dobey | ok, thanks | 19:12 |
| mars | Hi deryck, what's up? | 19:12 |
| bryceh | hmm, I've just merged db-devel trunk into my branch and now make schema fails... | 20:19 |
| bryceh | http://pastebin.ubuntu.com/518226/ | 20:19 |
| gary_poster | bryceh: cd download-cache; bzr up; cd .. | 20:21 |
| * gary_poster needs to find time to get rid of the download-cache | 20:22 | |
| bryceh | gary_poster, thanks | 20:22 |
| gary_poster | np | 20:22 |
| === al-maisan is now known as almaisan-away | ||
| deryck | rockstar, ping | 20:52 |
| rockstar | deryck, pong | 20:53 |
| deryck | rockstar, yo dude. Did you get those Windmill tests working? I never saw bugs. | 20:53 |
| rockstar | deryck, I still have yet to get that branch landed. | 20:54 |
| rockstar | deryck, for context, windmill is preventing MANY code branches from landing right now. | 20:54 |
| deryck | rockstar, so what can we do to move it forward? I guess we can talk about it at UDS. gmb isn't working on it next week anyway. | 20:55 |
| rockstar | deryck, I'll keep trying. I think we should talk seriously about it at UDS. | 20:56 |
| rockstar | Mostly, I think we should just toss windmill. | 20:57 |
| deryck | well, we could disable tests for now. tossing windmill seems ambitious to get a branch landed. ;) | 20:57 |
| rockstar | deryck, yeah, I disabled those tests, but every time I ec2 test it, it disappears in the black hole of ec2. | 20:59 |
| deryck | rockstar, ah, ok. | 20:59 |
| lifeless | something new is wrong with ec2test | 21:07 |
| lifeless | I saw that too, but my change landed and passed both buildbot and hudson ok | 21:07 |
| === Ursinha is now known as Ursinha-afk | ||
| lamont | 2010-10-22 14:32:50+0000 [-] File "/srv/launchpad.net/codelines/soyuz-production-rev-9886/lib/lp/buildmaster/model/builder.py", line 333, in updateBuilderStatus | 21:12 |
| lamont | 2010-10-22 14:32:50+0000 [-] MAX_EINTR_RETRIES, _update_builder_status, builder, logger=logger) | 21:12 |
| lamont | 2010-10-22 14:32:50+0000 [-] File "/srv/launchpad.net/codelines/soyuz-production-rev-9886/lib/lp/services/osutils.py", line 78, in until_no_eintr | 21:12 |
| lamont | 2010-10-22 14:32:50+0000 [-] return function(*args, **kwargs) | 21:12 |
| lamont | wgrant: ^^ I SAID MAX_EINTR_RETRIES was a bad idea.... | 21:13 |
| rockstar | abentley, wow. It's time to stand up, huh? Mumble? | 21:33 |
| abentley | rockstar: sure. | 21:33 |
| === salgado is now known as salgado-afk | ||
| lifeless | mars: hi | 21:39 |
| lifeless | mars: I'd still like a config setting to completely turn off profiling | 21:40 |
| mars | lifeless, could you please add that comment to the MP, "Needs Fixing"? | 21:40 |
| === matsubara is now known as matsubara-afk | ||
| LPCIBot | Project devel build (145): SUCCESS in 3 hr 27 min: https://hudson.wedontsleep.org/job/devel/145/ | 21:53 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][no-qa] Fix glob imports in python tests. | 21:53 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=244527] Moves JoinNotAllowed to | 21:53 |
| LPCIBot | registry.errors. This registers it on the webservice so that it | 21:53 |
| LPCIBot | reports HTTP 400 BAD REQUEST across the API instead of a server error. | 21:53 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=deryck][ui=none][no-qa] Unit tests for BugTaskSet.search() and | 21:53 |
| LPCIBot | BugTaskSet.searchBugIds() | 21:53 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=allenap, | 21:53 |
| LPCIBot | danilo][ui=none][bug=608631] Users now can use the [nnbsp] tag to | 21:53 |
| LPCIBot | input a narrow no-break space in Rosetta. This tag | 21:53 |
| LPCIBot | representation is also a workaround for some Browsers (eg. in | 21:53 |
| LPCIBot | Rekonq NNBSP is displayed as a zero-width character). | 21:53 |
| LPCIBot | Project parallel-test build (11): STILL FAILING in 2 hr 26 min: https://hudson.wedontsleep.org/job/parallel-test/11/ | 22:06 |
| LPCIBot | Project db-devel build (92): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/db-devel/92/ | 22:25 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Fix failing tests. | 22:25 |
| LPCIBot | * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11776 | 22:25 |
| LPCIBot | included. | 22:25 |
| wgrant | lamont: What happened? | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!