| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad-meeting | ||
| === jamesh [n=james@203.59.208.48] has joined #launchpad-meeting | ||
| === spiv [n=andrew@218-214-66-203.people.net.au] has joined #launchpad-meeting | ||
| ddaa | Yeay | 10:05 |
|---|---|---|
| lifeless | poolie sends apologies | 10:05 |
| ddaa | Let's start | 10:06 |
| ddaa | MEETING STARTS | 10:06 |
| ddaa | sorry being late, just came back home, jetlag and stuff | 10:07 |
| ddaa | == Agenda == | 10:07 |
| ddaa | Next meeting Monday 4 December, 09:00-09:45 UTC. | 10:07 |
| ddaa | * production status | 10:07 |
| ddaa | * naming convention [SteveA] | 10:07 |
| ddaa | * status reports | 10:07 |
| ddaa | == Roll call == | 10:08 |
| ddaa | _thumper_ is on leave until start of December. | 10:08 |
| ddaa | lifeless says: poolie sends apologies | 10:08 |
| SteveA | morning | 10:08 |
| ddaa | jamesh: ping | 10:08 |
| ddaa | spiv: pin | 10:08 |
| jamesh | hi | 10:08 |
| === SteveA hands lifeless a pin to write new-zealandish with | ||
| === ddaa giggles | ||
| SteveA | the pin is mightier than the sword | 10:09 |
| spiv | I'm here. | 10:09 |
| ddaa | There was a kiwi woman at the hostel... I figured out that .nz people "spin time" :) | 10:09 |
| ddaa | okay 'vrybody in there | 10:10 |
| ddaa | == Production status == | 10:10 |
| ddaa | New rollouts or production problems. | 10:10 |
| SteveA | ddaa: there is a bar/restaurant place call Bazar just down the road from me | 10:10 |
| SteveA | http://www.specialnite.com/venues/location/the_pijp/bazar/ | 10:10 |
| ddaa | SteveA, the one you recommended to me for a stay in Rotterdam? | 10:11 |
| SteveA | on the subject of new rollouts, when can we expect the smartserver to run on the supermirror? | 10:11 |
| ddaa | So, anything of notice happened in the past two weeks or so in production? | 10:11 |
| SteveA | and also the viewcvs kinda stuff? | 10:11 |
| ddaa | Is there anything in production in need of firefighting? | 10:11 |
| lifeless | SteveA: so there is a wsgi module for it. AFAIK its just a matter of configuration now. | 10:12 |
| lifeless | spiv: is that right ? | 10:12 |
| spiv | lifeless: Partly ;) | 10:12 |
| lifeless | spiv: for the http side that is | 10:12 |
| spiv | lifeless: where "configuration" includes "make it work with the different directory layout on disk" | 10:13 |
| SteveA | I'd like us to have a meeting (not this one) to determine exactly what needs doing so that we can have the smartserver runing on the supermirror | 10:13 |
| SteveA | and who is going to do it and when | 10:13 |
| SteveA | right after this here meeting works for me | 10:13 |
| spiv | Which is possibly taken care of by the apache magic already, but I don't know exactly how that hooks together yet. | 10:13 |
| ddaa | spiv has review meeting just after this one AFAIK | 10:13 |
| SteveA | true. so do i | 10:14 |
| lifeless | spiv: if we can pass the path in to the vfs - the chroot transport should be all we need. just command line glue | 10:14 |
| spiv | Also, there's an issue that the admins don't like mod_fastcgi, so the magic to hook up WSGI with something else (probably mod_python) needs to be figured out. | 10:14 |
| lifeless | spiv: they dont ? | 10:14 |
| jamesh | they won't run fastcgi, but they'd run Bazaar code within apache? | 10:15 |
| spiv | lifeless: there's a non-free fastcgi thing for a apache, or a free one that sucks, apparently. | 10:15 |
| spiv | I spoke to elmo about it briefly at allhands. | 10:15 |
| lifeless | how badly does it suck? I mean, is it worth more dev time to reimplement something that exists.. | 10:15 |
| spiv | Well, there's lots of existing modules for connection WSGI to stuff, including, I believe, mod_python stuff, so it's not something we'd have to implement ourselves. | 10:16 |
| spiv | It's also likely we'll want mod_python on the supermirror eventually as a better way to do the URL rewriting that mod_rewrite + a huge periodic dump file from the database. | 10:17 |
| SteveA | or just run it as a twisted daemon? | 10:17 |
| jamesh | mod_python basically means allowing the code to do whatever apache can, which is why I was surprised the admins would prefer that | 10:17 |
| SteveA | jamesh: it's a freeness issue I think | 10:17 |
| ddaa | spiv: that sounds like a useful cleanup, but the mod_rewrite problem has not been a problem so far. It's stupid simple but robust. | 10:18 |
| ddaa | so I'd call that a low priority cleanup. | 10:18 |
| spiv | ddaa: right. "eventually" :) | 10:18 |
| SteveA | ok. I'm getting confused. I want to explain what I want out of this. | 10:18 |
| SteveA | What I want is a set of numbered list items on a wiki page that lays out all the steps from where we are now, to having the supermirror running the smartserver. If there are parts that need investigation then that item says | 10:19 |
| SteveA | "investigate [foo] to determine whether [bar] " | 10:19 |
| SteveA | spiv: I'd like you to be responsible for writing this | 10:20 |
| spiv | SteveA: ok. | 10:20 |
| spiv | I think that's a good idea. | 10:20 |
| ddaa | spiv: today after review meeting might be late for you. What about meeting tomorrow? Who else than you, SteveA and I needs to be present? | 10:20 |
| SteveA | then next time I ask "how is this going", you'll be able to say "did A then B, and the result of investigating [foo] was [bar] " | 10:20 |
| SteveA | ddaa: I think we don't need the meeting, if spiv writes the doc. | 10:21 |
| spiv | I'll write the doc within 24 hours, put it on the wiki, and post to the list about it. | 10:21 |
| SteveA | thank you spiv | 10:21 |
| ddaa | ACTION: spiv writes supermirror-smart-server plan | 10:21 |
| spiv | I think discussion about it can probably be done adequately by email. If it turns out to be a messier than expected discussion, we can look at scheduling a meeting. | 10:21 |
| SteveA | I'd like the same for viewcvs-style support, at some point | 10:22 |
| ddaa | spiv: ++ | 10:22 |
| ddaa | SteveA: let's talk this week about what we'd like Tim to work on next month. The bzrweb integration could be one of those items. | 10:23 |
| ddaa | Moving on. | 10:23 |
| ddaa | == Naming convention == | 10:24 |
| ddaa | * Use a naming convention for branches to be hidden/removed (Steve Alexander) | 10:24 |
| SteveA | a bzr / supermirror user asked for a branch of his to be removed | 10:25 |
| SteveA | or hidden | 10:25 |
| SteveA | as it was just an experiement | 10:25 |
| SteveA | I spoke with him, and found out that he wanted it hidden just for aesthetic reasons | 10:25 |
| SteveA | that is, no problems with illegal data or anything | 10:25 |
| SteveA | I explained we can't easily do that right now | 10:25 |
| SteveA | he said okay, and suggested that we use a naming convention for branches that are to be hidden | 10:26 |
| SteveA | so that people can use this now, and they get hidden when we have support in the code | 10:26 |
| SteveA | maybe branch--hidden or something | 10:26 |
| ddaa | mh... double dash... | 10:26 |
| lifeless | I dont understand why we dont just use branch status | 10:26 |
| jamesh | hiding obsolete branches by default? | 10:27 |
| lifeless | right | 10:27 |
| lifeless | with a 'show all' page to show them | 10:27 |
| spiv | Also "merged" branches. | 10:27 |
| ddaa | lifeless: because we want to represent a "deleted" state, for branches that should eventually be garbage collected | 10:27 |
| lifeless | I feel quite uncomfortable with the idea of conflating 'hide branches' and 'name' | 10:27 |
| ddaa | which is different from merged/abandoned, which should appear in the "show all branches" listing even when we have branch deletion support | 10:28 |
| lifeless | ddaa: so add a state for that. One new entry in the dbschema, called 'to be deleted'. | 10:28 |
| ddaa | which is awkyard since it's not clear whenever we will actually support it | 10:28 |
| SteveA | I think we should use the name for this, unless the software will support it reasonably soon, conflation or no conflation | 10:28 |
| ddaa | also it's more work than just agreeing on a naming convention | 10:28 |
| jamesh | if we have a "to be deleted" state, people might expect the branch to stop being published. Is that the intent? | 10:29 |
| SteveA | the name is something users can change today, and the conflation is not harmful in the long term. it just goes away. | 10:29 |
| SteveA | becauase the branches do | 10:29 |
| ddaa | I think I already used something like "status=obsolete name=<foo>-deleted[-N] " | 10:29 |
| spiv | SteveA: We already have a status field with values like "obsolete" and "merged". Why not make the proposed UI changes use that? | 10:29 |
| SteveA | spiv: we can. if it is done *soon* | 10:29 |
| ddaa | I like SteveA's suggestion | 10:29 |
| ddaa | I think I understand the issue, and I'll reply to the questions by email today. | 10:30 |
| SteveA | I want to avoid us leaving this gap on account of a feature that won't be ready soon. So, if soon, great. If not soon, workaround. | 10:30 |
| ddaa | workaround sounds better to me right now, it's less commitment and avoids raising expectations, and having more stub features in the UI. | 10:31 |
| ddaa | Shall we move on? | 10:31 |
| ddaa | == Status reports == | 10:32 |
| ddaa | * spiv: supermirror-smart-server. | 10:32 |
| ddaa | * jamesh: spec-branches. | 10:32 |
| ddaa | * ddaa: python import. | 10:32 |
| jamesh | spec-branches is still in the queue | 10:32 |
| ddaa | python import: up and running since all-hands | 10:33 |
| ddaa | * ddaa: pyrex. | 10:33 |
| spiv | The status of supermirror-smart-server is probably best addressed by the wiki page I've promised to write shortly. | 10:33 |
| ddaa | Dunno if SteveA has reviewed the pyrex branch, or if their status has changed somehow. | 10:33 |
| spiv | So I'll skip that for now, if that's alright. | 10:34 |
| ddaa | spiv: that's alright, it's been discussed enough at the beginning of the meeting. | 10:34 |
| SteveA | so, the pyrex thing is ddaa's experimental new svn bindings, focused on what we need | 10:34 |
| SteveA | is that right? | 10:34 |
| ddaa | SteveA: that's right | 10:35 |
| SteveA | how complete is the pyrex stuff for what we need? | 10:35 |
| ddaa | Not complete yet. Includes removal of dep on native swig bindings. | 10:35 |
| ddaa | Now, the prereq have been merged to allow the work to start on using svn_ra API for the critical code paths. | 10:36 |
| SteveA | what is svn_ra | 10:37 |
| SteveA | ? | 10:37 |
| SteveA | what do you want to do with this branch? | 10:37 |
| ddaa | Which will allow very substantial improvements in efficiency. But I'd like feedback on the proof-of-concept code that's already pending review. | 10:37 |
| ddaa | svn_ra is the low-level "talk with svn over the wire" API | 10:37 |
| jamesh | ra == repository access | 10:37 |
| ddaa | goals: simplify the code (only one entry point to libsvn, thin bindings), more flexibility (allow access to all libsvn functionality), more efficient (allow using functionality not available with pysvn) | 10:39 |
| ddaa | ultimately, the problem is that all all python-libsvn bindings suck in one way or another | 10:39 |
| ddaa | and the svn import code has reached the point where that's become the next roadblock. | 10:40 |
| SteveA | what problems are we seeing that are blocked by shoddy bindings? | 10:41 |
| ddaa | using svn_ra allows to use a single session in the critical loop, which cuts down on round-trip and connection count | 10:41 |
| ddaa | SteveA: imports failing because of connection errors in the middle of the import | 10:41 |
| ddaa | current code involves literally thousands of connections (sequential) for even moderately sized imports | 10:42 |
| ddaa | makes it slow | 10:42 |
| ddaa | makes it unreliable | 10:42 |
| ddaa | and put uncessary load on community resources | 10:42 |
| SteveA | ok. | 10:42 |
| SteveA | lifeless: what would you suggest to do with ddaa's branch next? | 10:43 |
| lifeless | SteveA: its currently in the review queue, with you as the reviewer. | 10:43 |
| lifeless | I dont really get the question I think. Surely we want to achieve two things | 10:44 |
| SteveA | I'm not really qualified to review it | 10:44 |
| lifeless | 1) demonstrate that this is a solid, reliable way forward. I.e. check that callbacks work properly, and that the apr memory pool stuff is managed well | 10:45 |
| lifeless | 2) start using it. | 10:45 |
| lifeless | I would ask for the same thing you asked spiv to do - a list of whats needed to achieve these two things. | 10:45 |
| SteveA | thank you lifeless | 10:46 |
| SteveA | I agree with your points | 10:46 |
| SteveA | in addition, for point 1, this is a new binding that we'll be maintaining | 10:46 |
| SteveA | so we should have a good sense that it is a better way to proceed than maintaining existing bindings | 10:47 |
| lifeless | the existing bindings are both hard to maintain | 10:47 |
| SteveA | questions like, has the upstream for any of the bindings improved things since we last looked? | 10:47 |
| lifeless | I vouch for them being difficult | 10:47 |
| ddaa | meeting time ended: jamesh, spiv, you can go and workrave | 10:48 |
| SteveA | ddaa: I think you should do some more management of the meeting | 10:48 |
| SteveA | simply announcing that the time is ended is not good meeting management | 10:48 |
| ddaa | well, anyway all theh points have been adressed | 10:49 |
| ddaa | we can continue to talk about the svn bindings | 10:49 |
| ddaa | jelmer has posted some improvements to the upstream swig bindings | 10:49 |
| SteveA | lifeless: ok, so someone competent to do so needs to review it for the points you listed | 10:49 |
| ddaa | it's in the svn 1.5 branch and backported in edgy | 10:49 |
| ddaa | however, the swig bindings are not reliably maintained upstream | 10:50 |
| SteveA | also, is there value in this being released as open source if we do decide to go with it, to get other contributions? | 10:50 |
| lifeless | I think so. | 10:50 |
| ddaa | the pyrex bindings will be released as they are part of cscvs | 10:50 |
| ddaa | and releasing cscvs is something I want to do before the end of the year | 10:50 |
| SteveA | ddaa: the pyrex bindings exist as your private experiment. they are not part of cscvs at this point | 10:50 |
| ddaa | SteveA: well, assuming they get merged, of course | 10:51 |
| SteveA | one of the points of this review process is to decide whether we switch to them | 10:51 |
| lifeless | it doesn't make a lot of sense to me for the bindings to be part of cscvs | 10:51 |
| ddaa | makes sense to me, as they are very focused on what cscvs needs | 10:51 |
| ddaa | to keep them as simple as possible | 10:51 |
| ddaa | no more exposed functionality than necessary | 10:51 |
| ddaa | so, no more bugs than necessary | 10:51 |
| SteveA | it's an API binding | 10:52 |
| SteveA | adding new API to it won't create bugs in the rest, I think | 10:52 |
| ddaa | I see them more as a glue. Generic libsvn bindings is... complicated, it's not a nice-and-simple API | 10:53 |
| SteveA | if there's a point in releasing it, it's so that people get interested in it, perhaps to extend it, and reduce our maintenance burden | 10:53 |
| spiv | It's a clearly independent module in terms of functionality. If nothing else, keeping them seperate will make it easier for the community to contribute to them. | 10:53 |
| SteveA | trying to enforce a false limit on its scope will not help people get interested in it | 10:53 |
| spiv | A small, fairly simple set of pyrex files is much less scary to a potential contributor than those files + all of cscvs, which is pretty hairy in parts. | 10:54 |
| ddaa | I do not think there is intrinsic value in getting people interested in them. If there was actual interest in the python community for effective libsvn bindings, we would not have to roll our own. | 10:54 |
| spiv | And similarly, a contributor to cscvs might be scared by the false impression they have to learn pyrex or compile stuff to hack on cscvs. | 10:54 |
| ddaa | spiv: right, it would be good to clean up the cscvs packaging to have clear modules and extension points. The overall design is okay, but the execution is not quite there in terms of practical modularity. | 10:56 |
| spiv | I think we should try fairly hard to be a good open source citizen, providing reasonably neatly packaged source, rather than just a messy, tangled dump. We will damage the goodwill we generate by releasing source if we do it in a community-hostile way. | 10:56 |
| SteveA | ok | 10:57 |
| ddaa | some truth in that. That's why I want to keep this release low-key. | 10:57 |
| ddaa | It's just there for people who have expressed a desire to help already. | 10:57 |
| SteveA | who will review ddaa's pyrex stuff? someone who knows about how svn bindings need to work. | 10:57 |
| jamesh | spiv:a separately packaged binding only really makes sense if things other than cscvs will use it | 10:58 |
| jamesh | if the aim of the binding is just "as much of libsvn as cscvs needs", then it doesn't really have a separate target audience | 10:59 |
| ddaa | jamesh: ++ | 10:59 |
| ddaa | Also, the code might be independent in terms of functionality, but there's value in keeping it couple in terms of design for KISS compliance. | 10:59 |
| jamesh | plus, if the binding is "as much of libsvn as cscvs needs", then you may need to update the two in lockstep anyway | 11:00 |
| lifeless | I have to run another meeting now | 11:00 |
| lifeless | I suggest that spiv or jamesh review the code forits pyrexstyle. | 11:00 |
| jamesh | which makes separate packages less useful | 11:00 |
| lifeless | I have done some pyrex too, so in a pinch I can review it. | 11:00 |
| lifeless | for the svn style, me/spiv/jamesh can review it I suspect. | 11:01 |
| spiv | I know some pyrex, and some high-level svn, but not svn API. | 11:01 |
| lifeless | use of svn API should not be reviewed in this regard I think | 11:01 |
| lifeless | thats ddaa's problem :) | 11:01 |
| ddaa | yeah, anyway current code is mostly bug-for-bug compatible | 11:02 |
| ddaa | I just want guidance on coding standard, code organisation, etc. | 11:02 |
| === Starting logfile irclogs/launchpad-meeting.log | ||
| === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad-meeting | ||
| === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad-meeting | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!