[00:31] <micahg> how can someone add a bugwatch to a duplicate bug?
[00:31] <maxb> Hrm... is the branch scanner broken?
[00:36] <micahg> I seem to have trouble deleting bugwatches on edge
[00:36] <micahg> same on production
[00:39] <micahg> bac: I'm getting a problem connecting to LP page
[00:44] <spm> maxb: possibly. we're chasing atm. it seems to be working, but we're showing massive delays.
[00:51] <rockstar> maxb, can you show me an example branch?
[00:53] <rockstar> Er, an example of the scanner being broken.
=== mnepton is now known as mneptok
[01:02] <maxb> rockstar: https://code.edge.launchpad.net/~maxb/launchpad/use-hashlib has been pushed for some time now
[01:03] <spm> bleh nothing in the branch sccaner log matching that
[01:03] <maxb> just a massive backlog, then?
[01:04] <rockstar> maxb, actually, that looks like the mirror-puller might have issues.  spm and I are chasing now.
[01:19] <spm> maxb: looks like an unnamed individual has managed to hog the mirror-puller; stuff was still happening; but sufficiently slowly - it impacts on everyone else
[01:27] <maxb> *blink*
[01:27] <maxb> Just how many branches do you have to push to do that !
[01:28] <mwhudson> it's usually mirrored branches that screw things up
[01:40] <doctormo> Using a branch object, why is the url attribute always empty? I'm trying to find the url that bzr uses for it's branches but I don't think lp is able to provide it.
[01:41] <maxb> doctormo: um, more context please?
[01:42] <james_w> doctormo: the url is probably misnamed, it doesn't provide that information
[01:42] <doctormo> james_w: Thanks
[01:43] <james_w> doctormo: you can manipulate self_link to get a url for the branch
[01:43] <doctormo> My branch listing process is so slow, loading in owners, urls and other data. Although I think checking the owner team members is killed it.
[01:43] <maxb> james_w: UDD question... having determined that an import failure is likely because an upstream-FOO tag is in the wrong branch.... is there any good way to test that out locally?
[01:44] <james_w> maxb: you can grab the import-scripts branch and do ./import_package.py <package name>
[01:44] <james_w> pass --no-push to not push
[01:45] <james_w> --no-existing to start from the beginning without re-using the branches on LP
[01:45] <maxb> ah, yes, but I want it to try importing using a local copy of the LP branches which I've moved a tag around in
[01:46] <james_w> that's probably fairly easy to do with a bit of code
[01:46] <maxb> ok, I'll have a hack
[01:46] <james_w> see the BranchStore class in icommon.py
[01:46] <james_w> if that is the cause it is probably because of a missing merge of the tags
[01:47] <james_w> bzr doesn't merge the tags when you merge branches, so you have to do it as an explicit step
[01:47] <maxb> The case I'm looking at, the upstream-x.y.z tag is in the ubuntu branch not the debian branch, where the upstream was independently imported into both
[02:23] <DBO> anyone else having issues pushing code?
[02:25] <DBO> oh there we go
[03:21] <persia> Did something change in the AJAX subscription UI recently?  I just ended up on a non-ajax subscribe self and/or teams page ( https://launchpad.net/ubuntu/+source/xf86-video-displaylink/+subscribe )
[03:21] <persia> I had thought those had all been removed (and have one invalid and one wontfix bug related to them under the assumption they have gone)
[03:22] <wgrant> persia: I occasionally get there by clicking on the link too quickly.
[03:22] <wgrant> (before the JavaScript has turned the non-AJAX link into an AJAXy one)
[03:23] <wgrant> The old forms are still there, so things still work if JS is turned off.
[03:23] <persia> That may have been what I did.  Are the old pages still there to support non-ajax browsers?
[03:23] <wgrant> Right.
[03:23] <persia> Aha!  Now I think the state of my bugs is wrong.
[03:23] <persia> It's still possible to get to the exceedingly annoying page where one can't do the obvious subscribing oneself while unsubscribing a team (or vice-versa).
[03:24] <persia> So the page is still buggy, although the related bug has been declared irrelevant because of the AJAX UI.
[03:24]  * persia decides it doesn't matter enough, but would prefer a consistent interface
[04:50] <mbt> Hi, I have made a new release of my project (AllTray) that is a minor bugfix release out of the maintenance branch. However, it seems that it doesn't want to show up on the front page for downloads. I don't want it at the top, ahead of my trunk releases, but I want it after the 0.70 release from historic, and it won't seem to go.
[04:51] <mbt> Am I doing something wrong here?  https://edge.launchpad.net/alltray/+download
[04:53] <mwhudson> mbt: what's your new release called?
[04:53] <mbt> 0.71, from the old-maintenance branch.
[04:53] <mwhudson> ah
[04:53] <mwhudson> maybe it's because the series is different?
[04:53] <mbt> I would like to push the historic releases "down"; as it is, the release that I just made won't even show up on the first page of downloads
[04:54] <mbt> I expect trunk to show up first, and it does---but then I expect historic to be last since it's obsolete and old-maintenance is the current 'stable', so I'd expect that to display after trunk
[04:56] <mwhudson> mbt: the series are sorted as if the names are version numbers
[04:57] <mbt> oh... so i have to rename the series to change the sort order?
[04:57] <wgrant> That's how series are intended to be used, but that doesn't seem to be conveyed very well.
[04:57] <mwhudson> looks like it
[04:57] <mbt> eww.
[04:57] <mwhudson> i had to read the code to figure this out, i certainly didn't know it off the top of my head
[04:58] <mbt> that'll break existing branches, though, if I do that, won't it.
[04:58] <mbt> or at least, their references.
[04:59] <mwhudson> mbt: it will change the lp:alltray/old-maintenance names
[04:59] <mbt> Well, wait a minute... trunk, historic-releases, old-maintenance... in that order, so I guess it's sorted by development focus first, then alphabetically?
[04:59] <mwhudson> but they don't tend to get stored by things
[05:00] <mbt> I should probably file a bug to ask to sort "obsolete" series last.
[05:00] <mwhudson> mbt: yes
[05:00] <mwhudson> mbt: that sounds like a very good idea
[05:00] <mbt> What's the code hosting component called again?
[05:01] <mwhudson> launchpad-code
[05:01] <mwhudson> but!
[05:01] <mwhudson> this bug should be filed against launchpad-registry probably
[05:01] <mbt> Oh.
[05:01] <mbt> I can do that. :)
[05:01] <mwhudson> thanks
[05:01]  * mwhudson runs away to make dinner
[05:03] <mbt> Oh.
[05:03] <mbt> Bug 490945.
[05:03] <ubottu> Launchpad bug 490945 in launchpad-registry "obsolete series takes precedence over stable" [Low,Triaged] https://launchpad.net/bugs/490945
[08:11] <nigel_nb> spm, is Lp's gnome bug tracker broken?
[08:18] <thekorn> nigel_nb, what do you mean by launchpa's gnome bugtracker? the auto sync of upstream bug status?
[08:18] <nigel_nb> yep
[08:19] <thekorn> I think it is disabled, there was an annoucement somewhere
[08:20] <nigel_nb> thekorn, oh! any specific reason?
=== mordred_ is now known as mtaylor
[08:21] <thekorn> nigel_nb, don't know, cannot remember correctly, plus I'm unable to find it right now
[08:21] <nigel_nb> thekorn, np.  thanks for letting me know :)
[08:41] <om26er> why bug emails come late as compared to answers ?
[08:41] <wgrant> om26er: They are batched, so each separate change doesn't come in its own email.
[08:42] <wgrant> Changes made by the same person within a few minutes will all come in the one email.
[08:42] <om26er> wgrant, hmm, thanks
[09:44] <solsTiCe> hi. i found strange that i am able to modify the orignal post for a bug whereas i am not the orignal poster. ironically, i am not able to modify my own last post, but change theb ug report ! there is a bug in the bugtracker ;-)
[09:59] <nigel_nb> solsTiCe, you can change any bug report, though you cannot change the comments to a bug
[10:01] <wgrant> The bug description may be changed at any time.
[10:01] <wgrant> Comments may not.
[10:31] <FloSoft`> hi, one question: why does sometimes it happen that the status is not tracked in the targeted release? like in https://bugs.launchpad.net/s25rttr/+bug/518404
[10:31] <ubottu> Ubuntu bug 518404 in s25rttr/s25client "Road can be constructed over water" [Undecided,Won't fix]
[10:31] <wgrant> FloSoft`: If the development series task is set to "Won't Fix", the main task becomes active again.
[10:32] <FloSoft`> how to change that?
[10:32] <FloSoft`> so its tracked again in the release?
[10:32] <wgrant> Change it to something other than Won't Fix.
[10:33] <FloSoft`> ah okay ;-)
[10:33] <FloSoft`> is it so one can "fix it" in another release?
=== matsubara-afk is now known as matsubara
[11:08] <Lamba> anyone here good with bzr ? - i just lost my net connection during a push and it's all gone a bit sideways. - on a new push bzr is saying its unable to obtain a lock and suggests to use "break-lock" but bzr then gives "error unsupported protocol for url" when i try that.
[11:11] <Meths> Lamba: There's more activity in #bzr than here at the moment, may want to ask there.
[11:11] <Lamba> kk
[11:29] <james_w> OOPS-1501EA207
[11:29] <ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1501EA207
[11:31] <Lamba> fixed. for future reference, break-lock lp:~username  works. break-lock sftp  or break-lock bzr+ssh dont, although they give no obvious error.
[11:31] <wgrant> Lamba: They should work fine. What do they do?
[11:33] <Lamba> nothing :P - just drop back to prompt.
[11:33] <wgrant> Which URLs did you try?
[11:34] <Lamba> sftp:lp//~username/project/trunk
[11:34] <wgrant> Ah. That's not a valid URL.
[11:34] <Lamba> yea. no error though.
[11:34] <wgrant> lp:~user/project/branch aliases to bzr+ssh://username@bazaar.launchpad.net/~user/project/branch
[11:35] <Lamba> ah. ok. thanks :D
=== mrevell is now known as mrevell-lunch
=== mrevell-lunch is now known as mrevell
=== CardinalFang__ is now known as CardinalFang
=== salgado is now known as salgado-lunch
=== matsubara is now known as matsubara-lunch
=== andreas__ is now known as ahasenack
[15:59] <gerard_> there seems to be some problems with importing lp:warzone2100 from svn
[16:00] <gerard_> we're at r9751 but it's stuck at r6897
[16:00] <gerard_> or... let me check, sec
[16:01] <gerard_> heh, nvm
=== jamalta-afk is now known as jamalta
[16:01] <gerard_> that's just bzr and svn having different revision numbers
=== yofel_ is now known as yofel
=== matsubara-lunch is now known as matsubara
[16:26] <kirkland> I can't reach this page: https://edge.launchpad.net/~ecryptfs-devel/+mailinglist-moderate
[16:26] <kirkland> I suspect because there are thousands of spam messages awaiting approval
[16:26] <kirkland> help?
=== micahg1 is now known as micahg
[16:30] <bigjools> hey kirkland
[16:30] <kirkland> bigjools: yo
[16:30] <bigjools> I enjoyed your NZ blog :)
[16:30] <kirkland> bigjools: thanks!
[16:30] <bigjools> and somewhat jealous - I spent a lot of time trekking around there
[16:30] <kirkland> bigjools: evidently my LP presentation was "too enthusiastic" though
[16:31] <kirkland> bigjools: heh
[16:31] <kirkland> bigjools: so that mailing list receives dozens of spams per day
[16:31] <bigjools> I'll find someone to help with your problem
[16:31] <kirkland> bigjools: so many that i just quit moderating
[16:31] <bigjools> ok
[16:31] <kirkland> bigjools: and basically i only go to the page when someone complains that their message doesn't get through
[16:31] <kirkland> bigjools: is there any spam filtering that is, or can be done on the LP side?
[16:32] <kirkland> bigjools: otherwise, i just need to get in there and clean out months of spam messages
[16:32] <bigjools> I have no idea!
[16:32] <bigjools> but I know a man who does
[16:32] <kirkland> bigjools: cool, thanks
[16:32] <bigjools> maybe barry does, even though he's not on LP at the moment?
[16:33] <bac> hi
[16:33] <kirkland> bigjools: or, if a mailing can be configured such that only members of the team can post
[16:33]  * bac reads backwards
[16:34] <kirkland> hi bac
[16:34] <bigjools> heh, didn't see bac in my list of users since he's at the top as an op
[16:34] <kirkland> bac: let me know what you need from me
[16:34] <bac> hi dustin
[16:34] <bac> kirkland: AIUI mailing lists in LP don't have a lot of configurability
[16:35] <bac> kirkland: what team are you referring to?
[16:35] <kirkland> bac: yeah, no offense, but they're really pretty bad
[16:35] <kirkland> bac: ecryptfs-devel
[16:35] <bac> kirkland: i'll pass that sentiment on to barry!  :)
[16:35] <kirkland> https://edge.launchpad.net/~ecryptfs-devel/+mailinglist-moderate
[16:35] <kirkland> bac: ;-)
[16:35] <kirkland> bac: make sure you include the "no offense" part :-)
[16:36] <bigjools> haha
[16:36] <persia> Wasn't there a bug about getting CLI mailman access to the LP mailing lists?
[16:36] <persia> That might help sort things more quickly.
[16:38] <bac> kirkland: i think we're going to have to wait until barry can provide some answers.
[16:38] <kirkland> bac: okey
[16:41] <barry> bac, kirkland wassup?
[16:42] <bac> barry: dustin has a LP-based mailing list with only 4 members that is getting spammed to death
[16:42] <bac> barry: is there a way to configure 'only post by members'?
[16:43] <barry> yeah, but the problem is that mailing lists is not the right place to be doing spam detection.  we really need spamassassin in the mta.  i think there's an open rt about that
[16:44] <barry> bac: no, however non-lp users cannot email any mailing list, so if you've identified lp users who are spamming, we need to disable their accounts
[16:44] <kirkland> barry: spamassasin would be great
[16:44] <kirkland> barry: in the short term, i can't access the moderation page
[16:44] <barry> persia: yes, there is an open bug about api access to mlists.  will probaby happen after lucid
[16:44] <barry> kirkland: because it's timing out?
[16:44] <kirkland> barry: i suspect because there's too many messages in queue
[16:44] <kirkland> barry: yeah
[16:45] <barry> lovely
[16:46] <barry> the only thing i can think of for "right now" is to get some losa love to clear them out.  not a fun thought for them though :/
[16:47] <kirkland> barry: okay, well, they will get lots of love back from the hot russians ladies messaging that list
[16:47] <barry> kirkland: there's always a silver lining! :)
[16:48] <kirkland> barry: so there's 2-3 messages of the hundreds that i'm trying to allow through
[16:48] <barry> kirkland: do you know which those are? message-ids?
[16:48] <kirkland> hmm
=== salgado-lunch is now known as salgado
[16:51] <barry> kirkland: if you don't that's okay.  it would make the clear out a little simpler i think
[16:51] <kirkland> 20100209095431.GC16039@sage.bj.intel.com
[16:51] <kirkland> barry: i'd like to white-list that user
[16:51] <kirkland> barry: and i'm looking for the 1 other
[16:51] <barry> kirkland: once that message is approved, they automatically get whitelisted
[17:02] <barry> kirkland: please send me an email with the message-ids of the messages you want to allow and i will try to get some losa time to figure out how to clear your queue
[17:02] <kirkland> barry: i can't find them; just clear out everything
[17:02] <kirkland> barry: and i'll hope for spamassassin in the future
[17:03] <kirkland> barry: and i'll apologize profusely to the legit users who's messages have been blocked
[17:03] <barry> kirkland: cool
[17:03] <kirkland> barry: thanks for your help
[17:04] <barry> kirkland: this is for the ~ecryptfs-devel mailing list, right?
[17:09] <kirkland> barry: yessir
[17:09] <kirkland> barry: though ~ecryptfs-users is equally fscked
[17:11] <barry> kirkland: what is it about crypto that brings out the spammers and crazies? :)
[17:46] <mtaylor> is there no way to get at blueprints via launchpad lib?
[17:46] <maxb> mtaylor: AFAIK, the answer is if it's not on https://edge.launchpad.net/+apidoc, it's not possible
[17:47] <maxb> I can quite believe that no one got around to exposing blueprints APIs
[17:47] <mtaylor> maxb: lovely... there is an object in that api called specification, but the docs for it refer to bugs
[17:47] <mtaylor> maxb: even though there is a bug object
[17:48] <mtaylor> maxb: I'm gonna go with "no one got around to exposing it"
[17:49] <persia> maxb: I thought the answer was "If it's not in +apidoc, patches to expose it would be welcome"?
[17:50] <maxb> s/not possible/not possible yet/ :-)
[19:14] <micahg> I seem to be having trouble deleting bug watches
[19:28] <micahg> it seems that only admins can delete watches with comments imported
[20:02] <YokoZar> Maybe I'm a complete nit, but has the upstream bug linking been completely moved somewhere?  I can't figure out how to link an upstream bug on edge atm
[20:03] <micahg> YokoZar: also affects project
[20:03] <YokoZar> I click Also Affects Project -> see no place to enter URL for upstream bug (this is where I used to do it).  I click "Also Affects Distribution" and if I paste the link in the url box there I'm told that Ubuntu uses launchpad.
=== matsubara is now known as matsubara-afk
[20:04] <micahg> YokoZar: you need to select the project
[20:05] <YokoZar> micahg: Why?  Launchpad used to figure that automatically from the bug url.  It's also not helpful that Wine is on the 4th page of the search results for "Wine"
[20:05] <micahg> YokoZar: no, it only works if the upstream is set, is this for wine in Ubuntu?
[20:07] <YokoZar> Yeah
[20:08] <micahg> YokoZar: wine or wine1.2?
[20:09] <YokoZar> micahg: ah hah, that's the issue, I hadn't set the upstream project for wine1.2 yet I think
[20:09] <micahg> YokoZar: yep, it's not set
[20:09] <YokoZar> now how to actually do that...
=== salgado is now known as salgado-afk
[20:10] <micahg> YokoZar: I'll take care of it, but it's done on the package page by clicking the set upstream link
=== sale_ is now known as sale
[21:13]  * lamont has a question on archive publishing...
[21:14] <lamont> lets say I had something like https://launchpad.net/ubuntu/+archive/test-rebuild-20090513 and a pile of disk..  does launchpad have the ability to give me an apt repo with the contents of that packaged up pretty, ala archive.u.c?
[21:14] <lamont> wgrant: around?
[21:14] <wgrant> wgrant: I am.
[21:14] <wgrant> lamont: You cannot publish that archive without code changes.
[21:14] <wgrant> Small changes, but changes all the same.
[21:15] <lamont> wgrant: know now that I have a big pile of disk and a fat pipe to the librarian that want to do just that.  sometime this month.
[21:15] <lamont> well, with a copy of lucid, but still.....
[21:15] <lamont> I'd even settle for a chunk of launchpad-lib abusing code to rip URLs to fetch debs and src files from to craft such an archive
[21:16] <wgrant> That disk might well have to be on cocoplum. Let me check.
[21:16] <lamont> mcmurdo, but whatever.
[21:16] <wgrant> I mean, there may be Soyuz limitations that restrict it to being published to cocoplum.
[21:17] <lamont> ah, well.  surviviable
[21:17] <lamont> albeit with much grumbling
[21:18] <wgrant> Although I may be wrong.
[21:18] <lamont> (as in, "I'LL FILE BUGS, dammit....")
[21:18]  * wgrant is hunting.
[21:19] <lamont> ew.  that whole thing is "binary packages awaiting publication"
[21:19] <wgrant> Yes.
[21:19] <wgrant> The key bit is whether process-accepted is running over that yet.
[21:20] <wgrant> It's not.
[21:20] <wgrant> So you could publish it just about anywhere.
[21:20] <lamont> \o/
[21:20] <wgrant> Assuming you can convince Soyuz to schedule it...
[21:20] <lamont> are the steps to do that documented somewhere I can see?
[21:21] <wgrant> It involves hacking some code to allow publishing COPY archives, and mangling DB permissions, so no.
[21:22] <lamont> for this round, I'd accept an SQL query that gave me a dump of what URLs to grab from the librarian and what to call them in the archive...  I'm not picky
[21:22] <lamont> though  doing it with lplib would be far preferable
[21:22] <lamont> to sql, that is
[21:22] <wgrant> You can do it through launchpadlib.
[21:23] <wgrant> But it would make Launchpad cry, I think.
[21:23] <lamont> cry how? load, or because it got left out of the loop?
[21:23] <wgrant> You should really talk to Soyuz and see how quickly they can get this done...
[21:23] <mwhudson> load
[21:23] <wgrant> Load.
[21:23] <lamont> the goal is to temporarily publish that, not permanently...
[21:23] <wgrant> You'd be making tens of thousands of expensive calls.
[21:23] <lamont> 15000 :-D
[21:24] <lamont> that's only 1.5 tens of thousands.
[21:24] <wgrant> *2 due to the two archs?
[21:24] <lamont> oh meh
[21:24] <lamont> *6
[21:24] <lamont> how ugly an sql query would it be?
[21:24] <wgrant> It was only a two-arch rebuild.
[21:25] <lamont> ah, well that's nice of us
[21:25] <lamont> in the future fantasy land, I expect ports will want to play along, too
[21:25] <wgrant> Nobody really want to DoS the distro builders for months.
[21:25] <lamont> yeah - before ports got to play, I'd have to finish up the "let's use the livecd buildd as a buildd when it's not building livecds" thing
[21:26] <lamont> 50% more buildds for ia64/ppc/sparc could do nothing but help
[21:26] <wgrant> Plus ideally restrict the rebuild to a subset of the available builders.
[21:26] <lamont> wgrant: it's not enough that it scores below universe?
[21:27] <wgrant> lamont: Not if you get three long-running builds on the builders at once.
[21:27] <lamont> right
[21:28] <lamont> well, restricted pools should be there soon, we just need to have it htb-ized
[21:28] <lamont> a dedicated subset of buildds for the rebuild-test, and all of the buildds for the main archive.
[21:28] <wgrant> So, the SQL to get what you want isn't terribly difficult.
[21:29] <wgrant> But you might as well just get archivepublisher hacked up to do what you want. It's not that difficult, and would surely make things a little less messy.
[21:29] <wgrant> The need isn't going to go away, so it might as well be fixed properly now.
[21:30] <lamont> who is the right person for me to lean on?
[21:30] <wgrant> bigjools
[21:31] <lamont> cool
[21:31] <lamont> brb
[21:35] <noctiphile> Was it ever determined why after upgrading to 9.10 so many lost their wireless connections?
[21:35] <Ursinha> noctiphile: hmm, I guess you should ask in #ubuntu instead
[21:35] <Ursinha> noctiphile: this is a Launchpad related stuff channel
[21:36] <noctiphile> I'm about to post the problem in Launchpad if there isn't a quick answer to the question.
[21:37] <wgrant> Try asking in #ubuntu.
[21:37] <Ursinha> noctiphile: that's ok, considering Ubuntu bug tracker is in Launchpad :)
[21:37] <wgrant> Launchpad has nothing to do with your wireless!
[21:38] <Ursinha> noctiphile: but still, you'll hardly have your answer here just because this isn't an Ubuntu channel :)
[21:41] <lamont> launchpad doesn't get to use wireless
[21:42] <wgrant> You know, I really hate custom uploads.
[21:42] <wgrant> They make everything so much harder.
[21:43] <persia> custom uploads?
[21:44] <wgrant> Binary uploads that contain stuff like debian-installer or translations tarballs.
[21:45] <wgrant> They way they are implemented is a little inconvenient, as they are only published to disk once, at accept time.
[21:53] <jcastro> kfogel: ping
[21:54] <jcastro> thumper: ping
[21:54] <thumper> jcastro: hi
[21:55] <jcastro> hi!
[21:55] <jcastro> seg|ars is writing an article about launchpad for ars technica
[21:55] <thumper> jcastro: yes...
[21:55] <jcastro> and I need to link him up with you folks, as his deadline got assigned to tonight, he doesn't have time for a full interview, so an insightful quote of somekind would be useful.
[21:56] <thumper> jcastro: quote about what?
[21:56] <jcastro> basically an insight on which aspects of lp you think are the most compelling enablers of collaboration
[21:57] <thumper> hmm...
[21:57] <thumper> when is his deadline?
[21:57] <thumper> jcastro: as in, how many hours?
[21:57] <jcastro> seg|ars: ^^^
[21:57] <seg|ars> thumper: what aspect of LP do you think has had the biggest impact on the way that users collaborate on software development?
[21:57] <seg|ars> I've got until about 10pm
[21:58] <thumper> seg|ars: well, 10pm for me is another 11 hours away, how long do you have?
[21:58] <seg|ars> I have about 8 hours
[21:58] <thumper> ok
[21:59] <thumper> seg|ars: my thoughts come much more from a code hosting point of view, whereas if you asked kfogel he may have others too
[21:59] <seg|ars> that's cool
[21:59] <jcastro> thumper: yeah I was hoping to snag as many of you from different parts as possible
[22:00] <thumper> seg|ars: I think that the way that launchpad can be project focused rather than just person focused helps a lot as it is easy to see branches from other contributors
[22:00] <thumper> seg|ars: bzr integrates really nicely with launchpad, and allows anyone to commit to their own branch
[22:00] <thumper> seg|ars: and still have it related to a project
[22:00] <thumper> seg|ars: the way we have code reviews integrated suggest to developers that they should think about it
[22:01] <thumper> seg|ars: people can propose their branches for merging easily, and the right people get notified
[22:01] <thumper> seg|ars: conversations can then ensue around the proposed changes with a view to getting contributions into mainline
[22:03] <thumper> seg|ars: I have to head out for a bit, but will be around later to address more comments
[22:03] <seg|ars> thanks, I appreciate your comments
[23:51] <thumper> seg|ars: ping
[23:53] <seg|ars> hey
=== jamalta is now known as jamalta-afk