| StevenK | Right | 00:00 |
|---|---|---|
| poolie | done | 00:00 |
| StevenK | We have to wait for abentley's rollback to hit qas too | 00:00 |
| wgrant | Nope. | 00:01 |
| wgrant | We've turned the feature off on production. | 00:01 |
| StevenK | So we can deploy to 14399, or would you prefer to wait? | 00:01 |
| wgrant | I'd prefer to deploy ASAP. | 00:02 |
| wgrant | The two rollbacks are qa-ok if they only affect the disabled feature. | 00:02 |
| StevenK | There's two rollbacks? :-( | 00:02 |
| wgrant | Yes. | 00:03 |
| poolie | is it just me or is there something strange on lp where the font size varies on some pages? | 00:28 |
| poolie | maybe it's just my browser | 00:30 |
| === Ursinha_ is now known as Ursinha | ||
| poolie | hm | 01:01 |
| poolie | i'm going to add a timeout to bzrlib tests | 01:01 |
| poolie | it's pretty generous, 300s | 01:01 |
| poolie | i wonder if this will hurt lp | 01:01 |
| poolie | 300s per test | 01:01 |
| poolie | *600s | 01:01 |
| lifeless | how are you going to do this? | 01:02 |
| poolie | https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559 | 01:07 |
| poolie | it crashes the whole test run | 01:07 |
| poolie | :/ | 01:07 |
| poolie | probably better than hanging | 01:08 |
| poolie | what do you think/ | 01:11 |
| poolie | lp could turn it off | 01:11 |
| poolie | or we could have it off by default | 01:11 |
| lifeless | interesting | 01:11 |
| lifeless | I have a few different angles here | 01:11 |
| lifeless | firstly lp - you can check the longest test run by introspecting a subunit stream from a failed ec2 run | 01:12 |
| lifeless | longest duration of a single test, I mean | 01:12 |
| poolie | true | 01:12 |
| lifeless | add 50% or so and we're safe. | 01:12 |
| lifeless | secondly, I think this would be good to put into testtools and/or fixtures | 01:12 |
| lifeless | it has no need to be bzrlib specific | 01:12 |
| lifeless | and its really quite nice | 01:12 |
| poolie | also true, i thought about that too | 01:13 |
| poolie | it is a bit abrupt | 01:13 |
| lifeless | e.g. fixtures would happily accept a timeout fixture which alarms if not turn down in time | 01:13 |
| poolie | but i don't see any better options | 01:13 |
| poolie | yep | 01:14 |
| lifeless | you can use signal.signal to inject an exception when SIGALARM is received, I suspect | 01:14 |
| poolie | we don't currently depend on fixtures | 01:14 |
| poolie | we could | 01:14 |
| poolie | probably yes | 01:15 |
| poolie | that could make it tidier | 01:15 |
| poolie | at the expense of perhaps not terminating in some cases | 01:15 |
| lifeless | so the contract could be TimeoutFixture(duration, callback) | 01:15 |
| poolie | eg if you are stuck in C code | 01:15 |
| lifeless | perhaps yes | 01:15 |
| poolie | as we actually were in the case that motivated me to write this | 01:15 |
| poolie | mm | 01:15 |
| poolie | it might still get it unjammed | 01:15 |
| poolie | it could be an option | 01:15 |
| poolie | if you review https://code.launchpad.net/~mbp/testscenarios/module-scenarios/+merge/80287 i will be more likely to send you more patches :) | 01:16 |
| lifeless | anyhow those are my thoughts - share the niceness more widely, and check the longest run LP | 01:16 |
| lifeless | has | 01:16 |
| lifeless | poolie: its right up on my list actually, I nearly got to it yesterday. | 01:16 |
| poolie | "you're boring me... BANG" | 01:21 |
| poolie | lifeless, ok https://code.launchpad.net/~mbp/python-fixtures/timeout/+merge/83721 | 01:59 |
| * lifeless cues the on hold music | 02:00 | |
| poolie | for the diff? | 02:00 |
| poolie | what's up with the longpoll stuff for that? | 02:00 |
| lifeless | no, for you :P | 02:00 |
| poolie | i see a lot of noise about it | 02:00 |
| poolie | oh ok | 02:00 |
| lifeless | we're about to go live | 02:00 |
| lifeless | anyhow, immediate feedback is that this is much more than test specific; (haven't seen the diff yet) | 02:01 |
| poolie | oh? | 02:01 |
| lifeless | well its a good generic 'I'm doing something and I might not come back' facility, wrapped up in a context manager | 02:02 |
| lifeless | so I'd like to drop the focus on tests in the prose around it | 02:02 |
| poolie | mm | 02:02 |
| poolie | i see your point | 02:02 |
| poolie | i think it is really for emergency use | 02:03 |
| lifeless | your readme says TimeoutFixture | 02:03 |
| poolie | i wouldn't encourage using it widely | 02:03 |
| lifeless | your body tests TestTimeout | 02:03 |
| poolie | until for instance it copes properly with several things happening at once | 02:03 |
| poolie | you'reright | 02:03 |
| lifeless | I prefer the former (and jml is arguing for just Timeout, for this case) | 02:03 |
| lifeless | poolie: I think its fine to have something with caveats | 02:03 |
| lifeless | poolie: the caveats are real, and devs can make informed choices. | 02:04 |
| poolie | you're right that aside from that it is not test specific | 02:04 |
| lifeless | 211+ import pdb;pdb.set_trace() | 02:04 |
| poolie | just 'Timeout' is ok with me | 02:05 |
| poolie | heh | 02:05 |
| lifeless | is possibly not intended to be merged | 02:05 |
| lifeless | its amazing how loudly cats can snore | 02:09 |
| poolie | i don't really want to fix that in this branch :) | 02:09 |
| poolie | or indeed at all | 02:09 |
| lifeless | cat snoring? Indeed :) | 02:09 |
| poolie | so given all this, perhaps the sample data does not need to be tests but just functions | 02:10 |
| lifeless | make sense to me | 02:10 |
| poolie | that's quite nice they'renot test specific | 02:12 |
| poolie | actually that's more testable not going through the double-testing layer too | 02:19 |
| poolie | ok re-pushed | 02:24 |
| lifeless | poolie: I wonder whether a callback is more useful than an exception | 02:33 |
| lifeless | poolie: e.g. a trivial callback can raise, a different one could log a marker about how far through (whatever task) things were when the alarm triggered | 02:34 |
| lifeless | perhaps I'm overthinking this | 02:35 |
| wallyworld_ | huwshimi: i've updated the demo to use local storage to persist changes between page refreshes, and added in editing on the details page. let me know if there's anything else | 02:45 |
| huwshimi | wallyworld_: Awesome, will do. | 02:45 |
| poolie | lifeless, maybe so | 02:50 |
| poolie | perhaps that can wait until someone has a need for it | 02:50 |
| lifeless | wgrant: pop quiz; lp_serve and codehosting sections in schema.conf, both run as same uesr right ? | 03:05 |
| wgrant | lifeless: They should, yes. | 03:08 |
| wgrant | lifeless: Check the owner of their existing OOPSes? | 03:09 |
| huwshimi | Does anyone want to help me think about bug statuses/colours/grouping? Voice, or IRC if multiple people are keen. | 03:20 |
| huwshimi | wgrant, poolie: I think both of you have discussed colours etc on IRC in the past | 03:20 |
| huwshimi | wait, that should have been bug status colours and status grouping | 03:22 |
| wgrant | huwshimi: Sure. | 03:23 |
| wgrant | Hopefully poolie's around too. | 03:24 |
| huwshimi | wgrant: OK thanks, let's give it a minute and see if poolie wants to join in | 03:25 |
| huwshimi | wgrant: Or I can just ramble here | 03:25 |
| lifeless | here is good | 03:28 |
| huwshimi | sure | 03:29 |
| huwshimi | So, we're going to try out moving the status into the top line of the new bug listings. We'll sit the status next to the importance and style it similarly to the status. We need to figure out some colours for statuses. So... | 03:31 |
| huwshimi | The colours for the importance will probably stay the same (at least at this point). Colours do a good job of signifying different types of importance. | 03:31 |
| huwshimi | Even though importances are really one type of "thing" | 03:32 |
| huwshimi | We don't want the status colours to fight with importances so we could make them tones of one colour, or we could group statuses so that there are only a few colours | 03:33 |
| huwshimi | The status groups I came up with were the following: | 03:34 |
| huwshimi | Initial (New, Incomplete, Opinion, Confirmed, Triaged) | 03:34 |
| huwshimi | Rejected: (Invalid, Won't Fix) | 03:34 |
| wgrant | Opinion is Rejected | 03:34 |
| huwshimi | wgrant: Ah thanks | 03:34 |
| wgrant | Triaged is not Initial. | 03:34 |
| huwshimi | The other two groups were: working (In Progress) and done (Fix Committed and Fix Released) | 03:35 |
| wgrant | Right. | 03:36 |
| huwshimi | wgrant: Would you break up that inital group? I'm mostly trying to identify a group of statuses that are essentially the same thing | 03:36 |
| wgrant | Triaged certainly needs to be separate. | 03:36 |
| wgrant | I don't know about the others. | 03:36 |
| huwshimi | wgrant: So in a workflow it probably wouldn't move between statuses in the same group | 03:36 |
| wgrant | huwshimi: Fix Committed goes to Fix Released, New to Incomplete. | 03:37 |
| huwshimi | wgrant: Ah you're right | 03:38 |
| wgrant | Fix Committed, Won't Fix, Opinion and Confirmed have no good reason to exist. | 03:38 |
| lifeless | huwshimi: 'same thing' | 03:39 |
| lifeless | huwshimi: have you seen the issue tracker draft spec ? | 03:39 |
| huwshimi | lifeless: Yeah, I was just looking at that | 03:40 |
| huwshimi | wgrant: In a sense could you say that In Progress and Fix Committed are kind of the same thing? | 03:40 |
| lifeless | huwshimi: there is indeed an effort ongoing to reduce the number of statuses | 03:40 |
| huwshimi | wgrant: They're both a "this bug is being worked on" statuses, just with a different tense | 03:40 |
| lifeless | huwshimi: it is perhaps tricky to do just now- because of the ongoing debate about the value of the nuance | 03:41 |
| huwshimi | lifeless: Yeah, in some ways this might be a step towards that (having similar colours) | 03:41 |
| lifeless | huwshimi: we'd expect many 'new->incomplete', 'new->opinion|invalid|wontfix', 'new->triaged' transitions | 03:41 |
| lifeless | many projects don't use in-progress /fix committed at all AFAICT | 03:42 |
| lifeless | etc | 03:42 |
| wgrant | I think most projects would use In Progress. | 03:42 |
| wgrant | Fix Committed is probably rare. | 03:42 |
| lifeless | wgrant: in progress is bit twiddling overhead | 03:42 |
| huwshimi | lifeless: I guess the thing here is that the colours won't force anyone into any kind of workflow, but might (if people notice the subtleties) help people see what stage the bug is at. | 03:43 |
| lifeless | so for a quick segue | 03:45 |
| lifeless | there there a few interesting dimensions around a bug and lifecycle | 03:45 |
| lifeless | there is the progress bar dimension | 03:45 |
| lifeless | there is the what-is-it-waiting-for dimension | 03:45 |
| lifeless | there is the 'when will it be usable' dimension | 03:46 |
| lifeless | to illustrate the difference, consider an LP bug | 03:46 |
| lifeless | its 'done' when its released and switched on via flags | 03:46 |
| lifeless | to get there it may wait on user input many times (some of which may use the INCOMPLETE state) | 03:47 |
| lifeless | it may wait on dev, design, qa inputs | 03:47 |
| lifeless | it may wait on deployment pipeline | 03:47 |
| lifeless | and it may be usable for a user once its enabled for beta users | 03:47 |
| lifeless | so, I think its important to decide *which* dimension you are trying to quantise when you think about this | 03:48 |
| lifeless | otherwise you'll tie yourself, and our users, up in knots :) | 03:48 |
| lifeless | (and note that 'status' as its currently defined doesn't map directly to -any- of these dimensions) | 03:48 |
| lifeless | I wish I had some helpful insight here - sorry ! | 03:49 |
| huwshimi | lifeless: That is helpful. I still think we can provide some hints to what part the cycle of the bug is at. There's a group of bugs that need some extra info/management/discussion before they can be worked on (New, Triaged, Incomplete, Confirmed). There's the bugs that have been rejected (Invalid, Won't Fix, Opinion). There's bugs that are being worked on (In Progress, Fix Committed). And there are bugs that are do | 03:52 |
| huwshimi | ne (Fix Released). | 03:52 |
| huwshimi | I know that doesn't necessarily map to everyone's workflows | 03:53 |
| huwshimi | but I think it's correct in terms of what we have in Launchpad right now | 03:53 |
| huwshimi | And I | 03:54 |
| huwshimi | The result of those categories is just chosing a colour for each status. Do Invalid, Won't Fix and Opinion really deserve an individual colour or can they be lumped together in a "rejected" colour | 03:55 |
| * micahg wonders why opinion still exists | 03:56 | |
| wgrant | micahg: I think we all do. | 03:56 |
| huwshimi | haha | 03:56 |
| wgrant | huwshimi: Triaged bugs are ready to be worked on. | 03:57 |
| lifeless | huwshimi: 'triaged' bugs can be worked on' | 03:57 |
| huwshimi | ah, yes | 03:57 |
| lifeless | huwshimi: as can confirmed [they just don't have an importance set] | 03:57 |
| lifeless | huwshimi: I think the 'reject' and 'being worked on' sets are good | 03:57 |
| lifeless | huwshimi: arguably rejected + fix-released is one grouping (bugs that are finished with) | 03:58 |
| huwshimi | lifeless: I thought the same about bugs that are finished with, but I think it would be good to distinguish between them as they have pretty opposite outcomes | 03:59 |
| lifeless | huwshimi: sure, I buy that; was being a bit socratic :P | 04:00 |
| huwshimi | :) | 04:01 |
| huwshimi | So do you think I would get away with having 5 status colours? For each of: Unconfirmed (New, Incomplete), Ready (Triaged, Confirmed), Rejected (Invalid, Won't Fix, Opinion), Being worked on (In Progress, Fix Committed), Done (Fix Released) | 04:05 |
| huwshimi | (with unconfirmed, ready etc being labels I'm only using to help explain right now) | 04:06 |
| wgrant | That sounds reasonable. | 04:06 |
| lifeless | +1 | 04:07 |
| huwshimi | wgrant, lifeless: Awesome, thanks for the help :) | 04:08 |
| lifeless | anytime | 04:08 |
| StevenK | Is doctest an actual upstream Python module? | 05:00 |
| lifeless | yes | 05:02 |
| lifeless | its in the stdlib | 05:02 |
| StevenK | Oh, ew. | 05:02 |
| StevenK | Ah ha! poolie! | 05:17 |
| StevenK | 14337.1.1 mbp@can | from testtools.testresult.real import _details_to_str | 05:17 |
| * StevenK tries to remember the magic he used to get Person:+index working in a test harness. | 05:38 | |
| StevenK | Stupid RDF. | 05:38 |
| wgrant | Not RDF, but XRDS. | 05:39 |
| jtv | wgrant: are you reviewing today? If so: ooh, pick me, pick me! https://code.launchpad.net/~jtv/launchpad/bug-849683-patchup/+merge/83729 | 05:41 |
| wgrant | jtv: The cloner is used ~twice per release. | 05:42 |
| wgrant | To perform archive rebuilds. | 05:42 |
| jtv | That explains. Well, no more problem anyway, with this branch. | 05:42 |
| wgrant | Actually, IDS uses it too. | 05:43 |
| wgrant | So three times a release :) | 05:43 |
| wgrant | jtv: What changed in lib/lp/soyuz/doc/buildd-queuebuilder-lookup.txt? | 05:44 |
| wgrant | There's a big block of changes where I can't actually see any differences. | 05:44 |
| jtv | Lint. | 05:44 |
| wgrant | Yeah, but I can't see what. | 05:44 |
| wgrant | Oh. | 05:44 |
| jtv | Got indented too far (I guess by the doctest formatting tool), and thus overran the 78th column. | 05:44 |
| wgrant | Indended by 4 instead of 5. | 05:44 |
| wgrant | Yeah. | 05:44 |
| StevenK | AH | 05:44 |
| jtv | Was it 5? Ah yes. Then it wasn't even the formatting tool, I guess. | 05:45 |
| jtv | StevenK: “AH”? are you okay? | 05:45 |
| StevenK | jtv: I was wondering too | 05:45 |
| wgrant | jtv: Approved, thanks for the fixes and cleanups. | 05:46 |
| jtv | Thank you. | 05:46 |
| lifeless | allenap: wgrant: teamparticipation updates are racy; thats why it gets out of sync I suspect. | 05:56 |
| lifeless | allenap: or at least, may explain. Requires select for update to fix. | 05:56 |
| poolie | hi all | 05:56 |
| wgrant | lifeless: That's possible, but pretty unlikely. | 05:56 |
| poolie | StevenK, yes that was me | 05:56 |
| poolie | i even saw the lint warning | 05:56 |
| poolie | exporting the symbol seemed likely to overflow my stack | 05:57 |
| poolie | i guess i could have suppressed it? | 05:57 |
| lifeless | its a rather noddy warning TBH | 05:57 |
| lifeless | we have it disabled for most of LP | 05:57 |
| poolie | you could more reasonably warn it is an underscored symbol... | 05:58 |
| poolie | but | 05:58 |
| poolie | it is more of a warning of "may break in the future" rather than "is broken now" | 05:59 |
| poolie | let the future fix its own bugs, we have enough of our own | 05:59 |
| poolie | huwshimi, lifeless, like robert said there are a bunch of different dimensions there | 05:59 |
| poolie | ah | 06:00 |
| poolie | i agree with a lot of that stuff | 06:00 |
| poolie | i will suggest one more thing | 06:00 |
| poolie | which is that some statuses are inherently more interesting than others, most of the time | 06:00 |
| poolie | specifically the 'in play' statuses of new, inprogress, fixreleased | 06:00 |
| poolie | *fixcommitted, i mean | 06:00 |
| poolie | and maybe incomplete | 06:00 |
| poolie | they are more likely to be something some one wants to work on next | 06:00 |
| poolie | perhaps they should be more prominent | 06:00 |
| StevenK | poolie: It annoys me that bin/test prints it every time | 06:01 |
| poolie | does it? | 06:01 |
| poolie | the import warning? | 06:02 |
| StevenK | Yup | 06:02 |
| poolie | guys, help me decide about the tarball download feature | 06:02 |
| poolie | it does not appear on the default lh home page only on per-revision pages | 06:02 |
| poolie | i could fix it and update | 06:02 |
| wgrant | bug | 06:02 |
| poolie | or, i could fix a bug saying it's not in the lp main ui | 06:02 |
| poolie | which is ultimately more interesting | 06:02 |
| poolie | bug 240580 | 06:03 |
| _mup_ | Bug #240580: Ability to download a tarball for a revision <qa-ok> <Launchpad itself:In Progress by mbp> <loggerhead:In Progress by mbp> < https://launchpad.net/bugs/240580 > | 06:03 |
| poolie | you just closed it wgrant :) | 06:03 |
| wgrant | Both? :) | 06:03 |
| poolie | or, no, maybe that was something else | 06:03 |
| huwshimi | poolie: Thanks. I'm a little hesitant to start placing importance on certain statuses, just because I don't understand enough about the ramifications on some people's workflows (I know it'd just be a small UI thing, but it's one less issue with the UI I want to possibly introduce right now). | 06:05 |
| lifeless | EWHAT: database/schema/tst.dot | 06:06 |
| poolie | that also sounds reasonable | 06:06 |
| poolie | what do you specifically want to do next? | 06:06 |
| poolie | huwshimi, i'd be curious about your thoughts on my mail about a Thanks button | 06:06 |
| poolie | more from a ux than implementation perspective | 06:07 |
| poolie | not likely to happen soon though | 06:07 |
| lifeless | poolie: doing it the lh main ui would be nice; doing it in the LP main ui is also nice. I don't see them as the same bug, and whichever you choose to work on first is up to you :) | 06:07 |
| poolie | i think i will mark this bug complete and file followons | 06:07 |
| huwshimi | poolie: My initial reaction is that it would be a nice, friendly, community building touch. I think it would add a nice rewarding experience to using Launchpad. | 06:08 |
| poolie | :) | 06:10 |
| lifeless | jtv: hey, is there an existing collection of scripts for doing db schema evolution w/slony the way we do ? | 06:12 |
| jtv | lifeless: no idea — haven't followed how our schema stuff interacts with slony tbh | 06:12 |
| lifeless | the scripts get wrapped in slonik | 06:13 |
| lifeless | so things that want to use ORMs etc to generate db patches - well they can't ;) | 06:14 |
| lifeless | they could if they emit the schema changes to a stream, but not if they depend on commit/rollback etc | 06:14 |
| lifeless | or on processing data mid-migration | 06:14 |
| lifeless | however there are a raft on pypi | 06:15 |
| lifeless | random link of the day | 06:17 |
| lifeless | http://bulbflow.com/overview/ | 06:17 |
| jtv | Maybe once we're on 9.x we can look into streaming replication. | 06:23 |
| lifeless | yeah | 06:23 |
| lifeless | stub wants to wait for a bit for 9.x, some slony issues that concern him | 06:23 |
| jtv | Yes. I do still water at the mouth with new postgres release summaries though. | 06:24 |
| lifeless | :) | 06:24 |
| poolie | lifeless, nice | 06:29 |
| jtv | lifeless: the staging oops report contains an entry that makes me wonder if you've set the timeout threshold too low… | 06:29 |
| jtv | -1.00s OOPS-fead2780a43b01845f361d2acbb79f14 Unknown | 06:29 |
| lifeless | jtv: hah | 06:29 |
| lifeless | :) | 06:29 |
| jtv | It took minus one second and _still_ it times out. That's going to be hard to optimize. | 06:29 |
| lifeless | jtv: its all about i | 06:30 |
| jtv | Are we squaring our times then? | 06:30 |
| poolie | call cern | 06:30 |
| jtv | poolie: good point. | 06:30 |
| lifeless | jtv: oops tools applies a heuristic | 06:31 |
| lifeless | jtv: it appears to be glitched - https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-fead2780a43b01845f361d2acbb79f14 | 06:31 |
| lifeless | jtv: note the oops actually doesn't report any timing data whatsoever | 06:31 |
| lifeless | jtv: and by glitched I mean '-1 to avoid confusion' | 06:31 |
| jtv | GAHHH sorry I have to focus on something else right now. | 06:33 |
| jtv | Grrr all these notify() functions and all this time the test wasn't calling the right one. | 06:33 |
| lifeless | ugh | 06:38 |
| lifeless | database/schema depends on canonical.* | 06:38 |
| lifeless | twitch | 06:38 |
| StevenK | How? | 06:38 |
| lifeless | from canonical.launchpad.scripts import db_options, logger_options, logger | 06:38 |
| lifeless | from canonical.database.sqlbase import connect, ISOLATION_LEVEL_AUTOCOMMIT | 06:38 |
| lifeless | from canonical.database.postgresql import fqn | 06:38 |
| StevenK | Ah | 06:39 |
| lifeless | yes | 06:40 |
| lifeless | so, making a separate tool will involve some way to bridge our global magical config settings and the separate tool | 06:41 |
| StevenK | You want to pull database/schema out entirely? | 06:42 |
| lifeless | the driving logic, yes. | 06:42 |
| lifeless | microservices need DB's and slony. | 06:42 |
| lifeless | I need a name though | 06:44 |
| lifeless | lazr_postgresql I guess | 06:44 |
| lifeless | (refusing to namespace on grounds of being sane) | 06:44 |
| jtv | wgrant: if Ubuntu syncs a source package from Debian and then builds it, would SPR's dsc_signing_key and dsc_maintainer_rfc822 be the Debian maintainer's? | 07:18 |
| wgrant | jtv: signingkey is probably empty. I'm not sure what maintainer is... it depends what gina does. | 07:19 |
| * wgrant hunts. | 07:19 | |
| wgrant | spr = SourcePackageRelease( | 07:19 |
| wgrant | section=sectionID, | 07:19 |
| wgrant | creator=maintainer.id, | 07:19 |
| wgrant | component=componentID, | 07:19 |
| wgrant | sourcepackagename=name.id, | 07:19 |
| wgrant | maintainer=maintainer.id, | 07:19 |
| wgrant | So the maintainer should be the Maintainer field from the imported source package. | 07:20 |
| bigjools | morning guys | 08:02 |
| jtv | Good morning | 08:04 |
| jelmer | Goeiemorgen jtv | 08:04 |
| jtv | Goedenmorgen! | 08:05 |
| bigjools | double dutch | 08:05 |
| danhg | Morning | 08:58 |
| mrevell | Hey | 09:01 |
| adeuring | good morning | 09:02 |
| === jam1 is now known as jam | ||
| poolie | hi all | 09:22 |
| poolie | bigjools, is rabbit appropriate for storing thing indefinitely? | 09:23 |
| poolie | maybe it is, i just had the idea it was for in-flight messages | 09:23 |
| bigjools | poolie: not at all, it's just a transport mechanism | 09:23 |
| poolie | so it's rabbit as a path to a service storing stuff in psql or whatever | 09:23 |
| bigjools | it's just a very useful way of firing and forgetting | 09:23 |
| poolie | memories of Dallas :) | 09:24 |
| bigjools | I only shot Osama, no rabbits :) | 09:24 |
| lifeless | bigjools: would need a query API too for it; so if doing that might use http for the store as well (given that we probably want to know the audit was committed :P) | 09:25 |
| === almaisan-away is now known as al-maisan | ||
| bigjools | lifeless: rabbit has a reliable commit mechanism IIRC | 09:26 |
| lifeless | bigjools: if you use it in rpc mode its equivalent to an http call | 09:27 |
| bigjools | why not just stick to Rabbit then? | 09:27 |
| lifeless | bigjools: if you use it in persistent message fire-and-forget-but-tell-me-that-there-is-at-least-one-subscriber then its potentially lossy unless you have an HA story for it | 09:27 |
| lifeless | bigjools: and we don't have an HA story for it | 09:27 |
| bigjools | and do we have HA story for some future storage mechanism? | 09:28 |
| lifeless | slony | 09:28 |
| lifeless | (thats yes, if we use postgresql, or yes if we use cassandra, etc) | 09:28 |
| bigjools | do slaves stay up if the master goes? | 09:28 |
| bigjools | can you store data in a HA fashion? | 09:29 |
| lifeless | for slony, yes and no - slaves stay up, master being down prevents writes | 09:29 |
| bigjools | which is my point | 09:29 |
| lifeless | this is different to rabbit in the fire and forget mode where messages can disappear entirely | 09:29 |
| lifeless | so I don't see why its your point | 09:30 |
| bigjools | my point is that nothing has HA for storage | 09:30 |
| bigjools | so why not just use a single API over rabbit instead of an API for this, another API for that ... | 09:30 |
| lifeless | uhm, cassandra does | 09:30 |
| lifeless | if we need HA writes | 09:31 |
| bigjools | we don't use cassandra | 09:31 |
| lifeless | this discussion is maddening | 09:31 |
| lifeless | I'll chat with you another day | 09:31 |
| bigjools | why? | 09:31 |
| bigjools | you don;t like my questions? | 09:31 |
| lifeless | I don't mind questions, but the goal posts seem to be moving | 09:31 |
| lifeless | I'm talking about being sure the audit item is logged | 09:32 |
| bigjools | what goal posts? | 09:32 |
| lifeless | you're talking about being up all the time | 09:32 |
| lifeless | they are different things | 09:32 |
| bigjools | umm, you started with the HA thing | 09:32 |
| bigjools | not me | 09:32 |
| lifeless | I started with lossiness | 09:32 |
| lifeless | not with HA; to avoid loss of messages with rabbit you need to either be using it in RPC mode, which is rather pointless, or you need to an HA story for it | 09:33 |
| bigjools | we might as well just use a separate Storm store to talk to an auditing PG | 09:34 |
| lifeless | well | 09:34 |
| lifeless | that wouldn't be reusable by other services and wouldn't have higher integrity due to needing direct access from the main appservers etc | 09:35 |
| lifeless | what we have with rabbit today is a mostly-reliable messaging syste, | 09:35 |
| lifeless | which is great | 09:35 |
| lifeless | we don't have guaranteed delivery except in rpc mode where you wait for a reply from the consumer | 09:36 |
| lifeless | the main impact this has is that when we really care about a message being delivered, we need to either use rpc mode or not pass it via rabbit; either is ok | 09:37 |
| stub | Technically, our writes to PostgreSQL can be lost. Slaves are lagged, and if we lose the master we lose the lag time's amount of data changes. | 09:39 |
| lifeless | true, though if we lose the change we made, and keep the audit trail for it, thats arguably less of a problem than keeping the change and losing the audit trail | 09:40 |
| stub | I'd consider looking at celery, which seems to allow you to use various things as the back end such as rabbit or postgresql | 09:40 |
| stub | I had a skim the other day since abently keeps mentioning it and it looks nice. I like projects that take their documentation seriously. | 09:41 |
| lifeless | bigjools: sorry for the maddening comment; ELONGDAY + we are/were crossing wires | 09:43 |
| lifeless | bigjools: I usually value teasing things apart and getting more clarity :( | 09:43 |
| * lifeless heads to be | 09:43 | |
| lifeless | d | 09:43 |
| lifeless | (PS: cynthia had a bad night last night.... so we all did) | 09:44 |
| bigjools | lifeless: I have jetlag, you have a baby. Great combo :) | 09:44 |
| lifeless | indeed! | 09:44 |
| lifeless | have a good day | 09:44 |
| * lifeless goes | 09:44 | |
| === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 3*10^2 | ||
| jml | lifeless: fwiw, re "Fixture" suffix: my main concern is that I use TempDir and EnvironmentVariableFixture the most, and either the former should be TemporaryDirectoryFixture or the latter should be EnvVar (or at least EnvironmentVariable). Too much to remember otherwise. | 10:23 |
| allenap | wgrant: Regarding your comment on https://bugs.launchpad.net/bugs/897269 about check-teamparticipation.py. I don't want to have to manually fix TP ever, so I think it's worth fixing it automatically as well as having the report. | 10:37 |
| _mup_ | Bug #897269: check-teamparticipation.py does not fix spurious participation records <teams> <Launchpad itself:In Progress by allenap> < https://launchpad.net/bugs/897269 > | 10:37 |
| mpt | "This membership is going to expire in 7 days from now" | 11:23 |
| === matsubara-afk is now known as matsubara | ||
| allenap | vila: You have put a big smile on my face :) https://bugs.launchpad.net/bzr/+bug/843211 | 11:58 |
| _mup_ | Bug #843211: With pipelines I cannot set push_location and public_branch generally <config> <Bazaar:Fix Released by vila> < https://launchpad.net/bugs/843211 > | 11:58 |
| bigjools | bug 872112 | 11:59 |
| _mup_ | Bug #872112: Buildd-manager combines DB write transactions and asynchronous calls <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872112 > | 11:59 |
| vila | allenap: glad you like it ! Other kind of feedback also welcome :) | 12:00 |
| StevenK | I think everyone who uses pipelines will buy vila a beer ... | 12:00 |
| allenap | Indeed! | 12:01 |
| StevenK | bzr push errors with can't do it / branch doesn't exist, so I sigh and run sync-pipeline | 12:01 |
| * vila coughs | 12:01 | |
| vila | make sure it works as you expect, there may still be some shaloow glitches | 12:01 |
| vila | shallow | 12:01 |
| StevenK | Since I've stopped landing so many Soyuz branches, I've stopped using pipelines so much. I wonder why that is ... | 12:02 |
| === mrevell_ is now known as mrevell | ||
| allenap | Does anyone know where I can find (in order to modify) the oops-tools-django-dependencies or oops-tools-django-testsuite-dependencies packages? I am a total newb to this stuff. | 12:46 |
| mrevell | matsubara, ^ ? | 12:48 |
| matsubara | allenap, bzr+ssh://bazaar.launchpad.net/%2Bbranch/lazr-source-dependencies/ | 12:51 |
| allenap | matsubara: Thanks :) | 12:51 |
| matsubara | hmm that came from bzr info and looks wrong. the right branch is lazr-source-dependencis | 12:51 |
| matsubara | allenap, https://launchpad.net/lazr-source-dependencies | 12:51 |
| allenap | matsubara: Cool. | 12:52 |
| * allenap contemplates filing a bug about not finding that package from site-wide search. | 12:52 | |
| === matsubara_ is now known as matsubara | ||
| === matsubara is now known as matsubara-lunch | ||
| flacoste | allenap, matsubara-lunch: lazr-source-dependencies is deprecated, use lp-source-dependencies | 14:22 |
| allenap | flacoste: I was about to ask matsubara-lunch about that, but for another reason. I was looking for the oops-tools-django-dependencies and oops-tools-django-testsuite-dependencies packages, but they're not in either lazr- or lp-source-dependencies. Do you know anything about them? | 14:24 |
| flacoste | allenap: aren't they in the meta-lp-deps project? | 14:24 |
| * allenap looks | 14:25 | |
| abentley | gary_poster: How I manually get the SimpleViewClass-munged version of a view class? | 14:26 |
| flacoste | allenap: where did you get these packages from? apt-cache search doesn't find them over here? | 14:26 |
| allenap | flacoste: They're in the python-oops-tools PQM chroot, so it's conceivable that they were made by a LOSA. | 14:27 |
| flacoste | allenap: yeah, i don't know where these packages are maintained? did you look on the oops-tools deployment wiki page if there is any info on them?% | 14:28 |
| allenap | flacoste: I'll have a look. | 14:29 |
| flacoste | https://dev.launchpad.net/QA/OopsToolsSetup | 14:29 |
| flacoste | allenap: i don't see anything there | 14:29 |
| allenap | Ta. | 14:29 |
| flacoste | if you find the answer, please update that page :-) | 14:29 |
| allenap | flacoste: Will do :) | 14:29 |
| allenap | mthaddon: Do you know what the lineage of the oops-tools-django-dependencies and oops-tools-django-testsuite-dependencies is? I've just seen that the former is installed on carob. It's also installed in the python-oops-tools PQM chroot (wrt. https://rt.admin.canonical.com//Ticket/Display.html?id=49246). | 14:33 |
| mthaddon | allenap: I think they've been losa-maintained up til now and are just in lucid-cat (should be able to download the source from any server in the DC) | 14:36 |
| rick_h_ | abentley: no, I've muted everyhting, just listening | 14:38 |
| abentley | rick_h_: no, you haven't. Your lips are red. | 14:38 |
| rick_h_ | yea, but you can't hear me right? abentley | 14:38 |
| abentley | I'm not hearing you saying anything. I'm just hearing echo. | 14:39 |
| rick_h_ | ok, well I've muted all inputs at pulse | 14:39 |
| abentley | rick_h_: You were still outputting to Mumble. I guess it's possible to do that without using Pulseaudio, but it seems unlikely. | 14:40 |
| allenap | mthaddon: Ta, thanks. | 14:43 |
| rick_h_ | abentley: adeuring http://www.youtube.com/watch?v=_zhQIfT7g58&feature=youtube_gdata_player is the video I mentioned, good stuff | 14:52 |
| adeuring | thanks | 14:52 |
| abentley | rick_h_: cool, thanks. | 14:56 |
| === vednis is now known as mar | ||
| === mar is now known as mars | ||
| rvba | Hi gary_poster, I'm investigating a timeout (bug 890927) and it turns out the problem is the repeated security check queries (line 2234 in lib/canonical/launchpad/security.py). Jeroen said I should talk to you about this because it's a matter you've worked on previously… so here I am :) | 15:03 |
| _mup_ | Bug #890927: private PPA Archive:+index timeouts <timeout> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/890927 > | 15:03 |
| bigjools | I thought they were cached these days? | 15:04 |
| rvba | I think they are *somewhat* cached. But each package on the page generates a security check query. | 15:05 |
| rvba | In this case, the exact same query is repeated. | 15:06 |
| bigjools | that is a harder problem to solve | 15:06 |
| bigjools | I guess this is the "published" check? | 15:06 |
| rvba | Right, hence Jeroen's advice to talk to Gary about it. | 15:06 |
| bigjools | if you can already see the page, there's little point doing those checks | 15:07 |
| bigjools | since all the necessary security has been passed already | 15:07 |
| rvba | It's the ViewArchive launchpad.View check. | 15:07 |
| rvba | True. | 15:07 |
| bigjools | right, so the view check is done for the archive, and then the same archive again and again for each package | 15:07 |
| rvba | Exactly | 15:07 |
| bigjools | a dirty fix would be rSP :) | 15:08 |
| rvba | Dirty indeed :), a more generic caching mecanism would be nice here. | 15:08 |
| rvba | mechanism* | 15:09 |
| rvba | Besides, the call comes from a place that I think is called from many other places which might need the security checks. | 15:09 |
| rvba | Working around that might be possible but even more dirty. | 15:10 |
| === matsubara-lunch is now known as matsubara | ||
| bigjools | rvba: are you thinking of a cache of (obj, permission_name) ? | 15:12 |
| rvba | Also, solving this elegantly might bring more performance improvements elsewere. | 15:12 |
| bigjools | true | 15:12 |
| rvba | bigjools: right now, honestly I don't know if that's really possible but yeah, I was thinking about having a LRU in the request for that. | 15:13 |
| rvba | bigjools: but I need to understand how the caching in place (which does not work in this case for some reason) works first. | 15:16 |
| gary_poster | rvba, I'm sorry I missed this | 15:21 |
| gary_poster | rvba, I'm trying to use Empathy as my IRC client and not having success with notifications yet | 15:21 |
| gary_poster | rvba, should I still look at the backlog and try to figure out what is going on :-) | 15:21 |
| rvba | gary_poster: no worries… maybe you can give me a few hints to understand how perm check caching works and what you think can be done in this case. | 15:21 |
| gary_poster | ok lemme read backlog | 15:22 |
| rvba | thanks gary_poster. | 15:22 |
| abentley | gary_poster: How I manually get the SimpleViewClass-munged version of a view class? | 15:22 |
| * gary_poster tries to remember these details... | 15:24 | |
| gary_poster | abentley, if I understad you correctly, that is what you will get from the adapter lookup | 15:25 |
| gary_poster | You can get the adapter registry itself | 15:25 |
| gary_poster | and do a lookup there without actually instantiating the class | 15:25 |
| gary_poster | if that helps | 15:25 |
| abentley | gary_poster: I have been trying to do the lookup manually, but I don't know exactly what to look up. Here's what I'm trying: https://pastebin.canonical.com/56497/ | 15:26 |
| === jcsacket1 is now known as jcsackett | ||
| gary_poster | rvba, so, I'm not ignoring you, but abentley's question is easier :-P | 15:29 |
| rvba | gary_poster: I figured :) | 15:29 |
| gary_poster | abentley, I'd suggest getting the site manager. that has an adapter registry on it for adapter lookups (and a separate one for utilities) | 15:30 |
| rvba | gary_poster: I'm not expecting a solution but hints btw | 15:30 |
| gary_poster | ack | 15:30 |
| gary_poster | abentley, that gives you an interface that's closer to metal | 15:31 |
| gary_poster | and I think it will be easier for you to use | 15:31 |
| gary_poster | the interface is described in zope.interface IIRC | 15:31 |
| gary_poster | abentley, as to the traceback, I don't know enough about what the cls is and so on to have an opinion as to what the problem is | 15:32 |
| abentley | gary_poster: the cls is defined at the top of the pastebin. | 15:32 |
| gary_poster | but I suggest dropping that and working with an interface that lets you specify the interfaces. | 15:32 |
| gary_poster | abentley: duh, sorry. in that case, I'd guess the problem is that +base-layout-macros is registered for something else. The adapter registry will give you the raw materials to anwer that question directly though. | 15:34 |
| gary_poster | I'm more than happy to dig in with you, abentley, but I'm trying to re-set up my LP environment with LXC, so I don't have a working environment atm | 15:35 |
| gary_poster | and I should try to help rvba | 15:35 |
| abentley | gary_poster: undertood. I used +base-layout-macros because it's registered for *, which I thought meant anything. | 15:35 |
| gary_poster | yes abentley, you are right. I don't have an immediate answer; I would have to dig too. :-/ | 15:36 |
| gary_poster | rvba, so, IIRC, we cache our security lookups in the security policy. | 15:37 |
| rvba | gary_poster: I see that in lib/canonical/launchpad/webapp/authorization.py.LaunchpadSecurityPolicy | 15:37 |
| === al-maisan is now known as almaisan-away | ||
| gary_poster | right rvba. Maybe if I look at that I will better understand the problem. | 15:38 |
| gary_poster | Because ATM I don't see what isn't working | 15:39 |
| rvba | gary_poster: me neither but maybe I'll try debugging it to see what's going on … then I'll come back to you. How does that sound? | 15:39 |
| rvba | gary_poster: the thing that I don't get is where the cache is exactly. I see a local object named cache being manipulated in checkPermission (same file). | 15:42 |
| gary_poster | rvba, cool. I'm interested in the IApplicationRequest check, because that's the only thing that jumps out at me as a way for the cache to be ignored. Although...these objects are in fact different, right? | 15:43 |
| rvba | I suspect my problem is that I've plenty of different objects being checked… and it turns out the check is the same because the objects are all related to the same archive. | 15:43 |
| bigjools | gmb, you need to thank me. It took *me* 5 hours to review jtv's buildd-manager branch. | 15:44 |
| gary_poster | rvba, right. So, that would lead to a few sorts of solutions | 15:44 |
| bigjools | the _underlying_ check is common | 15:45 |
| gmb | bigjools: You mean the 1200 line one that StevenK appeared to have started reviewing? | 15:45 |
| gary_poster | rvba, am I right that actually instantiating the IAuthorization adapter is the expensive bit here? | 15:45 |
| rvba | bigjools: exactly. | 15:45 |
| bigjools | gmb: that is the badger | 15:45 |
| gmb | bigjools: Thank you for taking care of it. | 15:45 |
| gary_poster | rvba, can we state categorically that these objects get their permissions from some other object? | 15:45 |
| gary_poster | I believe we have an existing mechanism for that sort of thing | 15:46 |
| bigjools | gmb: :) You didn't actually need to thank me, I am just feeling relieved I finished it | 15:46 |
| gmb | bigjools: (I daresay that it would have needed input from you or your fellow Soyuz experts either way) | 15:46 |
| gary_poster | I do not know how efiicient it is | 15:46 |
| bigjools | gmb: actually it was more of a Twisted domain change | 15:46 |
| rvba | gary_poster: yes, SourcePackagePublishinghistory -> Archive. | 15:46 |
| gmb | bigjools: I was really glad when I saw StevenK's name attached to it; I guess that made me overlook the fact that he hadn't actually reviewed it... | 15:46 |
| bigjools | lol | 15:46 |
| gary_poster | rvba, ok, what is their IAuthorization now? I think bac recently did some work on IAuthorizations that can explicitly pass their work off to another object. We should make sure that this takes advantage of the cache | 15:47 |
| rvba | gary_poster: the expensive part is the query, triggered by the call to getUtility(IArchiveSubscriberSet).getBySubscriber in checkAuthenticated of ViewArchive (lib/canonical/launchpad/security.py) | 15:47 |
| gary_poster | rvba, do you happen to have a stack trace for that? | 15:48 |
| rvba | gary_poster: that sounds like a solution. | 15:48 |
| rvba | gary_poster: yes, hang on. | 15:48 |
| rvba | gary_poster: http://paste.ubuntu.com/753787/ | 15:48 |
| flacoste | rvba: are you qa-ing Bug:887078? | 15:49 |
| flacoste | once that's clear, we can deploy and re-enable custom bugs listing | 15:49 |
| rvba | flacoste: I'm on it. | 15:50 |
| gary_poster | rvba, ok cool. That looks like we could take advantage of the cache pretty easily. Lemme see if I can find the magic authorization adapter... | 15:51 |
| gary_poster | (I see you are doing something else, np) | 15:51 |
| rvba | flacoste: rarg, in fact I QAed it this morning, I simply forgot to change the tag. Sorry about that. | 15:52 |
| rvba | Qa-ok. | 15:52 |
| rvba | gary_poster: cool! | 15:52 |
| gary_poster | I'm not sure which objects we are talking about here, but I suspect that we are already using DelegatedAuthorization, which I bet is what I was looking for. I'm slowed down by having to install stuff like ctags, sorry | 15:57 |
| bigjools | gary_poster: not using pycharm? :) | 15:57 |
| gary_poster | bigjools, with my new-ish Clojure (lisp-y) interest, emacs has been getting my attention these days :-) | 15:58 |
| bigjools | run away! | 15:58 |
| gary_poster | :-) | 15:59 |
| gary_poster | rvba, ok yeah, this is interesting | 16:00 |
| gary_poster | lib/lp/app/security.py has DelegatedAuthorization | 16:01 |
| gary_poster | it delegates to the raw authorization adapters | 16:01 |
| gary_poster | thereby skipping our cache entirely | 16:01 |
| rvba | Makes sense. | 16:01 |
| gary_poster | so... | 16:01 |
| gary_poster | we can think about this a few different ways | 16:02 |
| rvba | ViewSourcePackagePublishingHistory inherits from DelegatedAuthorization and delegates the checks to obj.archive. | 16:02 |
| gary_poster | right | 16:02 |
| gary_poster | my first coherent thought is that this abstraction bay be in the wrong place | 16:02 |
| gary_poster | may | 16:02 |
| gary_poster | Because it feels like the security policy ought to be in charge of its cache | 16:03 |
| gary_poster | so *it* ought to be able to see "oh look, it is delegated" | 16:03 |
| gary_poster | and *it* can look in the cache | 16:03 |
| gary_poster | and if it doesn't exist, do the adapter dance | 16:03 |
| gary_poster | that's less flexible than what we have now | 16:04 |
| gary_poster | but it ought to be a whole heck of a lot faster for cases like this | 16:04 |
| gary_poster | So let's think about an alternate case for a sec though | 16:05 |
| gary_poster | let's say we wanted to keep DelegatedAuthorization as is | 16:05 |
| gary_poster | in order to do that... | 16:05 |
| rvba | Maybe instead of calling checkAuthenticated in there we could use the checking method from LaunchpadSecurityPolicy | 16:06 |
| gary_poster | not only would it need to know about the cache, but it would need to be able to convert the cache answer to a real answer | 16:06 |
| gary_poster | because the cache answer is for a gievn participation | 16:07 |
| gary_poster | which means a given user | 16:07 |
| gary_poster | checkAuthenticated would need to look at the participation | 16:07 |
| gary_poster | (the request) | 16:07 |
| gary_poster | and compare the participation's user with the user it has | 16:07 |
| gary_poster | if they are the same, then we can use the cache | 16:07 |
| gary_poster | if not, we have to do our usual checks | 16:07 |
| gary_poster | that would be relatively easy to code, but it feels icky to me | 16:08 |
| rvba | this might be good enough for my problem :) | 16:08 |
| gary_poster | yeah | 16:08 |
| gary_poster | I don't love it, but it feels practical | 16:08 |
| gary_poster | let's talk about what feels nicer to me for just a sec though :-) | 16:08 |
| gary_poster | and see if something can fall out there | 16:08 |
| rvba | sure :) | 16:08 |
| rvba | I'm fuzzy about this participation thing though… | 16:09 |
| gary_poster | well, first, do you see what I mean about why it would be nicer, or am I on crack | 16:09 |
| rvba | What does it means exactly? | 16:09 |
| gary_poster | oh sure | 16:09 |
| gary_poster | so, the zope security system has this idea that multiple participants (think "principals," users or groups) can be involved in a security interaction. This allows modeling people granting permissions without escalating permissions. If I give you the ability to do something, and you try to do it, the security system should consider my permissions and your permissions, or else we are potentially in a privilege escala | 16:12 |
| gary_poster | tion scenario | 16:12 |
| gary_poster | that is unimprtant to us | 16:12 |
| gary_poster | we only allo w a single participation | 16:12 |
| gary_poster | and that is a request | 16:12 |
| gary_poster | which represents a security interaction between a user and the system | 16:12 |
| rvba | ok, hence the whole len(participations) > 1: raise RuntimeError("More than one principal participating.") | 16:12 |
| gary_poster | typically for the length of a transaction | 16:12 |
| gary_poster | precisely | 16:13 |
| gary_poster | so that's a participation | 16:13 |
| rvba | ok, thanks gary_poster. | 16:13 |
| gary_poster | is that clear-ish now, or should I try again? :-) | 16:13 |
| gary_poster | ok cool | 16:13 |
| gary_poster | so, my concern is that the cache on the participation is an artifact of the security policy | 16:13 |
| gary_poster | We could expose the cache in some way explicitly I suppose | 16:14 |
| gary_poster | Although... | 16:15 |
| gary_poster | Well, I have an old dislike of grabbing the request from the air | 16:15 |
| gary_poster | (thread local) | 16:15 |
| gary_poster | and I'd like to do that in as few places as possible | 16:15 |
| gary_poster | but anyway | 16:15 |
| rvba | gary_poster: why would we need the request? I suppose you mean because we need to get the user, but the user is provided when checkAuthenticated is called right. | 16:16 |
| rvba | ? | 16:16 |
| rvba | So if we expose the cache like you said, we could use it in DelegatedAuthorization.checkAuthenticated | 16:17 |
| gary_poster | rvba, we need the request, because it is the participation, and it has the cache that the security policy sets up. So if the authorization itself needs to check the cache, it needs to pull the request up | 16:17 |
| gary_poster | right rvba. It woud ideally be some kind of utility, I guess, if we did it that way | 16:17 |
| rvba | Ah ok, the security policy is on the request itself. | 16:17 |
| gary_poster | rvba, not quite, the cache is. Let's look back at authorization.py | 16:18 |
| rvba | wd = participation.annotations.setdefault(LAUNCHPAD_SECURITY_POLICY_CACHE_KEY,weakref.WeakKeyDictionary()) | 16:18 |
| rvba | cache = wd.setdefault(objecttoauthorize, {}) | 16:19 |
| gary_poster | LaunchpadSecurityPolicy is our security policy, obviously, Less obviously, instantiating it creates the interaction. | 16:19 |
| gary_poster | And yeah, there's the participation. | 16:19 |
| gary_poster | == request | 16:19 |
| gary_poster | with the cache | 16:19 |
| gary_poster | rvba, fwiw, I'm fine with a call of some sort too if you like, if you think it would go faster. Fine with irc too :-) | 16:20 |
| rvba | gary_poster: I was about to suggest the same thing :) | 16:20 |
| gary_poster | :-) | 16:20 |
| * rvba fires up skype. | 16:20 | |
| rvba | skype ok? | 16:20 |
| gary_poster | yeah, cool rvba | 16:21 |
| gary_poster | I'm garyposter on Skype, rvba | 16:21 |
| rvba | gary_poster: I'm trying to find how to add a new contact, hang on :) | 16:23 |
| === beuno is now known as beuno-lunch | ||
| === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 | ||
| === Ursinha is now known as Ursinha-lunch | ||
| sinzui | matsubara, Can you do exploratory testing of bug 885692. I think this bug fixes bug 603732 and bug 375331 too | 17:32 |
| _mup_ | Bug #885692: bug supervisors have more power than maintainers and admins <bugs> <disclosure> <qa-ok> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/885692 > | 17:32 |
| _mup_ | Bug #603732: If there is no driver a maintainer should be able to accept a bug nomination <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/603732 > | 17:32 |
| _mup_ | Bug #375331: Some extra filebug options don't show up for projects not having a bug supervisor <bugs> <projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/375331 > | 17:32 |
| === beuno-lunch is now known as beuno | ||
| matsubara | sinzui, yes | 17:43 |
| rick_h_ | abentley: adeuring heads up, running out for lunch, bbl. | 17:44 |
| abentley | rick_h_: okay | 17:44 |
| === salgado is now known as salgado-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === salgado-lunch is now known as salgado | ||
| poolie | hi all | 19:08 |
| rick_h_ | howdy poolie | 19:08 |
| poolie | hi there | 19:09 |
| poolie | what are you up to now rich_h_? | 19:09 |
| rick_h_ | poolie: chilling in a conference room in AL while beating my head on a wall trying to figure out why this one tests fails | 19:10 |
| poolie | oh you're with gary? | 19:10 |
| rick_h_ | hate that "hmm, one last test and all done..." the last ones know how to poke you | 19:10 |
| poolie | or deryck? | 19:10 |
| rick_h_ | not atm | 19:10 |
| poolie | yeah | 19:11 |
| rick_h_ | but hopefully later this wek | 19:11 |
| rick_h_ | week that is | 19:11 |
| poolie | or spurious failures after a long test run | 19:11 |
| abentley | gary_poster: The ultimate solution to my problem: http://pastebin.ubuntu.com/754062/ (I did not realize that view were multi-adapters). | 20:17 |
| poolie | o/ abentley | 20:18 |
| gary_poster | abentley: ah, sorry, I should have spotted that. Glad you found it. | 20:18 |
| abentley | poolie: \o | 20:18 |
| dobey | who do i bug exactly, to fix problems i see with vcs imports? or should i just bug someone to add me to that team so i can fix them? | 20:18 |
| gary_poster | abentley, fwiw, I still think you will like the end result of your code better if you use the raw adapter registry | 20:19 |
| poolie | fix in the sense of failures, or they are just misconfigured, dobey? | 20:19 |
| poolie | if you want to help garden them i'm sure that would be welcome | 20:19 |
| gary_poster | dobey, have you already mentioned something in Launchpad questions? If so, I apologize, we're trying to work through the list. | 20:19 |
| dobey | poolie: well in this case it's misconfigured | 20:19 |
| abentley | gary_poster: This is test code, and it's passing, so I don't understand what more I'd want. | 20:19 |
| gary_poster | abentley: oh ok. I thought you were making a tool. What you'd want more: not to have to create a throw-away object. | 20:20 |
| poolie | jelmer, how could we do that for dobey? | 20:20 |
| dobey | gary_poster: no, i just spent ~30 minutes or so looking at 2.5 year old code that i thought was new :( | 20:20 |
| gary_poster | dobey :-( gotcha | 20:20 |
| dobey | gary_poster: and my understanding is that ~vcs-imports is a place most people don't want to be | 20:21 |
| abentley | gary_poster: Oh, I thought the API was the same whether I did it directly or on getGlobalSiteManager(). | 20:21 |
| jelmer | poolie: it looks like ~canonical-bazaar is admin for ~vcs-imports, so we should be able to add another member :-) | 20:22 |
| dobey | and it doesn't help that i can't just configure a new import if someone else already owns a branch which i would like to set up as an import in the proper place | 20:22 |
| gary_poster | dobey, it's certainly true that we don't have experts on that code any more. :-/ | 20:22 |
| jelmer | poolie: I wonder if we should make package imports and code imports more similar in this regard. code imports would benefit from out-of-date warnings as well. | 20:22 |
| dobey | so i guess even if i was on that team, i am not sure i would be able to fix this specific import | 20:22 |
| gary_poster | abentley: the API on the site manager is similar, but as I said, the site manager has adapter registries on it | 20:23 |
| gary_poster | that API is different | 20:23 |
| gary_poster | (the API of the adapter registries) | 20:23 |
| jelmer | dobey: the main disadvantage of being in ~vcs-imports is that you get a dozen extra emails per day, with some spikes | 20:23 |
| jelmer | dobey: what's the import? | 20:23 |
| dobey | https://code.launchpad.net/glib | 20:24 |
| dobey | jelmer: lp:glib, but it looks like someone set up an lp:glib/2.26 pointing at the git master | 20:24 |
| dobey | which is really annoying, because git master is not 2.26 | 20:24 |
| dobey | and the series are all messed up on that project | 20:24 |
| dobey | and other projects seem to have some imports set up, but don't have the series bits set up, so lp:foo doesn't work on them | 20:25 |
| jelmer | dobey: ~vcs-imports won't really help for that, vcs import admins can only really change the source URL of code imports and remove them | 20:26 |
| jelmer | dobey: ~registry can change a large set of projects that aren't hosted on Launchpad, including glib | 20:26 |
| rick_h_ | abentley: ping | 20:29 |
| abentley | rick_h_: pong | 20:29 |
| dobey | hmm | 20:29 |
| rick_h_ | abentley: know you're busy, but wanted to see if you get a sec if you could try out my branch with the indicator js plugin for the loading graphic? | 20:30 |
| abentley | rick_h_: sure, where is it? | 20:30 |
| rick_h_ | abentley: it works here, but it feels fragile with css and curious if it's what was intended from the discussions | 20:31 |
| rick_h_ | https://code.launchpad.net/~rharding/launchpad/buglists-loading-885272 | 20:31 |
| rick_h_ | abentley: I had to update the css combine template | 20:31 |
| rick_h_ | so make sure you regen that or add in the indicator assets css file | 20:31 |
| rick_h_ | I'm not 100% sure how that gets "updated" for people | 20:31 |
| dobey | jelmer: and i have a feeling ~registry is not a team i can be in :) | 20:32 |
| jelmer | dobey: so, in general, it seems like we are a bit too strict on who can change products that aren't hosted on Launchpad but merely tracked | 20:32 |
| jelmer | s/on/about/ | 20:32 |
| dobey | right | 20:32 |
| dobey | it seems there are a lot of defunct teams set up to deal with these, too | 20:33 |
| jelmer | dobey: I think it's just ~registry :) | 20:33 |
| sinzui | dobey, any canonical employee can be in the team if they needs to manage the 1100 projects that other projects like Ubuntu rely on | 20:33 |
| dobey | https://launchpad.net/~gnome-python-maintainers is the "maintainer" for pygobject it seems, but the team has no administrator | 20:33 |
| jelmer | dobey: I do think you could probably be in ~registry but you should probably check with one of the launchpad folks. Curtis is particularly active in ~registry | 20:34 |
| sinzui | dobey, ~launchpad currently dominates membership, but a few years ago, it was Ubuntu staff | 20:34 |
| dobey | ah | 20:36 |
| sinzui | dobey, you are now a member of ~registry. You will see lots of edit icons on projects now | 20:36 |
| dobey | sinzui: oh, ok; thanks | 20:37 |
| abentley | rick_h_: the makefiles updates combo.css. yui3-overlayindicator is present for me. | 20:37 |
| dobey | is there any way to deal with the issue of having the same branch of git being imported by multiple people (or rather, that it can't be)? | 20:38 |
| rick_h_ | abentley: right, but combo.css is generated from bin/combine-css which I had to manually add a path to | 20:38 |
| rick_h_ | abentley: and combin-css comes from the buildout templates | 20:38 |
| abentley | rick_h_: bin/combine-css is also generated by the makefile, AIUI | 20:39 |
| jelmer | dobey: euhm, sortof | 20:39 |
| jelmer | dobey: launchpad's URL checking is pretty naive, so if there are multiple URLs for a repository they can each be registered | 20:39 |
| rick_h_ | abentley: ok, cool, sounds like you're good | 20:39 |
| === matsubara is now known as matsubara-afk | ||
| abentley | rick_h_: I'm not seeing the spinner in firefox, and chromium looks busted. | 20:43 |
| rick_h_ | abentley: any errors? I'm seeing them in both. | 20:44 |
| rick_h_ | abentley: this branch doesn't have the backport for the chrome bug | 20:44 |
| dobey | jelmer: hrmm | 20:44 |
| rick_h_ | so to view it I had to just manually change the html to disable the -disabled css | 20:44 |
| abentley | rick_h_: Uncaught TypeError: Cannot read property 'next' of undefined. | 20:45 |
| rick_h_ | abentley: right, that's the chrome issue from yesterday | 20:45 |
| rick_h_ | try to merge with devel I guess to correct that part | 20:45 |
| abentley | rick_h_: If you merge stable, that should go away. | 20:45 |
| rick_h_ | abentley: I just cheated and hand changed the css rule hiding the overlay | 20:45 |
| rick_h_ | abentley: right, just didn't do that today yet. Thanks | 20:46 |
| rick_h_ | abentley: the image is in the center of the overlay'd div | 20:46 |
| rick_h_ | so make sure to check for it in the center of the table | 20:46 |
| dobey | jelmer: i guess i also need to be a member of vcs-imports to be able to configure a branch as owned by vcs-imports? | 20:46 |
| dobey | jelmer: or should i just make ~registry the owner? | 20:48 |
| abentley | rick_h_: It should be visible from the top and the bottom, so if being vertically centred makes it hard to see, we probably shouldn't do that. | 20:48 |
| rick_h_ | abentley: ok, so the stuff that this was working on was creating a single div overlaying the updating content with the spinner | 20:49 |
| rick_h_ | abentley: we've got a larger spinner, 32px that's used with the grey'ing out of the content to show it's going | 20:49 |
| jelmer | dobey: ~registry is fine as a branch owner as well | 20:50 |
| dobey | ok | 20:50 |
| abentley | rick_h_: I don't know what the answer is. Maybe two spinners. | 20:52 |
| wgrant | rick_h_: Did you change the main spinner recently? | 20:52 |
| rick_h_ | wgrant: yes, I needed one that would work on a grey background | 20:52 |
| rick_h_ | wgrant: I guess Huw said to pick one until he got around to making one | 20:53 |
| wgrant | rick_h_: Aha | 20:53 |
| wgrant | Is it slightly larger than the old one? | 20:53 |
| rick_h_ | wgrant: we've got two versions now, a 16 and 32px versions of the same gui | 20:53 |
| rick_h_ | wgrant: shouldn't be, the px size is exact | 20:53 |
| wgrant | The old one was already too big (it caused the page to jump around), but this one seems larger. | 20:53 |
| wgrant | hmm. | 20:53 |
| rick_h_ | it might push to the edge of the px more than the last, but it's exactly at 16 like the old | 20:53 |
| rick_h_ | abentley: ok, does it show up for you though? | 20:54 |
| rick_h_ | abentley: I guess more "does it work" for you and then we can go after the asthetics some | 20:54 |
| abentley | rick_h_: Unclear. I merged stable and now I'm dealing with the aftermath. | 20:54 |
| rick_h_ | abentley: lol, ok. I'm running on juice with my mifi, so going to head to a coffee shop I think. | 20:55 |
| rick_h_ | abentley: so back online in a bit | 20:55 |
| abentley | rick_h_: cool. | 20:55 |
| dobey | sinzui: hrmm; i can't seem to change the development focus on glib. | 20:55 |
| sinzui | dobey, ~registry does not maintain it | 20:56 |
| sinzui | dobey, Robert Ancell is in ~upstream, and he is also in ~registry | 20:57 |
| dobey | right, ok | 20:57 |
| sinzui | dobey, ~jjardon can add you to the team | 20:58 |
| sinzui | dobey, we made him the maintainer of several gnome projects. He will happily add people who can help fix the series. | 20:59 |
| dobey | is "release url pattern" on a series a regex, or just a glob? | 21:01 |
| dobey | i guess a glob, otherwise .* could have different results i suspect | 21:05 |
| lifeless | its a glob | 21:07 |
| dobey | is there some way to specify a git branch to import now, rather than it implicitly always being master? | 21:16 |
| wgrant | Add ',branch=foo' to the end of the URL | 21:16 |
| dobey | ah ok | 21:18 |
| rick_h_ | bah, coffee shops need more than 6 tables. Walk out there and no space | 21:22 |
| dobey | hrmm, imports failing | 21:24 |
| dobey | http://launchpadlibrarian.net/86214321/registry-glib-trunk.log | 21:24 |
| jelmer | dobey: the URL is incorrect, the /git/ bit shouldn't be there for git.gnome.org IIRC | 21:24 |
| dobey | jelmer: oh, hrmm; it's there for the git+ssh versions | 21:25 |
| jelmer | the standard git server doesn't error out when a repo doesn't exist, it just hangs up, hence that error message | 21:25 |
| jelmer | yeah, git://git.gnome.org/glib.git seems to work, git://git.gnome.org/git/glib.git doesn't | 21:25 |
| dobey | jelmer: did you update the URLs somehow? i didn't see how to do it, so i just deleted the glib branch and recreated it, but i see the gobject-introspection ones are working now | 21:29 |
| jelmer | dobey: there should be a link down the page "Edit import source or review import" | 21:30 |
| jelmer | dobey: maybe you have to be in ~vcs-imports to see it | 21:30 |
| dobey | jelmer: i don't see those. | 21:31 |
| mwhudson | yeah, that's ~vcs-imports only i think | 21:32 |
| jelmer | dobey: I don't think it's a problem for us to add you to ~vcs-imports | 21:32 |
| abentley | rick_h_: So, it looks nice, and the grey overlay helps a lot. But it seems to activate only on the first load, in both Firefox and Chromium. | 21:32 |
| dobey | jelmer: ok :) | 21:32 |
| mwhudson | unless you are allergic to email :) | 21:32 |
| rick_h_ | abentley: ok, will look | 21:33 |
| dobey | mwhudson: i have procmail :) | 21:34 |
| mwhudson | dobey: lucky you get any email at all then! | 21:34 |
| * mwhudson doesn't trust procmail | 21:35 | |
| mwhudson | well, my ability to drive it, really | 21:35 |
| dobey | mwhudson: well, i get the mail i care about :) | 21:35 |
| abentley | rick_h_: easiest way to trigger a load is probably the sort buttons. | 21:36 |
| rick_h_ | abentley: ok thanks. Yea it looks like the show/hide is triggered. Not sure if it's too fast or just not showing | 21:37 |
| rick_h_ | abentley: ah, nvm, I see it. Thanks for the heads up | 21:39 |
| abentley | rick_h_: np. | 21:39 |
| rick_h_ | abentley: ok, pushed fixes, the indicator spinner dom element was removed via the ajax response :) | 22:32 |
| rick_h_ | abentley: if you get a sec to see if that looks better for you, we can even but huwshimi and see if this is what we wanted and if I should try to land it | 22:32 |
| poolie | huwshimi, hi, i'd like to have a link to download a tarball of branch contents, within the main lp ui | 22:35 |
| poolie | can you help me work out where that ought to go (both which page and where on the page?) | 22:36 |
| huwshimi | poolie: Sure | 22:36 |
| poolie | there is a bug... | 22:36 |
| poolie | bug 897537 | 22:37 |
| _mup_ | Bug #897537: no link to download branch tarball within the main lp ui <branches> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/897537 > | 22:37 |
| poolie | huwshimi, so... | 22:39 |
| poolie | i can imagine this would lead in to a much larger redesign | 22:39 |
| poolie | perhaps without end | 22:39 |
| poolie | actually you know all this | 22:40 |
| poolie | do you want to talk about it now or just reply on the bug later? | 22:40 |
| huwshimi | poolie: Let's have a quick chat now | 22:40 |
| huwshimi | poolie: So this link is to download the source of any branch at any revision? | 22:41 |
| poolie | yes | 22:41 |
| poolie | with obviously an important special case being getting the source of the tip of the branch, and an important case of that being getting the tip of trunk | 22:42 |
| huwshimi | poolie: And can we only show links only on loggerhead or can we have them in our main ui as well? | 22:42 |
| poolie | perhaps, until lp has good main-webapp per-revision pages, we're better off focussing on just getting the tip, and people can click through to loggerhead to get past revisions | 22:42 |
| poolie | not quite sure what you mean | 22:43 |
| poolie | the point of the bug is that we ought to show them in the main ui | 22:43 |
| poolie | the urls are predictable so the main ui can just make them up | 22:43 |
| huwshimi | poolie: Right, I'm just checking we can actually do that | 22:43 |
| huwshimi | ah awesome :) | 22:43 |
| poolie | i think :) | 22:43 |
| huwshimi | hehe | 22:43 |
| huwshimi | So I imagine it would be useful to display a "download the source" link for on https://code.launchpad.net/loggerhead and https://launchpad.net/loggerhead/+download and https://code.launchpad.net/~debian-bazaar/loggerhead/experimental | 22:45 |
| huwshimi | And probably http://bazaar.launchpad.net/~debian-bazaar/loggerhead/experimental/files | 22:46 |
| poolie | yep | 22:46 |
| poolie | that last one, bazaar.l.n is loggerhead, so that's a separate issue | 22:46 |
| poolie | specifically bug 897535 | 22:47 |
| _mup_ | Bug #897535: tarball download link only appears on per-revision page <loggerhead:Triaged> < https://launchpad.net/bugs/897535 > | 22:47 |
| huwshimi | yeah | 22:47 |
| huwshimi | I would be a little hesitant to put source download links on project overview pages (https://launchpad.net/loggerhead). Mostly as it might create confusion as to how to get the code properly (most of the time we don't want people to just download the code, we want them to grab a bzr branch). | 22:48 |
| poolie | yep | 22:48 |
| poolie | <https://code.launchpad.net/~debian-bazaar/loggerhead/experimental> is already a bit "omg what do i do now" | 22:49 |
| poolie | :/ | 22:49 |
| poolie | perhaps part of the problem there is that the headings are not very visually distinct? | 22:49 |
| poolie | the font is barely any larger and the whitespace is not helping | 22:49 |
| huwshimi | actually now that I think about it if we add a get the source link on https://launchpad.net/loggerhead/+download it should probably be a link to https://code.launchpad.net/loggerhead so people can decide whether they want a branch or a tar ball | 22:49 |
| poolie | yes | 22:50 |
| poolie | https://code.launchpad.net/loggerhead has a link back | 22:50 |
| poolie | i think both of them should try to say "or perhaps you want a branch/a tarball instead" | 22:50 |
| poolie | it is worthwihle i suppose | 22:52 |
| poolie | it feels a bit like a kludge for people ending up on the wrong page :) | 22:52 |
| poolie | but i suppose it's natural people will go to a 'wrong' page that as they explore | 22:53 |
| huwshimi | I'd be inclined to be fairly specific with the wording too. On a branch page I would write: | 22:56 |
| huwshimi | Get this branch: | 22:56 |
| huwshimi | bzr branch lp:~debian-bazaar/loggerhead/experimental | 22:56 |
| huwshimi | or download .tar.gz | 22:56 |
| huwshimi | or something along those lines | 22:56 |
| poolie | yeah | 22:57 |
| poolie | so | 22:57 |
| poolie | often, people should either get an actual release tarball, or they should get a proper branch | 22:57 |
| poolie | but if they do want a tarball, it ought to be possible to find how to do that | 22:57 |
| poolie | so +download links to the branch list | 22:58 |
| poolie | the branch page offers you a tarball with the wording you gave above | 22:58 |
| poolie | and... should the list-of-branches page do anything? | 22:58 |
| huwshimi | Do you mean this page: https://code.launchpad.net/bzr ? | 22:59 |
| huwshimi | If so I would think it would be useful to have a .tar.gz link on that page too. I imagine some people will be using branches to host content that people would want to get at without using bzr (if it was a js library or some design files etc.) | 23:00 |
| huwshimi | The wording would be a bit trickier as there is already "There are download files available for Bazaar." | 23:01 |
| poolie | so as a special case, it offers you a tarball of the development focus? | 23:02 |
| poolie | wfm | 23:02 |
| poolie | the text on that page is an interesting case | 23:02 |
| poolie | the freeform text above the table | 23:02 |
| poolie | because it mixes together | 23:02 |
| poolie | stats | 23:02 |
| poolie | things you're supposed to take action on, if you're a developer | 23:02 |
| poolie | "perhaps instead you want... download files" | 23:03 |
| huwshimi | poolie: Yeah, we already have the special case of "bzr branch lp:bzr" so this would fit with the download of the same branch | 23:03 |
| poolie | instructions, and navigation | 23:03 |
| huwshimi | poolie: I know I was just trying to decipher everything going on there | 23:03 |
| poolie | so i think it all blurs together | 23:04 |
| poolie | :/ | 23:05 |
| poolie | perhaps we should just delete/hide the stats | 23:05 |
| huwshimi | Active reviews probably should be a link in the sidebar. It is a "related content" link | 23:06 |
| abentley | rick_h_: sorry, EOD. Let's chat about it tomorrow. | 23:06 |
| lifeless | poolie: I'm consdering coming to the xmas part | 23:06 |
| abentley | rick_h_: (End Of Day) | 23:06 |
| rick_h_ | abentley: sure thing, I'll send an email in case huwshimi gets any time to look at it UI wise | 23:06 |
| poolie | lifeless, awesome | 23:06 |
| lifeless | poolie: wondering about couch camping or something | 23:10 |
| poolie | i will ask | 23:10 |
| poolie | lifeless, you're welcome to | 23:12 |
| poolie | stay here | 23:12 |
| poolie | no warranty as to comfort :} | 23:12 |
| StevenK | lifeless: Sarah and I can probably find somewhere for you too, if you wish | 23:12 |
| rick_h_ | huwshimi: email on the way, if you get a sec to check it out. I'll be in/out online tonight so feel free to ping in irc if you want to chat | 23:12 |
| rick_h_ | huwshimi: and I'll catch you when I get back (going to hit dinner and such in a bit) | 23:13 |
| huwshimi | rick_h_: Cheers, will do. | 23:13 |
| poolie | huwshimi, ok this sounds like a plan: on the branch list page | 23:13 |
| poolie | get rid of the counters | 23:14 |
| poolie | active reviews and download files into the portlets | 23:14 |
| poolie | ... | 23:14 |
| poolie | can we get rid of the first sentence? | 23:14 |
| poolie | maybe.... | 23:15 |
| poolie | add 'browse', 'tarball' links to each row? | 23:15 |
| poolie | or | 23:16 |
| huwshimi | poolie: It might be nice to make the format of that first sentence like it is on a branch page, with a few wording changes to make it clear this is just the dev focus | 23:16 |
| poolie | maybe add tarball items only for series branches? | 23:16 |
| huwshimi | "get a copy of the branch using the command" is a nice way to put it, but maybe a little redundant | 23:18 |
| poolie | huwshimi, ok that sounds like a plan | 23:22 |
| poolie | anything else? | 23:22 |
| huwshimi | poolie: I think that all sounds pretty good | 23:23 |
| lifeless | flacoste: around ? | 23:27 |
| lifeless | flacoste: quick question if so | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!