[01:57] <poolie> hi maxb
[02:01] <poolie> spiv i'm trying to qa 813349
[02:01] <poolie> i turned off the importer for now
[02:11] <maxb> Hi poolie
[02:11] <maxb> And, no, I don't know why I'm still awake
[02:11] <poolie> hi max :)
[02:12] <poolie> i'm glad you are; it's good to have a second pair of eyes
[02:12] <poolie> spiv is sick
[02:12] <poolie> but i hope you get to bed eventuall
[02:12] <poolie> you're right, perhaps we should just run from a checkout
[02:52] <poolie> maxb we're on 2.3.4 now
[05:34] <lxsameer> my connection lost in middle of a cloning, how can i resume cloning? (.bzr folder created)
[05:34] <bob2> is it in a shared repository?
[05:39] <lxsameer> bob2: like lp ? yeah
[06:55] <wgrant> spiv: Around?
[06:55] <wgrant> Ah, sick, I see.
[06:55] <vila> hi all !
[06:56] <wgrant> spiv: On the off chance you are watching, inline MP diffs are now switched on on production for ~launchpad.
[06:57] <vila> wgrant, spiv : soooo nice
[07:03] <wgrant> The styles are a bit off for me, but it works!
[07:06] <spiv> wgrant: sweet
[07:07] <spiv> wgrant: I am around today, but working pretty slowly :/
[07:10] <spiv> Hmm, the "loading diff" message could use the little spinner icon.
[07:10] <spiv> And rendering huge diffs makes firefox struggle a fair bit :)
[07:14] <wgrant> spiv: Yeah, but those are tiny tweaks :)
[07:16] <spiv> wgrant: right, incremental improvement FTW :)
[07:25] <jam> morning all
[07:39] <jam> spiv: I thought links that expanded inline were supposed to be green? They are blue on my page.
[07:39] <jam> And yes, a spinner would be nice, I just went to: https://code.launchpad.net/~vila/bzr/rm-tweaks/+merge/68274 and it took quite a while to bring up the diff.
[07:40] <jam> (I'm guessing that is primarily loggerhead loading the cache for the first time of a new branch, which I have fixes for, but all a bit blocked. :)
[07:40] <vila> jam: I just pushed some corrections, may be it made it worse ?
[07:41] <jam> vila: I'm not talking the whole diff, I'm talking SPIV's sexy new "show me the diff of this subset of the changes"
[07:41] <jam> though yes
[07:41] <vila> me too :)
[07:41] <jam> loggerhead will rebuild the history from scratch if the tip changes
[07:41] <jam> which again... fixes available :)
[07:42] <jam> very nice spiv!
[07:48] <spiv> jam: thanks :)
[07:50] <spiv> jam: hmm, yeah, the something about the CSS must have changed.
[07:51] <spiv> Ideally details like showing a spinner and the right style for the expander link will be mostly part of the standard expander.js infrastructure
[07:51] <spiv> Possibly they already are and I'm just not using it quite right.
[07:55] <vila> haa, I just got a slow load, all previous ones were fast, jam, may be you loaded them before me populating the cache ?
[07:55] <jam> vila: right. When loggerhead sees the tip change, it starts from scratch, and walks the whole ancestry
[07:56] <vila> in any case, that would make reviews of intermediate changes far easier (and doable online)
[07:56] <vila> mail reviewers may not benefit from it though...
[08:02] <vila> poolie: The inline diffs should make it easier to re-review rm-tweaks, care to give it a go ?
[08:04] <poolie> hi vila
[08:04] <poolie> what a great idea!
[08:08] <jam> vila: I know there are plans in abentley's head to change the process to be able to send updated diffs along with updated comments
[08:09] <jam> (via email)
[08:09] <jam> but certainly, short term this is good stuff
[08:09] <jam> vila: for the config stuff and verbosity knob
[08:09] <jam> this was actually originally targetted at 2.2
[08:09] <vila> oooh
[08:09] <jam> I'm not sure if we should be thinking about backporting it or not
[08:09] <jam> poolie: any thoughts on "out-of-date" messages?
[08:09] <jam> vila: my first thought is that we should target Natty
[08:10] <jam> since that is where people are writing code for Oneiric
[08:10] <vila> jam: yup, that what I thought too, 2.4
[08:10] <poolie> jam i liked the phrasing in your current diff
[08:10] <jam> vila: isn't natty 2.3?
[08:10] <jam> poolie: thanks. Though the question was meant to be, where should we be trying to get it landed?
[08:10] <vila> jam: oh, right, then no, I think 2.4 is good enough
[08:11] <poolie> i would say 2.4 at first
[08:11] <jam> sure "at first", and maybe Oneiric will be out soon enough we won't backport. But wouldn't 2.3 make sense?
[08:11] <Riddell> good morning all
[08:11] <poolie> spiv, vila, wow, that works very well
[08:11] <vila> poolie: isn't it ? :)
[08:11] <poolie> it depends a bit how confident you are it cannot cause any regressions
[08:12] <poolie> is the option now guaranteed to switch it all the way off?
[08:16] <poolie> vila, oh, i see http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/
[08:17] <poolie> i assume those previous broken builds are due to you futzing with it?
[08:17] <vila> yeah, I finished too late yesterday to write an email
[08:17] <vila> hehe
[08:17] <vila> indeed :)
[08:17] <jam> poolie: it still runs a regex check before it reads the config setting, but otherwise config == 'off' is a shortcut to exiting the hook
[08:17] <vila> I will clean this up today and re-run as a final test and to get a proper history
[08:17] <poolie> ok
[08:17] <poolie> ok
[08:17] <jam> vila: on a different tack, I don't really think branch config is ideal here, vs just a global setting. what do you think?
[08:18] <poolie> if i had to choose, the announcement is more important than having pretty history
[08:18] <poolie> i think global would be ok; we can always refine it later
[08:18] <vila> I think by default we shouldn't restrict to a global setting only, let the user decide
[08:19] <vila> I can imagine some branches where I damn well know I'm out of date and don't want to be nagged endlessly
[08:19] <vila> poolie: you're right, writing the emails now
[08:28] <jelmer> hi jam, poolie, vila
[08:28] <vila> _o/
[08:29] <jelmer> vila: is the upload to lucid-cat of bzr 2.3.4 still necessary?
[08:29] <vila> I wanted 2.4b5, but since we went back to 2.3.4, this will have to wait
[08:30] <vila> jelmer: up to you, but 2.4.0 is not that far away
[08:31] <poolie> hi jelmer
[08:34] <poolie> vila, uh, maybe you should mention the sru jobs?
[08:34] <poolie> also, could we get them to run every 24h or so?
[08:34] <vila> poolie: separate mail for srus
[08:34] <poolie> ok
[08:35] <jelmer> vila: ok
[08:35] <vila> poolie: what would be the point ?
[08:35] <poolie> following up to that 'critical' mail, could someone investigate whether jubany's more happy now, or what needs to be done to get those branches ok again?
[08:35] <poolie> i need to go soon
[08:35] <vila> if we want to automate, I can look into checking the package version
[08:35] <poolie> oh, the point of running every 24h?
[08:35] <vila> yeah
[08:36] <poolie> well, it means there's a fair chance there will be something up to date when i go to look at it
[08:36] <poolie> rather than there being a guarantee i need to ask for a new build
[08:36] <poolie> also, it's probably easier than scripting it?
[08:36] <vila> hmm
[08:36] <vila> right, let's start with every 24h
[08:38] <vila> tweaked
[08:39] <jam> poolie: we have 179 current failures with the associated bug.
[08:40] <jam> However, I don't know what (if any) of the packages you restarted
[08:41] <vila> yeah, we need some log for imports restarted on demand to communicate better there
[08:47] <maxb> Does anyone see a problem with just retrying the entire 179 on the new bzr version and seeing what happens?
[08:48] <vila> no, as long as you start with one or two first maybe ?
[08:49] <jam> maxb: as long as it doesn't set them as always-retry-this-failure
[08:50] <jam> so "retry these, but don't set it as a retry-able failure mode"
[08:50] <jam> vila: other topic, so, switching to use a stack-based config doesn't seem like it adds much, and it makes it harder to backport in the future.
[08:50] <jam> also, I'm not very happy with the config name
[08:50] <jam> but I don't think switching to just "launchpad" is quite right, either
[08:50] <jam> I guess "bzr." is reserved for core bzr ?
[08:50] <vila> jam: not switching means adding tech debt on trunk
[08:50] <jam> vila: barely any, tbh
[08:51] <vila> no, we get rid of 'bzr.' entirely
[08:51] <jam> I don't really see why Branch.get_config() can't return ConfigStack(self)
[08:51] <vila> hehe, just try :)
[08:51] <jam> vila: where are the docs for the naming scheme, because somehow I missed them completely
[08:51] <jam> vila: I realize it doesn't implement the same api today, but if you are worried about tech debt, it doesn't seem to be adding really anything new
[08:52] <jam> it certainly looks amenable to a regex-based fixup later
[08:52] <maxb> requeued anjuta, let's see what happens
[08:52] <vila> jam: http://doc.bazaar.canonical.com/devnotes/configuration.html
[08:53] <jam> vila: Bazaar itself defines all its constants as bzr.option_name or bzr.topic.option_name, in short, the bzr. prefix is reserved for bzr core/bzrlib itself,
[08:53] <jam> quoted from that file
[08:53] <vila> jam: well, if nobody tries the stack-based design, it will never be deployed, I expect special cases to appear while migrating the existing options
[08:53] <maxb> hmm, UDD concurrency is currently set to 1 ?
[08:54] <jam> i do see your mention of dropping bzrlib.plugins
[08:54] <vila> jam: meh, where ?
[08:54] <jam> vila: "package based"
[08:54] <jam> where it says that "Bzr." should be used for core config, and plugins should just use "<plugin>."
[08:55] <vila> jam: read a bit more
[08:55] <vila> 'topic based' and then 'topic based name seems to provide the best compromise'
[08:56] <vila> patches welcome to clarify the wording
[08:56] <jam> might I suggest the PEP style of writing, which puts "possible alternatives" into a different section so that it is obvious they aren't the recommendation ?
[08:58] <jam> vila: "collisions are detected at registration time..." I don't see a registration time
[08:58] <jam> (grepping for the word "register" in config.py)
[08:58] <jam> I believe I remember reviewing some code about that in the past, though
[08:59] <jam> I guess maybe "config.Option" which *I* find confusing vs option.Option
[08:59] <jam> not only that "option.Option" is referenced later in the file as "commands.Option" because of a spurious import coincidence
[09:00] <vila> meh, are we talking about your proposal or do you want to file bugs ?
[09:00]  * maxb raises jubany max_threads back to 8
[09:00] <vila> maxb: any idea who is setting it to 1 ?
[09:01] <maxb> no
[09:01] <jam> vila: I'm trying to make sure I'm understanding everything and things aren't lining up in multiple ways
[09:02] <maxb> I assume it was from smoketesting the change to 2.3.4, but it seems fine
[09:02] <poolie> jam, i have not requeued any packgase
[09:02] <poolie> i set it back to 1
[09:02] <poolie> i'm happy to have it go back up
[09:02] <poolie> ideally with someone keeping an eye on it
[09:02] <maxb> Now we wait and see whether any of what I've requeud fail
[09:02] <vila> jam: Go has an interesting discussion about name spaces: http://goneat.org/doc/effective_go.html#package-names
[09:02] <jam> maxb, poolie: Would we have a good mailing list (udd perhaps) for just posting "I made these changes on Jubany"
[09:03] <jam> as an audit-log of what-and-why things have changed?
[09:03] <maxb> And worry about whether this tag-fetching thing is a mistake :-/
[09:03] <poolie> udd
[09:03] <poolie> that's what i tried to do today, though perhaps not in enough detail
[09:03] <poolie> (like not mentioning the max threads thing)
[09:03] <jelmer> vila: is it possible to see which version was installed on babune in the new -proposed jobs?
[09:03] <poolie> i think probably user-type discussion should be on ubuntu-devel and ops/development on u-d-d
[09:04] <poolie> you guys should all join u-d if for some reason you have not already
[09:04] <vila> jelmer: it's displayed at the *end* of the job console
[09:04] <jam> poolie: I have not, but I'm a bit concerned it will just be a bunch of emails that I don't read
[09:04] <vila> jelmer: http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/lastSuccessfulBuild/console and scroll down
[09:04] <jam> I get plenty of those from being in ~launchpad as it is
[09:05] <maxb> So far we have numerous successes, but one failure with "missing text keys"
[09:05] <jelmer> vila: but that output happened *before* the tests ran?
[09:05] <poolie> jam, it's not that much
[09:05] <vila> jelmer: yeah, blame jenkins stderr handling, I'll change it to try to get it at the *start* of the output
[09:06] <vila> jelmer: but that won't be as good as having it displayed more pro-eminently (I have some ideas but need some tests)
[09:06] <jelmer> vila: it's not a big deal, I'm just surprised :)
[09:06] <vila> jelmer: do was I ;-)
[09:06] <vila> s/do/so/
[09:55] <vila> jelmer: are you using a script to mark the sru bugs verification-done ? Or do you do that manually ?
[09:55] <jelmer> vila: I'm doing it manually.
[09:56] <vila> k
[10:18] <Riddell> vila: should we do some more patch pilot today?
[10:20] <vila> Riddell: my plan for today is to write the summary mail before leaving (I'm out next week)
[10:20] <vila> Riddell: did you have a specific item to discuss ?
[10:21] <Riddell> vila: no, I just haven't looked at any since we did it on tuesday so I don't know if there are more patches to pilot
[10:22] <vila> ok, I haven't seen any  requiring pp (imbw)
[10:22] <Riddell> imbw?
[10:22] <vila> I May Be Wrong
[10:22] <vila> I always can ;)
[11:21] <maxb> Looks like 2.3.x has effectively fixed all of the BzrCheckErrors on jubany (though the queue is still draining)
[11:25] <jelmer> maxb: I guess that's a relief and worrying at the same time :-/
[11:25] <maxb> It does strongly suggest we should be considering making the fetch-tags behaviour optional in 2.4
[11:26] <jelmer> maxb: I agree we should make it optional
[11:26] <jelmer> maxb: it would be nice to actually fix the underlying problem though
[11:26] <maxb> Well, sure
[11:27] <maxb> Unfortunately the complexity of this underlying problem exceeds my current knowledge of bzr internals :-/
[11:47] <vila> jelmer, maxb : I agree with making tag fetching optional in 2.4, 2.4.0 freeze is planned for 2011-08-04, time is running short :-/
[11:48] <jelmer> ah, hmm
[11:49] <jelmer> we should at least make sure we have bug reports about these issues
[11:50] <spiv> maxb: you only need to understand how stacking works in the context of repositories with unconfigured fallbacks in the smart server and how that supports O(changes) fetches and a rough idea how CHK maps work :P
[11:50] <jam> vila, jelmer: bug #806348 is a fairly large regression for bzr2.4 vs bzr-2.3
[11:50] <ubot5> Launchpad bug 806348 in Ubuntu Distributed Development "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [High,In progress] https://launchpad.net/bugs/806348
[11:50] <jam> if we can't fix it, we need to back it out, disable-it-by-default
[11:50] <jam> spiv: yeah, the interactions of stacking + everything else has never been much fun
[11:50] <spiv> Just ban tags that are in the ancestry of tip ;)
[11:51] <jam> adding that RemoteRepo acts differently than local Repo is not good
[11:51] <jam> I think we should make it so that Local stacked repositories don't proxy, and see what falls out.
[11:51] <vila> spiv: what's your gut feeling about being able to fix it for 2.4.0 ?
[11:52] <vila> well, for 29/07 even :)
[11:52] <spiv> :)
[11:52] <vila> ':)' is a good gut feeling, I feel relieved :-p
[11:52] <spiv> I'm hoping there's a cheap fix or at least mitigation we can do.
[11:53] <spiv> It feels like the sort of thing we might be able to recover from more gracefully than just giving up with a BzrCheckError
[11:53] <jam> spiv: add a config variable, default it to false?
[11:53] <spiv> jam: well, that's a good fallback option
[11:54] <spiv> (and also helps with the 'unrelated tags cause bloated fetches' bug/feature)
[11:55] <spiv> But in principle the client knows what is missing, and knows where to find that data
[11:55] <Lo-lan-do> Hi all :-)
[11:55]  * Lo-lan-do is back to haunt jelmer *again*
[11:55] <spiv> It could and probably should do something more helpful than "sorry, I only got 99.9% of the data I need, I'm gonna barf."
[11:56] <Lo-lan-do> Same context as usual, we did a release of FusionForge, and the discussion is again coming to whether we should switch to git or not.
[11:57] <spiv> (Funnily enough it already does more-or-less that when it doesn't initially receive the parent inventories needed to make a viable stacked repository...)
[11:57] <Lo-lan-do> So, jelmer, do you have any light to shed on the whenabouts of "bzr push" to git repositories?  Or how to work with bzr (and plenty of local braches) when the main repository is git?
[12:00] <jelmer> hi Lo-lan-do
[12:01] <jelmer> Lo-lan-do: we've been making some progress on support for colocated branches and accessing colocated branches in git
[12:01] <jelmer> Lo-lan-do: not so much on support for "bzr push" to git repositories, I haven't been able to spend much time on it, mainly focussing on fixing bugs
[12:04] <Lo-lan-do> 'kay.  But if I have local branches in bzr, how hard/disruptive will it be to push them upstream?  Will I need horrible amounts of rebasing?
[12:07] <jelmer> Lo-lan-do: that really depends on the workflow - is there going to be a gatekeeper, is everybody going to push patches directly on the mainline, or are you going to merge things into the mainline?
[12:10] <Lo-lan-do> The workflow is I have several bzr branches for clients.  For the sake of this discussion, I'm their only user.
[12:11] <Lo-lan-do> When one of them is stable, I rebase it onto upstream (svn currently) and push it to trunk.
[12:11] <Lo-lan-do> It occurs to me that there's already some rebasing needed, so maybe my worries are not really justified.
[12:12] <jelmer> Lo-lan-do: I think it would be about the same amount of rebasing as you would if you used git
[12:12] <Lo-lan-do> The upstream repository is shared between all developers.
[12:14] <jelmer> Lo-lan-do: would they push merges into the upstream repository when landing a branch, or rebase branches they land onto trunk?
[12:14] <Lo-lan-do> No idea.  Maybe both :-)
[12:16] <Lo-lan-do> Other question: can I push from a bzr branch into a git branch other than the "master" branch?
[12:17] <jelmer> Lo-lan-do: not yet (that's what the bug fix work related to colocated branches is about)
[12:18] <Lo-lan-do> Ah, I see.
[12:38] <Lo-lan-do> jelmer: Any rough idea of when?
[12:40] <jelmer> Lo-lan-do: I'm a bit hesitant to give estimates; this work had been stalled for a while and we've just resolved one of the blockers. It touches some pretty core routines though, so I'm not sure what else we'll hit.
[12:41] <Lo-lan-do> No problem.
[12:42] <Lo-lan-do> I guess I can live with only using master for a while anyway (we don't plan on branching again right away).
[12:54] <Lo-lan-do> I haven't followed everything, but is bzr-git updated regularly in sid or do I need to track upstream?
[13:05] <jelmer> Lo-lan-do: semi-regularly, I'm not sure how up to date the current version in git is
[13:12] <Lo-lan-do> 'kay.  Thanks for the info :-)
=== med_out is now known as medberry
=== beuno is now known as beuno-lunch
=== deryck is now known as deryck[lunch]
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
=== medberry is now known as med_out
=== yofel_ is now known as yofel
[21:07] <lxsameer> my connection lost in middle of a bzr branch process how can i resume that?
[21:15] <jelmer> lxsameer: if you branched into a repository then you can just remove the branch and restart; I think it'll continue where it left off
[21:16] <lxsameer> jelmer: what do you mean? removing the directory cause all the downloaded data to be remove
=== med_out is now known as medberry