[10:59] <SteveA> goedemorgen
[12:00] <ddaa> Good morning gentlemans and gentlemans
[12:00] <ddaa> or gentlemen
[12:00] <spiv> Good evening.
[12:00] <ddaa> well, not ladies in any case
[12:01] <ddaa> Da Sydney crew appears to be away
[12:01] <ddaa> ha
[12:01] <poolie> hullo
[12:02] <_thumper_> speak of the devil
[12:02] <ddaa> okay, all required attendance now present
[12:02] <poolie> it's just the pointy hair :)
[12:02] <ddaa> hair?
[12:02] <ddaa> == Agenda ==
[12:02] <ddaa> Next meeting Monday 23 October 1000 UTC - 1045 UTC.
[12:02] <ddaa>  * roll call
[12:02] <ddaa>  * production status
[12:02] <ddaa>  * 1.0 targets
[12:02] <ddaa>  * release finder
[12:02] <ddaa>  * Python import
[12:02] <ddaa>  * Debian svn server load
[12:02] <ddaa>  * Cscvs and pyrex
[12:02] <ddaa>  * Sprint report
[12:02] <ddaa>  * SpecBranch status
[12:02] <ddaa>  * bzr-lp features
[12:02] <ddaa>  * forwarding bzr list emails
[12:02] <ddaa>  * advertising
[12:02] <ddaa>  * highlighted bugs
[12:02] <ddaa>  * any other business
[12:02] <ddaa> If you wish to change the time of the meeting or add/remove agenda items, say "bzzzt!".
[12:02] <ddaa> If we are short on time, the "any other business" item will be automatically, dropped. So if you ''want'' to discuss something more, speak up now.
[12:03] <poolie> add: 'agenda items for singapore', if that's not covered by 'bzr-lp features'
[12:03] <ddaa> == Roll call ==
[12:03] <ddaa> Sorry for missing the meeting last week without warning. 
[12:03] <ddaa> No excuse was given for this week.
[12:03] <_thumper_> here
[12:03] <poolie> here
[12:03] <ddaa> poolie: well, basically bzr-lp features is your soap-box, so it's okay
[12:03] <poolie> ok
[12:04] <spiv> here
[12:04] <SteveA> hi
[12:04] <ddaa> jamesh: hello?
[12:05] <ddaa> jamesh appears missing
[12:05] <poolie> moving on...
[12:05] <ddaa> == Prodution status ==
[12:05] <ddaa> Nothing new to report on production, as far as I know. Did anybody has something to report from last week?
[12:05] <jamesh> ddaa: here
[12:05] <SteveA> the only issue is the debian server load, which there is an item for later
[12:06] <poolie> next...
[12:06] <jamesh> ddaa: stub said he'd be doing a rollout this week, which will put the $productseries/+source form improvements live
[12:06] <jamesh> and have everything in place to run product-release-finder in production
[12:06] <jamesh> (finally)
[12:06] <poolie> jamesh: what will that do?
[12:06] <poolie> i mean, what will be seen under /+source
[12:06] <_thumper_> jamesh: could you point me to the changes?
[12:06] <ddaa> jamesh: offtopic, but good news
[12:07] <_thumper_> later is fine
[12:07] <ddaa> jamesh: please pay attention to the agenda
[12:07] <ddaa> == 1.0 targets ==
[12:07] <ddaa> supermirror-smart-server: spiv: delivery status? New estimated delivery date? What was done recently, what will be done next?
[12:07] <ddaa> importd-bzr-native: was marked as delivered, further cleanups (removing baz deps completely from Launchpad) was deemed out of scope for this spec.
[12:07] <ddaa> bzr-roundtrip-svn: not for 1.0
[12:07] <ddaa>  * mpool: read up/tick off svn roundtripping discussion
[12:07] <jamesh> ddaa: I thought a production rollout would be related to that agenda item
[12:08] <ddaa> jamesh: mh, okay, will clarify. It's about reporting issues with the production systems. There are normally specific agenda items to mention rollouts.
[12:08] <ddaa> spiv: how the smart server going those days
[12:08] <spiv> ddaa: I'm still working on the HTTP smart server -- the code is basically written, but there are some issues raised in reviews that need to be addressed before it can be merged to bzr.dev.
[12:09] <SteveA> meta note: it may be a more efficient meeting (less overhead) to have fewer items each with a wider scope
[12:09] <_thumper_> SteveA: agreed
[12:09] <ddaa> spiv: what's next, and what's the current ETA for deployment if any?
[12:09] <poolie> ddaa: no comments from me on bzr-svn roundstripping
[12:10] <spiv> This work includes a WSGI application, and documentation showing how to run it with FastCGI in Apache.
[12:10] <_thumper_> smart server for devpad?
[12:10] <ddaa> poolie: need more information ato find the threads discussing that?
[12:10] <poolie> ddaa: is it "mutating history in subversion and bazaar"?
[12:10] <spiv> For the supermirror, the only missing piece is translating the public URLs to the database-id directories on disk.
[12:10] <poolie> if there's something in particular you want my input on, forward it to me
[12:10] <ddaa> poolie: that and one or two other threads started at about the same time
[12:11] <SteveA> fastcgi?
[12:11] <spiv> But that should be very easy to hook in.
[12:11] <SteveA> is that the one with the funny licence?
[12:11] <SteveA> if so, the sysadmins don't like running it
[12:11] <spiv> Hmm.
[12:11] <ddaa> poolie: I guess I should summarise them and start new threads then
[12:11] <SteveA> spiv: check with the admins what cgi flavours they prefer
[12:11] <spiv> Well, maybe I can look into to WSGI + mod_python or something instead.
[12:12] <spiv> In theory, WSGI means I don't have to care too much... ah, theories :)
[12:12] <spiv> SteveA: will do.  Thanks for the heads up.
[12:12] <ddaa> spiv: before I get asked again, it would be nice of you to update the spec page on Launchpad, and maybe give an ETA
[12:13] <SteveA> please keep the spec implementation status + whiteboard up to date
[12:13] <spiv> I'll recheck the spec metadata... it looked accurate last time I checked about a week ago.
[12:13] <SteveA> it really helps with planning for 1.0, and also to cope with the distributed nature of our development
[12:13] <poolie> ddaa: i'll read it now and send you mail
[12:13] <spiv> (the spec itself is in need of a lot of effort to bring it up to date with reality though :(  )
[12:13] <SteveA> the whiteboard is a good place to put explanation about what is needed still in implementation or deployment
[12:14] <ddaa> that's fine, the spec is irrelevant now that there's code
[12:14] <spiv> Ok, I'll pay particular attention to the whiteboard.
[12:14] <ddaa> moving on
[12:14] <ddaa> poolie: thanks
[12:14] <ddaa> == Product release finder ==
[12:14] <ddaa>  * jamesh: report on PRF progress. Was complete and pending review two weeks ago.
[12:15] <jamesh> was merged, and the revision stub is rolling out contains the last round of fixes
[12:15] <ddaa> Since then, jamesh basically rewrote all of the $series/+source web ui
[12:15] <jamesh> so we should be able to run it in production this week
[12:15] <ddaa> Okay, I take you'll be in charge of babysitting the cronscript/daemon whatever
[12:15] <SteveA> that's great.  I'm looking forward to seeing an improved +source page
[12:16] <jamesh> SteveA: you can see it on staging right now
[12:16] <ddaa> this a new production subsystem, so we'll need to clarify ownership
[12:16] <ddaa> jamesh: TTY and SteveA about that later this week,
[12:17] <ddaa> == Python import ==
[12:17] <ddaa>  * ddaa: status of Python blocker cscvs bug
[12:17] <ddaa>  * jamesh: bzr-0.11 rocketfuel landing
[12:17] <ddaa> python: the new cscvs logic was done before the sprint. Currently pending review. This week, will test to confirm that it fixes the python import (continuing from last failure point).
[12:17] <ddaa> bzr-0.11: was fully landed (launchpad, cscvs, bzr, removal of bzrtools) in the past couple of weeks.
[12:17] <ddaa> jamesh: is that correct?
[12:17] <jamesh> yep
[12:17] <jamesh> I removed bzrtools and gnarly from the dists config too
[12:18] <ddaa> hello Rob, you're late
[12:18] <poolie> ddaa: his attendence is optional
[12:18] <poolie> so don't be snarky, if you were
[12:18] <ddaa> I know
[12:18] <ddaa> I do not even know what this word means
[12:18] <poolie> nevermind
[12:18] <_thumper_> next...
[12:18] <ddaa> but sorry for offending people
[12:19] <ddaa> I cannot help it you know, I'm french ;)
[12:19] <ddaa> == Debian svn server load ==
[12:19] <ddaa> Mithrandir (Tollef Fog Heen) reports that Wichert Akkerman is unhappy about the svn.debian.org load coming from russkaya (one of the importd-autotest slaves).
[12:19] <ddaa> > 1gb of traffic in a day is insane if the normal load is 30mb
[12:19] <ddaa> I do not see off-hand what would have caused that since I did not touch importd recently (meaning autotest should not have done anything in the past couple of weeks at least) and most of our debian imports are now in production (on neumayer or galapagos).
[12:19] <ddaa> Some stats:
[12:19] <ddaa> https://devpad.canonical.com/~andrew/paste/file996I60.html
[12:19] <_thumper_> rogue process?
[12:20] <_thumper_> something not killed properly?
[12:20] <ddaa> unlikely to cause load on remote servers
[12:20] <ddaa> but worth checking
[12:20] <_thumper_> could if the process was in a loop downloading stuff
[12:20] <ddaa> this sort of loop never happened
[12:20] <poolie> ddaa: so what are we going to do now?
[12:20] <lifeless> did I miss anything I should care about ?
[12:20] <poolie> ddaa: is there no log of what's retrieved?
[12:21] <poolie> lifeless: not really
[12:21] <poolie> would be interested to hear from you about the debian svn server load thing though
[12:21] <jamesh> would their access logs give some indication of what was being hit?
[12:21] <poolie> jamesh: possibly, but i don't think svn normally logs requests
[12:21] <ddaa> poolie: nope, no log of network activity. But I can narrow down what buildbot knows it has run on russkaya recently from those imports
[12:22] <poolie> however, from their point of view the problem is solved: they firewalled us
[12:22] <jamesh> poolie: ah.  it is going through svn:// so they wouldn't get apache access logs.
[12:22] <poolie> it is *our* obligation not to do this
[12:22] <ddaa> what's weird, is that they never complained before
[12:22] <lifeless> one possibility is a single freakingly big import
[12:22] <_thumper_> maybe they just noticed
[12:22] <ddaa> and now they do it, although there should be now load at all from russkaya recently
[12:22] <lifeless> i.e.
[12:23] <lifeless> 'please give me all the branches of x.org'
[12:23] <lifeless> which is gb's of data
[12:23] <poolie> ddaa: it seems to me that we should log what we crawl...
[12:23] <ddaa> https://devpad.canonical.com/~andrew/paste/file996I60.html
[12:23] <ddaa> lifeless: no such thing in the autotest stuff afaict
[12:23] <_thumper_> gee, the linux kernel is big isn't it?
[12:23] <poolie> ddaa: yes you keep posting that url but what are we supposed to infer from it?
[12:24] <jamesh> svn://svn.debian.org/devscripts <- that'll get every branch and tag
[12:24] <jamesh> similar for svn://svn.debian.org/debconf
[12:24] <lifeless> yup
[12:24] <ddaa> jamesh: thank you
[12:24] <lifeless> thats what I was thinking of
[12:24] <lifeless> that sort of thing
[12:24] <ddaa> poolie: supposed to find the error, what jamesh just did
[12:25] <ddaa> the pb is that we do what our users tell us
[12:25] <poolie> ddaa: so the importer doesn't detect the common ancestry between the tags?
[12:25] <ddaa> no way around that...
[12:25] <spiv> It seems like a difficult way to find the error, though.  Is there a query that can tell us what the recent activity is?
[12:25] <ddaa> tags?
[12:25] <poolie> it gets them all?
[12:25] <ddaa> ancestry?
[12:25] <ddaa> poolie: you are assuming that svn is meaningful about tags... it is not
[12:25] <poolie> it doesn't expose the CoW data at all?
[12:25] <jamesh> poolie: there is no way (other than convention) to tell if a URL is for a branch or the entire repository
[12:25] <_thumper_> a tag is svn is just a branch
[12:26] <poolie> jamesh, tim: yes, i know
[12:26] <ddaa> let's move on, poolie we can discuss how svn is shit later
[12:26] <lifeless> _thumper_: a tag is not a branch, thats the problem :(
[12:26] <ddaa> jamesh: thanks for the sharp eye, that will help
[12:26] <lifeless> _thumper_: its a copy is all
[12:26] <spiv> Well, it seems that we probably want to at least warn if someone attempts to import an SVN directory with "trunk", "branches" and "tags" subdirectories.
[12:26] <spiv> Because almost certainly that's not going to do what they want.
[12:26] <ddaa> spiv: we've got no useful warning system
[12:26] <poolie> spiv: that would probably solve most of the cases
[12:26] <ddaa> but that's a good point otherwise
[12:27] <poolie> ddaa: do you seriously mean if i enter the base url of a repo it will pull everything, similarly to checking out the whole thing?
[12:27] <ddaa> let's follow-up on mailing list, there are good ideas flying around
[12:27] <spiv> If warning isn't an option, I'd settle for "refuse to do it all".
[12:27] <spiv> s/all/at all/
[12:27] <jamesh> spiv: or warn if the URL they enter doesn't contain a segment named "trunk", "branches" or "tags"
[12:27] <ddaa> poolie: there's an bug that prevents it, but svn does not allow us to figure out if it's a error or not
[12:28] <lifeless> poolie: yes, because we cant tell the difference reliably
[12:28] <spiv> jamesh: that's a good idea
[12:28] <lifeless> poolie: same as ddoing a svn checkout of the base
[12:28] <jamesh> maybe even error out
[12:28] <poolie> lifeless: wow
[12:28] <poolie> ok
[12:28] <ddaa> GUYS -> MAILING LIST
[12:28] <ddaa> == Cscvs and pyrex == 
[12:28] <ddaa> SteveA said: for pyrex, say what you've done so far, what benefit it's had, what would need doing if this became "official"
[12:29] <ddaa> sorry had no time to prepare a paste
[12:29] <ddaa> I have an experimental branch,
[12:29] <ddaa> that implements libsvn bindings for cscvs using pyrex
[12:29] <ddaa> to replace python-subversion and pysvn
[12:30] <ddaa> So far, done almost all that's needed by the Repository and WorkingTree classes
[12:30] <ddaa> that does not include the critical code paths for the import process
[12:30] <SteveA> (on hammering servers, I wonder if we can pipe our svn connections through some kind of per host accounting, so at least we know how much we're hammering different hosts, and maybe give it a limit, at the network layer)
[12:31] <SteveA> (if there's something off-the-shelf for this, would be nice)
[12:31] <ddaa> benefit: saner code, single entry point into libsvn, fixing memory leaks, removing bug in import functionality (used for tests)
[12:31] <spiv> SteveA: (perhaps trickled?)
[12:31] <ddaa> other planned benefit: good API use to reduce server load
[12:32] <ddaa> like turning three session for every file change into a single query
[12:32] <ddaa> and n such queries by session
[12:32] <SteveA> I want feedback / review from someone here as to whether ddaa's work is in an appropriate direction for our mainline
[12:32] <SteveA> considering the cost to change over, and to maintain this long term
[12:32] <SteveA> any volunteers?
[12:32] <ddaa> will upload shortly and put as work-in-progress on pendingreviews
[12:33] <SteveA> existing familiarity with pyrex a bonus :-)
[12:33] <poolie> ddaa: i know some of the libsvn bindings actually don't expose all the interesting functions
[12:33] <poolie> is that a goal of this too?
[12:33] <poolie> or can you reach all of them from one of the existing wrappers?
[12:33] <ddaa> poolie: libsvn swig bindings are broken and crippled
[12:34] <ddaa> the goal of the pyrex stuff is to be functional but strictly limited in scope to what cscvs needs
[12:34] <jamesh> poolie: I think the aim is a specialised binding
[12:34] <ddaa> the advantage is ability to talk to the C library directly
[12:35] <ddaa> okay, moving on, now that everybody is aware of the stuff
[12:35] <SteveA> well
[12:35] <ddaa> note: it's just a personal experiment at this point
[12:35] <SteveA> I'm still looking for a volunteer to look over what you've done
[12:36] <ddaa> I do not see any.
[12:36] <SteveA> _thumper_: interested?
[12:36] <jamesh> I guess I can take a look at it -- I've done a bit of cscvs and Subversion stuff
[12:36] <_thumper_> SteveA, could do, but no experience with pyrex or familiarity with the other libs
[12:36] <jamesh> unless _thumper_ wants to
[12:36] <_thumper_> but could give it a go
[12:37] <ddaa> I think jamesh would be better for the time being
[12:37] <_thumper_> jamesh: how about you a first on this, and I'll look over it too
[12:37] <jamesh> _thumper_: sounds good
[12:37] <ddaa> as _thumper_ is going to be away for a while soon
[12:37] <SteveA> ok, thanks
[12:38] <ddaa> okay, jamesh, you are volunteered :)
[12:38] <ddaa> == Sprint report ==
[12:38] <ddaa> _thumper_: care to do it?
[12:38] <_thumper_> could do
[12:38] <_thumper_> early in the week it was more getting familiarity with the moving parts
[12:38] <_thumper_> around bazaar integration with launchpad
[12:39] <_thumper_> big picture stuff#
[12:39] <_thumper_> started looking at specs and branches
[12:39] <_thumper_> a few small bug fixes were put up for review
[12:39] <ddaa> (note: progress report on spec-branch is next agenda item)
[12:39] <_thumper_> didn't get anything on to pqm last week, but should do over the next day or two
[12:40] <_thumper_> it was good to get to meet SteveA and ddaa in person for a significant duration
[12:40] <SteveA> _thumper_: feel free to submit a trivial "whitespace / docstring only" change to check pqm is working
[12:40] <_thumper_> rather than just interview
[12:40] <lifeless> _thumper_: update your branch 
[12:40] <lifeless> _thumper_: your merge request is broken, you need to change the /home/warthogs/archives/ to /code/
[12:41] <_thumper_> I'm more comfortable now with the general codebase and approach
[12:41] <_thumper_> lifeless: ok
[12:41] <_thumper_> that's pretty much it
[12:41] <ddaa> so, it looks like the sprint was a success
[12:41] <_thumper_> oh, one other thing
[12:41] <_thumper_> created an informational spec for launchpad-bazaar called science fiction
[12:42] <_thumper_> talked through with mark on the weekend and he liked it
[12:42] <SteveA> nice
[12:42] <_thumper_> others should read
[12:42] <SteveA> URL please
[12:42] <ddaa> https://features.launchpad.net/products/launchpad-bazaar/+spec/science-fiction
[12:42] <_thumper_> beaten to it
[12:43] <ddaa> Thank you.
[12:43] <_thumper_> although mark suggested a menu item under Help (download this code)
[12:43] <ddaa> The help menu is going to look like the lp action menu before we had facets
[12:44] <ddaa> But let the ubuntu guys deal with the sanity of this.
[12:44] <ddaa> == SpecBranch status ==
[12:44] <ddaa> So, last week _thumper_ started implementing linking of specs and branches
[12:44] <_thumper_> poolie suggested a text relation for a branch so could briefly say what the branch is for
[12:44] <_thumper_> expecially when linking multiple branches to a spec
[12:45] <_thumper_> has merit I think
[12:45] <ddaa> Plain-text, good.
[12:45] <ddaa> We can be more descriptive later when usage patterns emerge.
[12:45] <_thumper_> so, database table done, pending update
[12:45] <_thumper_> interface classes and content object done
[12:45] <_thumper_> just some page stuff now
[12:45] <_thumper_> my work for this week
[12:46] <SteveA> tests?
[12:46] <poolie> tim will be in sgp next week, and away on hiatus after that
[12:46] <_thumper_> SteveA, yes we need tests
[12:46] <_thumper_> back for work first Monday in Dec
[12:47] <ddaa> lifeless: please indoctrinate thumper into TDD at the first opportunity :)
[12:47] <SteveA> the tests may be written before the code.  I'm keen on seeing people try out writing page tests using testbrowser as acceptance tests of the whole UI
[12:47] <SteveA> before the code is written
[12:47] <SteveA> I think this may be feasible, and valuable
[12:47] <ddaa> SteveA++
[12:48] <_thumper_> agreed
[12:48] <SteveA> but also, everyone should be familiar with the TDD finer-grained approach to modifying tests before writing code.
[12:48] <jamesh> I just reported https://launchpad.net/products/launchpad-bazaar/+bug/66383 about catching Subversion URIs that probably cover more than one branch
[12:48] <SteveA> cacheing?
[12:48] <SteveA> or catching?
[12:48] <jamesh> (from previous discussion)
[12:49] <spiv> catching, I assume.
[12:49] <jamesh> SteveA: catching
[12:49] <ddaa> catching
[12:49] <SteveA> thanks
[12:49] <poolie> i'm writing a summary to the list
[12:49] <SteveA> jamesh: very clear bug report.  thanks.
[12:50] <poolie> should that bug be marked security-related?
[12:50] <poolie> since there is potential for mischief
[12:50] <SteveA> I guess.  We're offering the world the ability to DOS svn server
[12:50] <SteveA> s
[12:50] <ddaa> poolie: makes sense
[12:50] <poolie> can end users add branch urls through the web site without canonical intervention?
[12:50] <SteveA> certainly critical
[12:50] <jamesh> poolie: yes
[12:50] <poolie> jamesh: make it so! :)
[12:51] <SteveA> poolie: as senior representative of the importd infrastructure, would you lead the diplomacy on this one?
[12:51] <poolie> SteveA: yes
[12:52] <SteveA> we've been rather rude to debian (in a technical sense), and because of that, and also because they're debian, they're due a nice response
[12:52] <SteveA> thanks poolie 
[12:52] <poolie> yes, i know
[12:52] <poolie> i think we should work out what happened and what we're going to do, and then tell them
[12:52] <ddaa> == bzr-lp features ==
[12:52] <ddaa>  * mpool: report on bzr-lp features
[12:52] <ddaa> Redirection from .bzr below launchpad web page was cherrypicked in production. I think I saw jamesh blog about it, but did not update https://help.launchpad.net/BazaarLinks.
[12:52] <ddaa> That means that efficient http redirect handling is no longer
[12:52] <ddaa> needed for Launcphad.
[12:53] <ddaa> poolie: talk about singapore now
[12:53] <poolie> as we were supposed to do for account creation (but perhaps did not?)
[12:53] <ddaa> meeting will brutally cut off in 5 mins for reviewers meeting
[12:53] <poolie> tim, lifeless, stub, mbp, mark are meeting in sinagpore next week
[12:53] <poolie> to plan bzr lp features
[12:53] <poolie> if you have stuff you think is not getting the attention it should,
[12:53] <poolie> tell me before friday
[12:54] <poolie> ddaa: for example, you need to tell me more about cscvs if you want it to be on the agenda
[12:54] <poolie> that's all, next
[12:54] <ddaa> nothing essential left
[12:54] <ddaa> jamesh: please update BazaarLinks when blogging
[12:54] <jamesh> for what it is worth, serving branchreferences could could be used to prototype the lp:/// URI scheme
[12:54] <ddaa> so people like me and SteveA can find your good stuff easily when asked
[12:55] <ddaa> jamesh++
[12:55] <ddaa> Meeting closed then.
[12:55] <SteveA> this kind of linkage stuff could go on some bazaar homepage in launchpad too
[12:56] <ddaa> Reviewers, have a break before your next meeting.
[12:56] <SteveA> thanks for keeping the meeting on track ddaa
[12:59] <jamesh> ddaa: added the link for my article and spiv's one too
[12:59] <ddaa> jamesh: thank you
[01:10] <SteveA> ddaa, poolie: ping
[01:10] <poolie> still ehre
[01:10] <ddaa> pong
[01:11] <SteveA> ddaa: poolie and I were just talking about the "accidental DOS attack" thing
[01:11] <ddaa> ultimately, we either manually review everything, or allow users to break stuff
[01:11] <SteveA> I'd like it to be your top priority, fixing it and ensuring it can't happen again
[01:12] <SteveA> even if this means creating a few OOPSes or database constraint violations for a while
[01:12] <SteveA> I'd rather an import not work, or 20 imports not work
[01:12] <ddaa> though we can certainly reduce the opportunity for mistakes...
[01:12] <SteveA> than one upstream get hammered
[01:12] <SteveA> I think poolie agrees here
[01:13] <poolie> yes, i certainly do
[01:13] <SteveA> so, what's the plan?
[01:13] <poolie> i'm going to send mail now
[01:13] <poolie> ddaa: please reply and correct it :-)
[01:13] <poolie> and let's work out what we're going to do
[01:14] <ddaa> naming conventions vary so wildly that I do not think we can do anything reliable
[01:14] <poolie> ddaa: this is a fairly major problem, but we can also think of it as practice for more serious potential problems as we grow
[01:15] <ddaa> we can narrow the window a bit with heuristics, and give a knob to allow JFDI with admin action...
[01:15] <poolie> ddaa: JFDI on having some protection against this
[01:15] <ddaa> some protection yes
[01:15] <poolie> i'd like to, by the end of this week, be able to type those urls in, or something similar
[01:15] <poolie> and have it not clobber the server
[01:15] <poolie> do you think that's reasonable?
[01:16] <ddaa> Should be fairly easy to stick a failsafe into the system. We just need to come up with a heuristic that is actually useful.
[01:17] <ddaa> dunno, maybe something like "if it only contains dirs, or is at the top of the repo"
[01:18] <poolie> ddaa: can you do a query to find out how many urls do or don't have /trunk/ in their url?
[01:18] <poolie> i'd expect it's 99%
[01:19] <jamesh> if cscvs finds a directory in the SVN branch that contains a "trunk" subdir and at least one of "branches", "releases" or "tags" then something is probably wrong
[01:19] <ddaa> there are many projects out that that do
[01:19] <ddaa> 'trunk/product'
[01:19] <spiv> ddaa: but that's "ok"
[01:20] <spiv> ddaa: in that the probable error there is grabbing too little, rather than far too much.,
[01:20] <ddaa> where there can be dozens of products, kde for example does things like that
[01:20] <spiv> So while the import of "trunk/product" might not be correct, it at least isn't going to be a DoS.
[01:21] <jamesh> ddaa: I mean once we've accepted a SVN URI, check what's inside that tree.
[01:21] <ddaa> I'm saying that what jamesh propose will not figure out that importing "trunk" is wrong.
[01:21] <spiv> (incidentally, it's nice that this sort of problem just doesn't occur with bzr's model)
[01:21] <jamesh> ddaa: the idea is to catch the case where we are probably importing too much
[01:22] <ddaa> let's have this discussion on ML
[01:22] <spiv> ddaa: Oh, I see what you're saying, I misunderstood you to be referring to "trunk/product" inside the URL given to us.
[01:22] <ddaa> I'll do something, anything, this week, as it can be an improvement
[01:22] <ddaa> can only be an improvement
[01:23] <ddaa> but it's the sort of problem where there are completely wrong obvious solutions
[01:23] <ddaa> so ML is better for discussing it
[01:24] <poolie> ddaa: at least in that case we will only download all the products
[01:24] <poolie> which might be wrong, but at least will be only about as much data as getting them individually
[01:24] <ddaa> what I said about anything being an improvement
[01:25] <ddaa> would you _really_ want to accept importing this: http://websvn.kde.org/trunk/
[01:26] <ddaa> and it's only the most pathologic example I can come up with off hand
[01:26] <ddaa> and there are cases where importing the whole repo is actually the correct thing and what the user really means
[01:30] <poolie> ddaa: is importd down at the moment?
[01:30] <ddaa> nope
[01:30] <ddaa> but no worry
[01:30] <poolie> is it going to keep pulling those branches?
[01:31] <ddaa> nope
[01:31] <poolie> why not?
[01:31] <ddaa> they have testfailed, it takes explicit action to start them again
[01:31] <poolie> and why did they testfail?
[01:33] <ddaa> not obvious, for example devscript import has not run recently
[01:34] <ddaa> probably one of the various bugs that the new svn logic code is fixing
[01:35] <poolie> ddaa, can you please, today, look through and make sure that anything which may be in this class is disabled?
[01:35] <poolie> and also make sure that if someone tries to restart them it will not happen
[01:36] <ddaa> poolie: of 273 productseries with svnrepository set, 212 have trunk in it
[01:37] <ddaa> the only persons who has got the power to restart those imports are launchpad admins, lifeless and I.
[01:38] <ddaa> there's no need to take further action, just need to remember _not_ to ever use the "start all imports that match a regexp" functionality in the buildbot ui.
[01:38] <ddaa> and I'm the only one that's supposed to do this sort of shit anyway, because lifeless is way busy with other things
[01:38] <lifeless> yup
[01:39] <lifeless> I occasionally will run a single test
[01:39] <lifeless> for an interested project, but thats all
[01:39] <lifeless> and never put something into production, I consider ddaa authoritative for that
[01:39] <ddaa> so, if shit happens again it's either because I was dumb, or because it's new user input.
[01:40] <ddaa> or because a launchpad admin did something dumb
[01:42] <ddaa> https://devpad.canonical.com/~andrew/paste/fileOMOl9z.html
[01:42] <ddaa> poolie: ^ all svnrepos that do not have trunk in them
[01:42] <ddaa> importstatus = 3: testfailed
[01:43] <ddaa> imporstatus = 2: autotest (new user input, surprise, it's bogus! no way!)
[01:43] <ddaa> importstatus = 6: in production
[01:45] <ddaa> 2 of the 6 in production appears bogus in terms of not matching the intended use
[01:46] <ddaa> https://svn.sourceforge.net/svnroot/comix was a case where checking the full repo is actually the correct thing to do
[01:46] <ddaa> something to do with users not reading documentation and stuff like that
[01:47] <jamesh> if people have a weird setup, requring an admin to approve a test isn't a bad thing
[01:47] <ddaa> sure
[01:47] <ddaa> anyway, in those cases I just ask (politely) "fix your repo, dumbass"
[01:48] <ddaa> "you may actually have a use for branches one day. Yes branches in svn are just directories. No, you've got nowhere to put them until you fix the layout of your repo"
[01:48] <ddaa> more politely of course
[01:54] <jamesh> ddaa: they don't need to fix the layout of their repo -- just get Launchpad to import their repo and start using Bazaar instead
[02:02] <ddaa> I do not do combined sale
[02:03] <ddaa> if people ask for x, I do not try to force feed them y
[02:03] <ddaa> I guess I'll never make a career in sales
[02:58] <ddaa> mh... devscripts is owned by registry
[02:58] <ddaa> legacy from the oh-so-good-idea imports death march
[03:46] <_thumper_> ping ddaa
[03:46] <ddaa> _thumper_: pong
[03:47] <_thumper_> ./tests.py lib pagetests.branches doesn't run any tests
[03:47] <_thumper_> I get Total: 0 tests, ...
[03:47] <ddaa> mh
[03:47] <_thumper_> wtf?
[03:48] <_thumper_> do I need some pre-test make step?
[03:48] <ddaa> https://launchpad.canonical.com/LaunchpadHackingFAQ#head-b454516710233a7eee2eb4b44d7bc6e4a97e04a3
[03:48] <ddaa> i think there are two issues there
[03:48] <ddaa> one is that you said "lib" instead of "canonical"
[03:48] <ddaa> lib is not a python module
[03:48] <_thumper_> I was just doing what the README said
[03:48] <ddaa> the other is that pagetests are a bit spethial
[03:49] <ddaa> well, try doing what the wiki says and fix the readme...
[03:50] <ddaa> in-tree documentation tends to be even more outdated than wiki pages
[03:50] <_thumper_> ta
[03:51] <ddaa> I think this readme was not updated since we went to zope 3.2 (if that's what we're using now)
[03:51] <ddaa> during some zope upgrade the test.py usage changed in subtle ways
[04:53] <jamesh> _thumper_: re running page tests: the incantation I use is "./test.py -vv --test=pagetests/branches"
[04:53] <jamesh> _thumper_: I've got a branch that actually updates the pagetests/README.txt too ...
[04:58] <_thumper_> jamesh: thanks
[04:58] <_thumper_> does yours have a problem tearing down the db layer?
[04:58] <jamesh> haven't noticed a problem like that recently
[04:59] <_thumper_> hmm...
[04:59] <_thumper_> I've just been pleasently surprised by gnupg-agent
[05:00] <_thumper_> the only thing needed was to uncomment the # use-agent part of gpg.conf
[05:00] <jamesh> just use gnome-gpg :)
[05:00] <_thumper_> nah, kde person
[05:00] <jamesh> we'll have to fix that ...
[05:00] <_thumper_> I'm allergic to gnomes
[05:00] <_thumper_> gives me hives