pooliehi maxb01:57
pooliespiv i'm trying to qa 81334902:01
pooliei turned off the importer for now02:01
maxbHi poolie02:11
maxbAnd, no, I don't know why I'm still awake02:11
pooliehi max :)02:11
pooliei'm glad you are; it's good to have a second pair of eyes02:12
pooliespiv is sick02:12
pooliebut i hope you get to bed eventuall02:12
poolieyou're right, perhaps we should just run from a checkout02:12
pooliemaxb we're on 2.3.4 now02:52
lxsameermy connection lost in middle of a cloning, how can i resume cloning? (.bzr folder created)05:34
bob2is it in a shared repository?05:34
lxsameerbob2: like lp ? yeah05:39
wgrantspiv: Around?06:55
wgrantAh, sick, I see.06:55
vilahi all !06:55
wgrantspiv: On the off chance you are watching, inline MP diffs are now switched on on production for ~launchpad.06:56
vilawgrant, spiv : soooo nice06:57
wgrantThe styles are a bit off for me, but it works!07:03
spivwgrant: sweet07:06
spivwgrant: I am around today, but working pretty slowly :/07:07
spivHmm, the "loading diff" message could use the little spinner icon.07:10
spivAnd rendering huge diffs makes firefox struggle a fair bit :)07:10
wgrantspiv: Yeah, but those are tiny tweaks :)07:14
spivwgrant: right, incremental improvement FTW :)07:16
jammorning all07:25
jamspiv: I thought links that expanded inline were supposed to be green? They are blue on my page.07:39
jamAnd 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:39
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
vilajam: I just pushed some corrections, may be it made it worse ?07:40
jamvila: 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
jamthough yes07:41
vilame too :)07:41
jamloggerhead will rebuild the history from scratch if the tip changes07:41
jamwhich again... fixes available :)07:41
jamvery nice spiv!07:42
spivjam: thanks :)07:48
spivjam: hmm, yeah, the something about the CSS must have changed.07:50
spivIdeally details like showing a spinner and the right style for the expander link will be mostly part of the standard expander.js infrastructure07:51
spivPossibly they already are and I'm just not using it quite right.07:51
vilahaa, I just got a slow load, all previous ones were fast, jam, may be you loaded them before me populating the cache ?07:55
jamvila: right. When loggerhead sees the tip change, it starts from scratch, and walks the whole ancestry07:55
vilain any case, that would make reviews of intermediate changes far easier (and doable online)07:56
vilamail reviewers may not benefit from it though...07:56
vilapoolie: The inline diffs should make it easier to re-review rm-tweaks, care to give it a go ?08:02
pooliehi vila08:04
pooliewhat a great idea!08:04
jamvila: I know there are plans in abentley's head to change the process to be able to send updated diffs along with updated comments08:08
jam(via email)08:09
jambut certainly, short term this is good stuff08:09
jamvila: for the config stuff and verbosity knob08:09
jamthis was actually originally targetted at 2.208:09
jamI'm not sure if we should be thinking about backporting it or not08:09
jampoolie: any thoughts on "out-of-date" messages?08:09
jamvila: my first thought is that we should target Natty08:09
jamsince that is where people are writing code for Oneiric08:10
vilajam: yup, that what I thought too, 2.408:10
pooliejam i liked the phrasing in your current diff08:10
jamvila: isn't natty 2.3?08:10
jampoolie: thanks. Though the question was meant to be, where should we be trying to get it landed?08:10
vilajam: oh, right, then no, I think 2.4 is good enough08:10
pooliei would say 2.4 at first08:11
jamsure "at first", and maybe Oneiric will be out soon enough we won't backport. But wouldn't 2.3 make sense?08:11
Riddellgood morning all08:11
pooliespiv, vila, wow, that works very well08:11
vilapoolie: isn't it ? :)08:11
poolieit depends a bit how confident you are it cannot cause any regressions08:11
poolieis the option now guaranteed to switch it all the way off?08:12
poolievila, oh, i see http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/08:16
pooliei assume those previous broken builds are due to you futzing with it?08:17
vilayeah, I finished too late yesterday to write an email08:17
vilaindeed :)08:17
jampoolie: it still runs a regex check before it reads the config setting, but otherwise config == 'off' is a shortcut to exiting the hook08:17
vilaI will clean this up today and re-run as a final test and to get a proper history08:17
jamvila: on a different tack, I don't really think branch config is ideal here, vs just a global setting. what do you think?08:17
poolieif i had to choose, the announcement is more important than having pretty history08:18
pooliei think global would be ok; we can always refine it later08:18
vilaI think by default we shouldn't restrict to a global setting only, let the user decide08:18
vilaI can imagine some branches where I damn well know I'm out of date and don't want to be nagged endlessly08:19
vilapoolie: you're right, writing the emails now08:19
jelmerhi jam, poolie, vila08:28
jelmervila: is the upload to lucid-cat of bzr 2.3.4 still necessary?08:29
vilaI wanted 2.4b5, but since we went back to 2.3.4, this will have to wait08:29
vilajelmer: up to you, but 2.4.0 is not that far away08:30
pooliehi jelmer08:31
poolievila, uh, maybe you should mention the sru jobs?08:34
pooliealso, could we get them to run every 24h or so?08:34
vilapoolie: separate mail for srus08:34
jelmervila: ok08:35
vilapoolie: what would be the point ?08:35
pooliefollowing 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
pooliei need to go soon08:35
vilaif we want to automate, I can look into checking the package version08:35
poolieoh, the point of running every 24h?08:35
pooliewell, it means there's a fair chance there will be something up to date when i go to look at it08:36
poolierather than there being a guarantee i need to ask for a new build08:36
pooliealso, it's probably easier than scripting it?08:36
vilaright, let's start with every 24h08:36
jampoolie: we have 179 current failures with the associated bug.08:39
jamHowever, I don't know what (if any) of the packages you restarted08:40
vilayeah, we need some log for imports restarted on demand to communicate better there08:41
maxbDoes anyone see a problem with just retrying the entire 179 on the new bzr version and seeing what happens?08:47
vilano, as long as you start with one or two first maybe ?08:48
jammaxb: as long as it doesn't set them as always-retry-this-failure08:49
jamso "retry these, but don't set it as a retry-able failure mode"08:50
jamvila: 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
jamalso, I'm not very happy with the config name08:50
jambut I don't think switching to just "launchpad" is quite right, either08:50
jamI guess "bzr." is reserved for core bzr ?08:50
vilajam: not switching means adding tech debt on trunk08:50
jamvila: barely any, tbh08:50
vilano, we get rid of 'bzr.' entirely08:51
jamI don't really see why Branch.get_config() can't return ConfigStack(self)08:51
vilahehe, just try :)08:51
jamvila: where are the docs for the naming scheme, because somehow I missed them completely08:51
jamvila: 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 new08:51
jamit certainly looks amenable to a regex-based fixup later08:52
maxbrequeued anjuta, let's see what happens08:52
vilajam: http://doc.bazaar.canonical.com/devnotes/configuration.html08:52
jamvila: 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
jamquoted from that file08:53
vilajam: well, if nobody tries the stack-based design, it will never be deployed, I expect special cases to appear while migrating the existing options08:53
maxbhmm, UDD concurrency is currently set to 1 ?08:53
jami do see your mention of dropping bzrlib.plugins08:54
vilajam: meh, where ?08:54
jamvila: "package based"08:54
jamwhere it says that "Bzr." should be used for core config, and plugins should just use "<plugin>."08:54
vilajam: read a bit more08:55
vila'topic based' and then 'topic based name seems to provide the best compromise'08:55
vilapatches welcome to clarify the wording08:56
jammight 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:56
jamvila: "collisions are detected at registration time..." I don't see a registration time08:58
jam(grepping for the word "register" in config.py)08:58
jamI believe I remember reviewing some code about that in the past, though08:58
jamI guess maybe "config.Option" which *I* find confusing vs option.Option08:59
jamnot only that "option.Option" is referenced later in the file as "commands.Option" because of a spurious import coincidence08:59
vilameh, are we talking about your proposal or do you want to file bugs ?09:00
* maxb raises jubany max_threads back to 809:00
vilamaxb: any idea who is setting it to 1 ?09:00
jamvila: I'm trying to make sure I'm understanding everything and things aren't lining up in multiple ways09:01
maxbI assume it was from smoketesting the change to 2.3.4, but it seems fine09:02
pooliejam, i have not requeued any packgase09:02
pooliei set it back to 109:02
pooliei'm happy to have it go back up09:02
poolieideally with someone keeping an eye on it09:02
maxbNow we wait and see whether any of what I've requeud fail09:02
vilajam: Go has an interesting discussion about name spaces: http://goneat.org/doc/effective_go.html#package-names09:02
jammaxb, poolie: Would we have a good mailing list (udd perhaps) for just posting "I made these changes on Jubany"09:02
jamas an audit-log of what-and-why things have changed?09:03
maxbAnd worry about whether this tag-fetching thing is a mistake :-/09:03
pooliethat's what i tried to do today, though perhaps not in enough detail09:03
poolie(like not mentioning the max threads thing)09:03
jelmervila: is it possible to see which version was installed on babune in the new -proposed jobs?09:03
pooliei think probably user-type discussion should be on ubuntu-devel and ops/development on u-d-d09:03
poolieyou guys should all join u-d if for some reason you have not already09:04
vilajelmer: it's displayed at the *end* of the job console09:04
jampoolie: I have not, but I'm a bit concerned it will just be a bunch of emails that I don't read09:04
vilajelmer: http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/lastSuccessfulBuild/console and scroll down09:04
jamI get plenty of those from being in ~launchpad as it is09:04
maxbSo far we have numerous successes, but one failure with "missing text keys"09:05
jelmervila: but that output happened *before* the tests ran?09:05
pooliejam, it's not that much09:05
vilajelmer: yeah, blame jenkins stderr handling, I'll change it to try to get it at the *start* of the output09:05
vilajelmer: but that won't be as good as having it displayed more pro-eminently (I have some ideas but need some tests)09:06
jelmervila: it's not a big deal, I'm just surprised :)09:06
vilajelmer: do was I ;-)09:06
vilajelmer: are you using a script to mark the sru bugs verification-done ? Or do you do that manually ?09:55
jelmervila: I'm doing it manually.09:55
Riddellvila: should we do some more patch pilot today?10:18
vilaRiddell: my plan for today is to write the summary mail before leaving (I'm out next week)10:20
vilaRiddell: did you have a specific item to discuss ?10:20
Riddellvila: 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 pilot10:21
vilaok, I haven't seen any  requiring pp (imbw)10:22
vilaI May Be Wrong10:22
vilaI always can ;)10:22
maxbLooks like 2.3.x has effectively fixed all of the BzrCheckErrors on jubany (though the queue is still draining)11:21
jelmermaxb: I guess that's a relief and worrying at the same time :-/11:25
maxbIt does strongly suggest we should be considering making the fetch-tags behaviour optional in 2.411:25
jelmermaxb: I agree we should make it optional11:26
jelmermaxb: it would be nice to actually fix the underlying problem though11:26
maxbWell, sure11:26
maxbUnfortunately the complexity of this underlying problem exceeds my current knowledge of bzr internals :-/11:27
vilajelmer, 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:47
jelmerah, hmm11:48
jelmerwe should at least make sure we have bug reports about these issues11:49
spivmaxb: 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 :P11:50
jamvila, jelmer: bug #806348 is a fairly large regression for bzr2.4 vs bzr-2.311:50
ubot5Launchpad 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/80634811:50
jamif we can't fix it, we need to back it out, disable-it-by-default11:50
jamspiv: yeah, the interactions of stacking + everything else has never been much fun11:50
spivJust ban tags that are in the ancestry of tip ;)11:50
jamadding that RemoteRepo acts differently than local Repo is not good11:51
jamI think we should make it so that Local stacked repositories don't proxy, and see what falls out.11:51
vilaspiv: what's your gut feeling about being able to fix it for 2.4.0 ?11:51
vilawell, for 29/07 even :)11:52
vila':)' is a good gut feeling, I feel relieved :-p11:52
spivI'm hoping there's a cheap fix or at least mitigation we can do.11:52
spivIt feels like the sort of thing we might be able to recover from more gracefully than just giving up with a BzrCheckError11:53
jamspiv: add a config variable, default it to false?11:53
spivjam: well, that's a good fallback option11:53
spiv(and also helps with the 'unrelated tags cause bloated fetches' bug/feature)11:54
spivBut in principle the client knows what is missing, and knows where to find that data11:55
Lo-lan-doHi all :-)11:55
* Lo-lan-do is back to haunt jelmer *again*11:55
spivIt 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:55
Lo-lan-doSame 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:56
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-doSo, 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?11:57
jelmerhi Lo-lan-do12:00
jelmerLo-lan-do: we've been making some progress on support for colocated branches and accessing colocated branches in git12:01
jelmerLo-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 bugs12:01
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:04
jelmerLo-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:07
Lo-lan-doThe workflow is I have several bzr branches for clients.  For the sake of this discussion, I'm their only user.12:10
Lo-lan-doWhen one of them is stable, I rebase it onto upstream (svn currently) and push it to trunk.12:11
Lo-lan-doIt occurs to me that there's already some rebasing needed, so maybe my worries are not really justified.12:11
jelmerLo-lan-do: I think it would be about the same amount of rebasing as you would if you used git12:12
Lo-lan-doThe upstream repository is shared between all developers.12:12
jelmerLo-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-doNo idea.  Maybe both :-)12:14
Lo-lan-doOther question: can I push from a bzr branch into a git branch other than the "master" branch?12:16
jelmerLo-lan-do: not yet (that's what the bug fix work related to colocated branches is about)12:17
Lo-lan-doAh, I see.12:18
Lo-lan-dojelmer: Any rough idea of when?12:38
jelmerLo-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:40
Lo-lan-doNo problem.12:41
Lo-lan-doI guess I can live with only using master for a while anyway (we don't plan on branching again right away).12:42
Lo-lan-doI haven't followed everything, but is bzr-git updated regularly in sid or do I need to track upstream?12:54
jelmerLo-lan-do: semi-regularly, I'm not sure how up to date the current version in git is13:05
Lo-lan-do'kay.  Thanks for the info :-)13:12
=== 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
lxsameermy connection lost in middle of a bzr branch process how can i resume that?21:07
jelmerlxsameer: if you branched into a repository then you can just remove the branch and restart; I think it'll continue where it left off21:15
lxsameerjelmer: what do you mean? removing the directory cause all the downloaded data to be remove21:16
=== med_out is now known as medberry

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!