[12:16] <sabdfl> launchpad list is private, right?
[12:22] <salgado> right
[12:25] <sabdfl> kiko: ping
[12:26] <lucasvo> is there any feauture planned to have a mailing list per group?
[12:29] <sabdfl> lucasvo: yes! would that be useful to you?
[12:33] <lucasvo> sabdfl: well, for coordinating efforts and discussion about development I think I would use it once there are more than 2 devs in my team
[12:34] <lucasvo> sabdfl: however I think working things out with malone and bazaar have higher priorities
[12:34] <sabdfl> agreed
[12:35] <lucasvo> (linking bugs to revision #, uploading bzr branches to product branches, and couple of other things)
[12:35] <lucasvo> ah yes, and maybe some syntax for bug fixing in ci messages would be cool
[12:35] <lucasvo> like: fixes bug # 22
[12:35] <sabdfl> amen, brother
[12:36] <lucasvo> sabdfl: sorry, I can't really figure out what amen means in this context. ACK? agreed?
[12:36] <sabdfl> very much agreed
[12:36] <lucasvo> good to know :0
[12:36] <lucasvo> :)
[12:38] <lucasvo> sabdfl: too bad it's not opensource. I started using LP because there were some rumors that it be opensourced. that was, what made me prefer it from trac and SF
[12:38] <sabdfl> trac is open source
[12:38] <lucasvo> sabdfl: yes, but it doesn't host the projects
[12:39] <sabdfl> right
[12:39] <lucasvo> not having to deal with svn permissions and making your ISP install trac is a great relief
[12:40] <lucasvo> do you (still) have in mind of opensourcing it? 
[12:40] <sabdfl> yes
[12:41] <sabdfl> we want to refactor it and release it chunks at a time
[12:41] <lucasvo> it's not that I would want to set it up on my own server, but when I develop free software I want to develop it using free software
[12:41] <sabdfl> starting with the infrastructure that makes it possible, so that others can write web infrastructure like this too
[12:41] <sabdfl> we have GREAT infrastructure
[12:41] <lucasvo> what infrastructure? I've only seen the apache proxy error so far... :)
[12:42] <sabdfl> you'll see :-)
[12:42] <lucasvo> yeah
[12:44] <sabdfl> night all
[01:43] <WebMaven> Added a spec: https://launchpad.net/distros/ubuntu/+source/zope3/+bug/56853
[01:43] <Ubugtu> Malone bug 56853 in zope3 "Make it easier to build Zope3 + MySQL applications" [Unknown,Unknown]  
[01:43] <WebMaven> https://features.launchpad.net/distros/ubuntu/+spec/better-zope3-support
[02:23] <WebMaven> https://wiki.ubuntu.com/Zope3onUbuntu
[02:24] <ajmitch> WebMaven: #launchpad isn't the best place for raising issues about ubuntu development
[02:25] <WebMaven> It's more of a Zope3 issue. I thought it would be of interest.
[02:25] <ajmitch> it's a request for ubuntu packages
[02:25] <WebMaven> Oh, you mean the stuff I pasted earlier. Sorry. OK.
[12:47] <sabdfl> how do i see an OOPS?
[12:49] <sivang> sabdfl: hey, I'm trying to see the link you sent me but it's timing out ;-)
[12:50] <sabdfl> sivang: any spec listing will show it to you
[12:50] <sivang> sabdfl: right, cool, and thanks for the landing!
[12:50] <sabdfl> sure, thanks for the code :-)
[12:51] <sivang> sabdfl: hrm, can you access staging though? (even front page)
[12:51] <sabdfl> https://staging.launchpad.net/+graphics
[12:51] <sabdfl> sure
[12:55] <sivang> sabdfl: this page partially loads. But Staging just timeouts with an OOPS for me, is this knows / planned ?
[12:55] <jamesh> sabdfl: https://devpad.canonical.com/~jamesh/oops.cgi/$OOPSID
[12:55] <sivang> OOPS-231S15
[12:55] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/231S15
[12:56] <sabdfl> sivang: staging may be under some load, i think there's work under way to open Edgy translations
[12:56] <sabdfl> which drives the db server nuts
[12:56] <sabdfl> they may be testing that on staging right now
[12:56] <sabdfl> jamesh: thanks!
[12:56] <sivang> ah right, makes sense, okay.
[12:56] <sabdfl> jamesh: great blog on the supermirror stuff
[12:56] <jamesh> thanks.
[12:56] <sabdfl> i really want that experience to be very slick for people
[12:56] <sabdfl> should come down to:
[12:57] <sabdfl>   bzr branch lp:///python my-branch
[12:57] <sabdfl>   bzr commit
[12:57] <sabdfl>   bzr push lp:/[some url indicating my branch] 
[12:58] <sabdfl> and it should then be visible to everyone, under ~name/product/my-branch
[12:59] <sabdfl> with the smart server work by spiv and mpool, i think we can make the whole thing pretty fast
[12:59] <sivang> hmm, so each person can become a sort of LP "Instance" holding a world of products , packages, branches and so on of his own ?
[12:59] <sivang> well, packages probably fall under PPAs
[01:00] <jamesh> yeah
[01:00] <sabdfl> sivang: yes
[01:00] <jamesh> I wonder if the smart server would be able to automatically use other branches as a basis for the initial push?
[01:00] <sivang> cool!
[01:00] <sabdfl> i was just thinking the same thing
[01:00] <sabdfl> if it remembered the revision that came *from* the supermirror, in metadata, it could use that for the push
[01:01] <sivang> and I assume the plan is also to allow that from teams, as they basically could be treated like people ?
[01:01] <jamesh> although perhaps doing repositories on the supermirror would get similar benefits
[01:01] <sabdfl> it could start the conversation with "hi, i am about to push a branch which started with revision X, and I happen to know you have that"
[01:02] <sabdfl> which could then create the repository and allow the new branch push to be really, really fast
[01:04] <sabdfl> so, you wouldn't even have to have had a previous push of this product yourself
[01:04] <sabdfl> just leverage a repository which can be created because you know which revision you last saw from the SM
[01:05] <sabdfl> since revision ID's are uuid's, knowledge of the revid implies knowledge of the branch itself
[01:05] <sabdfl> though we should probably enfore branch privacy over and above that
[01:05] <sabdfl> mpool: ^ ?
[01:33] <LarstiQ> sabdfl: when aaron's nested trees work is done, you should be able to identify a project by it's root-id
[01:40] <sabdfl> LarstiQ: that's pretty interesting - i'll chat with aaron about that
[01:41] <LarstiQ> you still have the problem that everyone who branches off that has the same root-id, but it gives you an idea what branches to look at
[01:42] <LarstiQ> but aaron can tell you more :)
[01:42] <jamesh> LarstiQ: we have a DB with revision info for all the registered branches, so picking a closest matching branch is not an insurmountable problem
[01:43] <jamesh> LarstiQ: just go back in the revision history til you get a match
[01:45] <LarstiQ> jamesh: you'll need something more than just push then
[01:45] <LarstiQ> or it will be installing old revision first, and that is what you want to speed up
[02:02] <lifeless> sabdfl: the basic approach will be that you ask the smart server what you need to upload
[02:02] <lifeless> sabdfl: so it may be possible - we've actually discussed this before
[02:03] <lifeless> IIRC we felt it was best to have an explicit 'reuse this branch' api in it, which is not as transparent, but provides plenty of room for optimisation
[02:06] <lifeless> LarstiQ: you cant id a project by the root - forked projects will share roots, just like revision ids will, and anyhow a revision id query is almost the same overhead
[02:07] <LarstiQ> lifeless: right, I see forks as the same thing, but that has potential for huge mismatches in the revision history
[02:07] <lifeless> also, all the existing projects have one root id
[02:07] <LarstiQ> there is that small operational problem, yes :)
[02:08] <LarstiQ> that is a particular id though?
[02:08] <lifeless> yes
[02:09] <LarstiQ> would you do a 'related branches:' by traversing the revision-history and looking up who has the same revisions, or would roots (bar the current one) be ok for that?
[02:10] <LarstiQ> You'd need the former for branching visualisation anyway
[02:13] <lifeless> so the problem with transparent branch cloning is revision pollution
[02:14] <LarstiQ> if you use a launchpad wide repository?
[02:14] <LarstiQ> or even a user/product wide one
[02:14] <lifeless> if we ignore that, its basically a chatter back and forth to determine what revision the bundle to be uploaded should be made against
[02:14] <lifeless> which is the exact same chatter that any normal upload to a branch will use
[02:15] <LarstiQ> even on dumb transports?
[02:15] <lifeless> except that there is no remote initial revision to match against
[02:15] <lifeless> no, any normal hpss upload
[02:15] <LarstiQ> ok
[02:20] <lifeless> but a simple approach is to allow explicit cloning
[02:20] <lifeless> 'branch remoteA remoteB, then push --overwrite remoteB'
[02:20] <lifeless> I think we can make this seamless within the client for launchpad uploads
[02:21] <LarstiQ> how do you determine remoteA?
[02:22] <lifeless> query for 20 or 30 revision ids in the lp database, among the branches for the product being uploaded too that you have access to
[02:22] <lifeless> the revision ids are exponential backoffs in the rev history
[02:23] <lifeless> the tip, tip -5, tip -25, tip -125, tip -625, tip - 3K, tip -15K
[02:23] <lifeless> sort of thing
[02:25] <lifeless> anyhow, its all worth consideration
[02:25] <LarstiQ> ok, that should work when you branch python-trunk and keep the same product when uploading
[04:36] <sabdfl> lifeless: in many cases, the user will branch *from* launchpad and push *to* launchpad
[04:36] <sabdfl> so, it should be able to know at least a recent rev-id that is on the server
[10:49] <parsek> is there a shipit channel, or can i ask here about it
[10:56] <LarstiQ> you can ask here
[10:57] <parsek> do i have to make 2 orders if i want to order kubuntu and ubuntu
[10:57] <lucasvo> parsek: yes
[10:58] <parsek> does it cost me anything
[10:58] <lucasvo> parsek: no
[10:58] <parsek> i mean shiping
[10:58] <lucasvo> parsek: and they will get shipped together
[10:58] <lucasvo> parsek: no
[10:58] <parsek> thx
[10:58] <lucasvo> just login to shipit.ubuntu.com and afterwards shipit.kubuntu.org
[10:59] <parsek> well i`m doing it the other way
[10:59] <parsek> does it matter
[10:59] <parsek> first kubuntu then ubuntu
[11:00] <lucasvo> no
[11:03] <parsek> well, i dont know if here is any makers of kubuntu but i have to say that thx for making a great OS (works perfectly even with my 5 year old laptop) and thanks lucasvo 
[11:04] <parsek> Bye!