=== MTecknology is now known as NoNickAssigned
=== NoNickAssigned is now known as MTecknology
[07:17] <mvl> hi, I have a question on merge proposals
[07:18] <mvl> in https://help.launchpad.net/Code/Review, it says that on the branches' overview page, there should be a link "Propose for merging into another branch"
[07:19] <mvl> however, I can't find the link on my branch. How can I propose it for merging?
[07:19] <lifeless> what page are you looking at ?
[07:19] <mvl> https://code.launchpad.net/~martin-v/+junk/zconfig-ipv6
[07:19] <lifeless> ah
[07:20] <lifeless> its a junkcode branch - thats a scratch space, and doesn't support things like merge proposals
[07:20] <lifeless> AIUI
[07:20] <mvl> so how can I create one that will support that?
[07:21] <lifeless> what branch did you want to have your branch merged into ?
[07:21] <mvl> https://code.launchpad.net/~fdrake/zconfig/trunk
[07:23] <mvl> perhaps I just push to ~martin-v/zconfig/ipv6?
[07:25] <mvl> Indeed that seems to work - thanks!
[07:27] <lifeless> yes, thats how you do it
[07:28] <mvl> how can I have bzr change the saved push location?
[07:29] <lifeless> --remember
[07:30] <mvl> thanks!
[07:54] <micahg> lifeless: did LP change the way it sends files?  .txt files are now prompting for an external helper
[07:55] <lifeless> micahg: on private bugs yes
[07:56] <micahg> lifeless: ah, ok, then is that correct, or should I file a bug?
[07:56] <persia> Would that persist if a bug was initially private, but made unprivate?
[07:56] <lifeless> micahg: its a stop-gap, we'll be changing it again in a week or three, and then it will be permitted to be inline again.
[07:56] <micahg> lifeless: k, so no bug then, right?
[07:56] <lifeless> micahg: its correct; they are being serfved from the lp.net domain, so to prevent attacks on your LP cookies we set content-disposition:attachment
[07:57] <lifeless> no bug needed, there's already one about the underlying mechanics
[07:58] <micahg> lifeless: thanks
[07:58] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/395960
[07:58] <ubot5`> Launchpad bug 395960 in Launchpad Foundations "proxying user supplied files via the launchpad appserver domain has security and performance issues (affected: 1, heat: 9)" [High,Fix committed]
[08:00] <lifeless> persia: if the attachments were left 'restricted'
[08:00] <lifeless> persia: if you've observed this, you can tell - there won't be a redirect when you access it, and it will have cd:attachment
[08:00] <lifeless> persia: if so, this is a bug - please file it.
[08:01] <micahg> lifeless: can we have public bug and private attachments yet?
[08:01] <persia> I've not observed it, just curious.  Easy way to check would be the apport-reported bugs in Ubuntu, but one would presumably want to use bugs submitted on selected dates.
[08:02] <persia> I'm not sure I'll notice, as my browser tends to treat everything (even on public bugs) from LP as something to either save or launch in an external reader.
[08:02] <persia> (and doesn't obviously show redirect in the process)
[08:03] <lifeless> micahg: no, the bug and the attachment privacy is intended to be the same
[08:03] <micahg> lifeless: oh, ok, well, when we switch a bug from public to private, the attachments change as well now?
[08:04] <lifeless> micahg: they should yes
[08:04] <micahg> lifeless: cool
[08:04] <lifeless> again, if they don't, tis a bug.
[08:04] <lifeless> they are sadly stored as separate bits
[08:04] <lifeless> its denormalisedish
[08:04] <lifeless> I would file a bug, but frankly I don't care until performance is fixed ;)
[08:06] <persia> And there's a certain advantage to having unfiled bugs: old bugs that weren't important for a while become hard to show as currently important, even as priorities change, just because of their age.
[08:08] <lifeless> persia: I don't subscribe to that approach :)
[08:09] <lifeless> if bug reports are recording defects, the age of a report just says how long the defect has existed
[08:11] <persia> Hrm.  In principle I agree with you.  Tactically, sometimes I find the other effective.
[08:12] <persia> (but I tend to reserve that tactic for when I also have an underabundance of time)
[08:46] <lucidfox> So, I've heard about the Opinion status, but it seems like it closes the bug
[08:47] <micahg> lucidfox: yes, it's a final status
[08:47] <lucidfox> What status should I use for "I don't feel it's a genuine bug, but I'll change behavior is requested if enough users agree with the original poster"?
[08:47] <micahg> lucidfox: wouldn't that be a wishlist?
[08:49] <lucidfox> Well, it's an issue of split opinion on UI design. The bug author wants me to change the UI in a certain way, I think it isn't warranted (so I'm not going to work on it for now), but I'm ready to adhere to the users' wishes if they are on the author's side.
[08:49] <micahg> lucidfox: you can set it to opinion and subscribe
[08:49] <micahg> and change it back when you're ready to fix it
[08:49] <micahg> or mark it triaged with a note in the description
[08:50] <lucidfox> If I set it to opinion, 95% users browsing the bugtracker won't be able to see it
[08:50] <persia> Just out of curiosity, is the rationale for why we want "opinion" instead of being able to use "Traiged" and "Won'tFix" on wishlist bugs documented somewhere?
[08:50] <micahg> lucidfox: so, wishlist/triaged with a disclaimer might make more sense
[08:50] <persia> Or wishlist/Won'tFix
[08:51] <lucidfox> Won't Fix will close it too
[08:51] <persia> Maybe the issue is that we don't have a good way to expose things that need discussion, nor a really good place to discuss them.
[08:51] <micahg> persia: http://blog.launchpad.net/bug-tracking/new-bugs-status-opinion
[08:52] <lucidfox> Yes, and I sort of agree with the opinion of the commenters: "Do we need yet *another* "ignored" status?"
[08:52] <persia> Ah, OK.  I'm unsure about the semantics, but I think it's a bug if these don't show in the list by default.
[08:53] <micahg> persia: well, it's meant to be a final state
[08:53] <persia> They ought only be ignored by the maintainers of the project that isn't going to address them, and anyone maintaining a project has advanced techniques to preserve precious ignorance in the interest of getting anything done
[08:54] <persia> micahg, That's the part I don't understand: if discussion is continuing, it ought be moving towards Fix Released or Won't Fix.  If it's not, that's a waste of human thought, and this is one of our greatest resources.
[08:55] <persia> Nice to have a place to discuss stuff, but if the discussion is intended at the outset to be pointless, I don't see any value to it having existed (and I do see penalties to having the discussion if it is intended to be ignored)
[08:55] <lucidfox> In Ubuntu, so far, it seems Opinion de facto means "Mark says it will stay this way, move on"
[08:55] <persia> Which is actively harmful.
[08:56] <persia> All the folks discussing stuff on the bug would do better to focus on other things, and even if they really, really, really want to address the issue under discussion, to completely ignore that bug, and go do something differently.
[08:56] <micahg> persia: well, it seems like like it's meant to stay opinion barring a change of heart on the part of the devs, so it's pretty final
[08:56] <persia> Whereas if "Opinion" was a state intended to wait for consensus, and move forward after some time, it makes sense to use it occasionally.
[08:57] <lucidfox> Not all developers are equally uptight about their opinions. I, for one, feel ready to cater to the majority of my users even if I personally disagree with them.
[08:58] <persia> micahg, It's just a matter of how we define the semantics.  If we (and the LP documentors) agree that the status is intended to be temporary whilst discussion occurs, and an alternative to "Incomplete", I think there is value.  Otherwise, how is it better than "Won't Fix" except in the perception of folks reading it?  Same benefit would be gotten by changing the string attached to "Won't Fix"
[08:58] <micahg> persia: I think that is exactly the point, it's perception
[08:58]  * persia is *very* opinionated, and won't sway to a majority, but is always happy to be convinced that another viewpoint is either valid or even preferable
[08:59] <persia> micahg, So, if it's just about semantic perception of "Won't Fix", we are actively destroying the value of our Bug DB by having two different status values.
[08:59] <persia> Because there's no semantic distinction.
[08:59] <micahg> persia: and hence the opinion about it on -devel :)
[08:59] <persia> But I think that some upstreams (like lucidfox) would actively use it as a non-final value.
[09:00] <persia> And I'm not sure there aren't some bugs where there is a place for this in Ubuntu as well (although we tend to just push upstream, and let the discussion happen there)
[09:01] <lifeless> lucidfox: opinion would be appropriate for that
[09:01] <lifeless> lucidfox: 'final until enough people argue' - same as wontfix in that regard :)
[09:02] <persia> lifeless, Any thoughts on showing "Opinion" bugs in the default lists so that users can more easily find them and participate in those discussions?
[09:02] <lucidfox> No, it's not. For me, "Won't Fix" means "I'm not going to change it, it's final, move on."
[09:02]  * persia too
[09:03] <lucidfox> What I'd like to see is an "open opinion" status that means "I'll change it if enough people ask for it."
[09:03] <lifeless> persia: hmm, AIU the story, that might help (it would avoid dups)
[09:04] <persia> lifeless, Oh cool.  Is deryk still the right person to pester about this?
[09:04] <lifeless> persia: of course; or provide a patch
[09:04] <lifeless> lucidfox: theres a strong pressure not to have many status values
[09:04] <persia> Give me a pointer to the right area of code: if I can get a patch before koffice either fails to build again or finishes building, I'll post it.
[09:05] <lifeless> lucidfox: and instead have just enough buckets to get by, to aid with the learning curve.
[09:05] <persia> (since it's been a couple weeks that koffice has been doing this, this isn't necessarily a short amount of time)
[09:05] <lifeless> persia: ah, I don't precisely know; I think there is a set of status that are 'shown by default' and the patch might be as simple as adding it to that set
[09:05] <lifeless> persia: that set would be in lib/lp/bugs/model/* or bugs/interface/*, in all probability
[09:05] <persia> That's what I thought.  I'm just not at *all* familiar with the Malone code.
[09:06] <persia> Ah, cool.  I'll take a look.  Thanks.
[09:08] <lifeless> persia: grepping for -i FIX_?COMMITTED would be a good start
[09:08] <persia> You presume I have the code in a place I can grep.  My last checkout is ~9 months old, and on a disused VM, and it took *two days* for me to actually get the code there.
[09:09] <lifeless> ><
[09:09] <lifeless> google code search?
[09:10] <persia> Grabbing subsets of files from loggerhead isn't that bad, just means the usual grep -rin isn't helpful.
[09:10] <persia> (have I mentioned that I think bzr needs better optimisation for folks with high bandwidth and high latency)
[09:11] <lifeless> persia: bzr itself handles that ok in all the tests we've tried; there is a firewall that ~ 3 months back james said -may- have kernel issues with long-fat-pipes
[09:11] <lifeless> we're waiting for confirmation that that is on lucid before investigating further.
[09:12] <persia> I've never seen more than ~300K/s from bzr on lp:/ trees.  I regularly get ~10Mb/s from other things in the Canonical DC.
[09:12] <lifeless> which things
[09:12] <persia> people.ubuntu.com, ports.ubuntu.com cdimage.ubuntu.com, etc.
[09:12] <lifeless> AIUI various front end servers are in front of this firewall
[09:12] <lifeless> like cdimage :)
[09:12] <persia> And probably the others :)
[09:13] <persia> But still, factor of 30 makes it painful
[09:13] <lifeless> yes
[09:13] <lifeless> bzr can exceed that, we know that
[09:13] <lifeless> why its not in this situation is ... perplexing
[09:13] <persia> With ~300ms latencies?
[09:13] <lifeless> persia: once it finishes the chatter its one-way streaming
[09:14] <persia> Ah, hrm.  I can see why it's perplexing.
[09:14] <persia> (although in my somewhat extreme case, I can usually download and unpack something from archive.ubuntu.com faster than I can complete the bzr chatter to loggerhead)
[09:15] <persia> For most packages, 6 times back&forth, assuming no transmission time (short messages),and no processing time is too long.
[09:15] <persia> And bzr seems to be 8-10.
[09:15] <lifeless> anyhow
[09:15] <persia> (not that I'd complain if the 10 happened in 5 seconds or so)
[09:16] <persia> Yeah, completely off-topic: back to the patch :)
[09:16] <lifeless> I'm aware of it, but its not top rung yet.
[09:16] <lifeless> one thing that I'm very excited about is a 2.5 second reduction in handshake time for bzr connections
[09:16] <lifeless> thats coming up soon
[09:17] <persia> What is that 2.5s?  processing time?  transit times?  processor idle?
[09:17] <lifeless> python load time
[09:17] <persia> Oh, heh, that will be nice.
[09:30] <persia> lucidfox, Bug #642637
[09:30] <ubot5`> Launchpad bug 642637 in Launchpad Bugs "Opinion should be visible by default (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/642637
[09:31] <lucidfox> Danke
[09:31]  * lucidfox subscribes
[09:33] <persia> No, thank you for raising the issue (and lifeless for identifying the offending code).  The patch itself is trivial.
=== yofel_ is now known as yofel
[11:31] <mdke> hi there. I can't seem to push to LP
[11:31] <mdke> matt@matt-laptop:~/ubuntu-docs/maverick$ bzr push lp:ubuntu-docs/maverick
[11:31] <mdke> bzr: ERROR: Connection error: Couldn't resolve host 'xmlrpc.launchpad.net' [Errno -2] Name or service not known
[11:31] <mdke> is this a problem on my end or have others seen it?
[11:32] <mdke> actually, looks like an issue with my internet connection, nm
=== bpeel is now known as bpeel_away
=== bpeel_away is now known as bpeel
=== bpeel is now known as bpeel_away
[17:28] <lucidfox> Is there some kind of magic string that the Launchpad translation manager will automatically translate into the language name?
[17:29] <lucidfox> either in English or in that language itself
=== yofel_ is now known as yofel
=== bpeel_away is now known as bpeel
=== Meths_ is now known as Meths
[19:48] <JamUnix> a question: I deleted my old Launchpad GPG key to sign the Code of Conduct in 2005 and add a new last night ..... should remove the code of conduct and strong (with the old key )???? and sign again with the new key that newly added launchpad
[20:47] <lucidfox> JamUnix> No need to
=== dendrobates is now known as dendro-afk
[22:08] <fta> would it be possible to re-allocate a few lpia builders to clear up the queue? i've been waiting for more than a week for some builds to even start
[22:09] <fta> https://edge.launchpad.net/~chromium-daily/+archive/dev/+packages
=== dendro-afk is now known as dendrobates
[22:16] <lifeless> fta: please use the question system
[22:17] <lifeless> let me know the # and I'll point a sysadmin at it
=== lifeless changed the topic of #launchpad to: http://launchpad.net/ | Read https://help.launchpad.net/ for help | Help contact: - |  Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[22:32] <wgrant> fta: The build queue looks pretty much empty now.
[22:33] <wgrant> Although it was bad last week.
[22:33] <micahg> yeah, if there was just 1 more lpia builder, it would be < 24 hrs
[22:33] <fta> wgrant, indeed, but just 2 lpia builders for the last 10 days, that clearly not enough
[22:34] <fta> +'s
[22:34] <wgrant> fta: Oh, you want more builders *on* lpia.
[22:34] <wgrant> That's easy for an admin to do.
[22:35] <fta> i should drop some dists, but i still needs some stats to decide how many users i'll break
[22:35] <fta> -s
[22:35] <wgrant> I need to check why the stats script still isn't running.
[22:36] <fta> that was bug 139855
[22:36] <ubot5`> Launchpad bug 139855 in Soyuz "Display stats about PPA usage (affected: 29, heat: 214)" [Low,In progress] https://launchpad.net/bugs/139855
[22:39] <mtaylor> mmm. launchpad down?
=== dendrobates is now known as dendro-afk
[22:55] <mwhudson> mtaylor: which bit?
[22:57] <mtaylor> mwhudson: seems to be back - I'm gonna blame my internets
[22:57] <lifeless> mtaylor: rolling reboots just now
[22:58] <lifeless> mtaylor: what error did you encounter?
[22:58] <lifeless> so that I can make sure we have a bug to make this seamless
[22:58] <mtaylor> lifeless: well, I tried doing an apt-get update with ppas in my sources.list and those were all missing
[22:59] <mtaylor> lifeless: then I tried to get to my drizzle bug list, and that just hung
[22:59] <mtaylor> lifeless: so then I stopped trying things
[22:59] <mtaylor> lifeless:  oh - ppa apt sources still not reachable
[23:00] <lifeless> ok, that one we know about
[23:00] <lifeless> SPOF at the moment - its a somewhat large dataset, all the PPAs.
[23:00] <mtaylor> fair enough
[23:01] <wgrant> It's a bit sad, since it has an awful lot of automated clients.
[23:01] <mtaylor> lifeless: I have _NO_ idea how that bit of the architecture works, but does that bit need to be dynamic? seems like http://ppa.launchpad.net/yorba/ppa/ubuntu/dists/lucid/main/i18n/Translation-en.bz2 could just be a static file on a bank of web servers that rolling upgrades wouldn't need to care about?
[23:02]  * mtaylor likes tossing out solutions without fully understanding problems
[23:02] <wgrant> There's not much to the architecture...
[23:02] <lifeless> mtaylor: its the data seize
[23:02] <lifeless> mtaylor: *size*
[23:03] <wgrant> Sounds like the librarian.
[23:03] <lifeless> won't fit on the bulk volume machines; long term stuff is being done.
[23:03] <mtaylor> lifeless: well, I get that there's a lot of data there, but when you roll out new launchpad code, what needs to be restarted that would cause Translation-en.bz2 to be unreachable?
[23:03] <mtaylor> ok
[23:03] <lifeless> mtaylor: the kernel.
[23:04] <mtaylor> ah - and I'm guessing it's not just duplicated and sharded across bunches of dumb-ass web server cloud server machines
[23:04]  * mtaylor will butt out ...
[23:04] <lifeless> right, because the dataset is too large without sharding and we dont' have sharding on this thing
=== bpeel is now known as bpeel_away
[23:24] <mwhudson> mtaylor: ppa.lp.net is back now
[23:25] <mtaylor> mwhudson: w00t. thanks
=== jfroy_ is now known as jfroy
[23:29] <coryclaxon> Anyone know why the PPA servers are down?
[23:30] <jpds> coryclaxon: They're back now.
[23:30] <mtaylor> coryclaxon: they should be back
[23:30] <coryclaxon> oh ok
[23:30] <coryclaxon> ty