=== `23meg is now known as mgunes [00:53] heya Rinchen! [00:54] hi there Hobbsee [01:24] lamont: you're right, btw. the script is not working. [01:25] Hobbsee: cool. [01:25] I guess. [01:25] I mean, that means it's not just me. [01:25] heh [01:25] yeah [01:29] lamont: any idea on how to go about fixing lpia, btw? [01:29] I think it was fixed.. [01:29] so now I'm waiting to see if I'm right [01:30] it's still not taken any builds [01:30] so, unless you've just fixed it, i'd say it's still borken [01:39] iz b0rked [01:39] and on the list for me to work with cprov on tomorrow. [01:40] someohow [01:40] dealing with an escalation at the day job... that just requires 100% of my time [01:41] hehe :) [01:41] fair enough [01:46] I really want to have serious progress tomorrow, so that I can take thur/fri off for that national holiday thing we have this week [02:00] lifeless: you around? [02:00] bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: file u'/etc/init.d/stop-bootlogd' entered as kind 'symlink' id 'stopbootlogd-20071119183925-bf194164ecf5c346', now of kind 'file' [02:00] how do I make that go away? [02:05] lamont: sheesh, how many did you bork? :) [02:05] Hobbsee: nah - that's something different [02:05] and I fixed that with 'dpkg --purge bzr' [02:05] wasnt meaning that :) [02:07] lamont: palmer appears to have stalled, too. [02:11] heh. elmo sounds different when he's asleep. === thumper is now known as thumper_laptop === thumper` is now known as thumper [02:16] hi [02:17] when I push my changes to bzr, I am getting an error like this: [02:17] No handlers could be found for logger "bzr [02:24] got that yesterday too [02:24] lamont: yes [02:25] lamont: get a bzr released this century [02:25] lifeless: it's a buildd machine... iz running edgy [02:25] which it will continue to run. [02:26] I fixed it by nuking bzr [02:26] E: Problem executing scripts DPkg::Post-Invoke 'if [ -d /etc/.bzr ]; then LANG=C /usr/bin/bzr st /etc; fi' [02:26] where does that come from anyway? [02:26] must be time for an upgrade. i'm surprised it's not running dapper. [02:26] lpia buildds run edgy. everything else runs dapper [02:26] ahhh [02:26] hppa runs dapper with a gutsy kernel. go us. [02:27] sadly, nuking bzr wasn't enough: I had to mv /etc/.bzr :) [02:27] and no, you should never run a gutsy kernel on dapper. there are udev issues. [02:43] Why would the lpia buildds be running edgy? Didn't they only appear post-Feisty? [03:00] the hardware for some of them aren't supported by dapper [03:00] (they run x86 bits outside the chroot) [03:26] oops. hadn't realized the lpia buildds were blocking slave-scanner [03:26] and fixing the first bug didn't do squat for the overall success of the program [03:39] lamont: That slave-scanner-destroying bug is meant to be fixed tomorrow, right? [03:40] Fujitsu: that requires some cprov/lamont time on the machines, so yeah, it's a tomorrow thing. [03:41] lamont: I mean in 1.1.11. [03:41] and yes, modulo the fact that I have no time, I'll see how much time I can create to work with him on fixing it, and get lpia back in the running [03:41] I saw something targetted along those lines, IIRC. [03:41] oh, no clue on that [03:41] I know that as of today, lpia buildd's were not building anything (they're dying with an exception). No clue as to root cause of that, etc. [03:42] I have a hotsite that I'm working on (day job) tomorrow that will seriously affect my availability, though. [03:43] it may even affect my thanksgiving holiday [03:50] lamont: for old bzr you can 'bzr rm foo; bzr add foo' [03:50] lifeless: ah, cool [03:50] ciao [04:35] * Hobbsee wishes for blackholing ubuntu-core-dev [04:46] Hobbsee: we're working on it [04:47] jamesh: \o/ [04:47] * Hobbsee is tired of getting unrelated bugmail to her, because some nutter has assigned ubuntu-core-dev, or ubuntu-dev. [04:48] it won't be in this week's release though [04:48] pity. ah well. [07:33] are the admins able to remove packages from PPA yet? i need to beable to overwerite a package since hte orig.tar.gz is borked and with the fixed one it has diff. md5sums so its kind of blocking me from doing anything atm [07:35] when does the 0.92 support rollout on lp ? === jamesh_ is now known as jamesh === mpt_ is now known as mpt [08:02] lifeless: presumably with the rest of the code this week [08:03] cool === \sh_away is now known as \sh [08:09] morning [08:32] damn, mrevell isnt here yet. [08:48] Hobbsee: he should come soon === cprov-away is now known as cprov === Adri2000_ is now known as Adri2000 [11:30] New bug: #164304 in rosetta "Duplicate empty translations" [Critical,Confirmed] https://launchpad.net/bugs/164304 [11:34] https://edge.launchpad.net/+builds/palmer Started 22 hours ago === stu1 is now known as stub === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:39] mrevell: ping [13:39] hello Hobbsee! [13:39] :D [13:39] * Hobbsee --> query [13:42] morning Hobbsee [13:42] heya lamont! [13:42] lamont: how goes it? [13:44] Hobbsee: showered, shaved, dressed, and heading to work in about 20 seconds [13:44] lamont: well done :) [13:45] :-D [13:46] and a conf call in about 5 hours on the escalation, for which I have much to get done. [13:46] :( [13:46] anyway, out the door === neversfelde_ is now known as neversfelde === cprov is now known as cprov-lunch [14:30] New bug: #164340 in rosetta "Do not fetch suggestions for read-only messages like translator credits" [High,New] https://launchpad.net/bugs/164340 [14:38] * Hobbsee ponders the idea of team sub-ppa's. [14:39] sub-ppa's? [14:40] as in, a team owns a ppa - that there's one for production stuff, and one for random testing stuff [14:45] mpt: you said https://edge.launchpad.net/%7Ekubuntu-members/+editemail was a typo - what's the correct address supposed to be? [14:48] +2 more bugs for me to file. [14:48] Hobbsee: Teams can have ppa's already. [14:48] launchpad doesnt deal with big numbers, and dialogs that are mandatory to continue should *not* be marked (optional) [14:49] Hobbsee: ...so the issue is a production vs. testing repo? [14:49] Hobbsee: Why should that only apply for team ppa's? [14:49] soren: yeah. figured out the way around it, though [14:49] well, users too if they want it, i guess [14:50] Yes? [14:50] register another team, make the first team members of it. [14:50] make the admin the same. no more problem. [14:50] Ngh.. [14:51] Well, yes. That... works. [14:51] except that the address of it is already published, and it relies on someone copying over a whole bunch of stuff === salgado is now known as salgado-lunch [14:51] well, this is true. it's a bad and nasty workaround, but it works. === matsubara is now known as matsubara-lunch [14:53] soren: i never said it was elegant :) [14:53] Indeed you didn't :) [15:00] Meeting time? [15:02] welcome everybody to this week's ameu launchpad code reviewer's meeting [15:02] hi barry! [15:02] me, before keyboard locks me out [15:02] who's here to day? [15:02] me [15:02] me [15:03] me [15:03] me [15:03] mwhudson sends his apologies [15:04] ddaa: ping? [15:04] statik is still on holiday [15:04] BjornT is on holiday, afaik [15:04] == Agenda == [15:04] * Roll call [15:04] * Next meeting [15:04] * Action items [15:04] * Queue status [15:04] * Mentoring update [15:04] * Review process changes [15:04] pong [15:04] * On-call reviewer (sole responsibility?) [15:04] * 1-2 day branches [15:04] * 24h reviews [15:04] * Cover letter [15:04] * Death to [trivial] (non-reviewers can review?) [15:04] * Partial reviews [15:04] salgado-lunch: ping? [15:05] SteveA_: ping [15:05] oh actually, i think SteveA_ is away [15:05] me [15:05] * Next meeting [15:05] same time and place? anybody know they will not be able to make it? [15:06] cool [15:06] * Action items [15:06] both are jml's and i think he's away so we'll skip those [15:06] i removed a few action items that i think are overtaken by other events (e.g. the reviewer tool mwhudson and gmb are working on) [15:07] * Queue status [15:07] it looks pretty good to me [15:07] stub and SteveA_ win the stale branch awards for today :) [15:08] * Mentoring update [15:08] anything new to discuss here? [15:08] 5 [15:08] 4 [15:08] 3 [15:08] 2 [15:08] 1 [15:08] * Review process changes [15:09] so i've read through the thread so far and i think a couple of things are emerging [15:09] there seems to be consensus about having on-call reviewers, but not banning them from coding on review days [15:09] does anybody /not/ like this idea? [15:09] no [15:10] * barry encourages everyone to pick a slot, first come first serve: https://launchpad.canonical.com/OnCallReviewers [15:10] i think coding is fine, and the on-call reviewer will be responsible to shelve his coding activity as soon as review duty [15:10] is needed [15:11] flacoste: yep, let's try that. i'll update that wiki page after this meeting [15:11] hopefully we can get good timezone coverage, and i'll pass this on to AsiaPac [15:11] * 1-2 day branches [15:12] the feedback so far seemed to think this should be a goal but not a requirement [15:12] any comments? [15:12] ok [15:12] i have [15:12] flacoste: the floor is yours [15:13] this is something which is really a development process issue [15:13] not a review process issue [15:13] altough it does have an impact on the review process [15:13] but still, i don't think it should be part of the review process improvement discussion [15:14] flacoste: fair enough. i think the artifact of such branches that reviewers see is the branch size. i can't say for sure, but my intuition is that 1-2 day branches will be far below the 2k size limit [15:14] for the most part [15:14] right [15:14] so, from the review process [15:14] what we should say is: lower branch size [15:14] if you want to get a review larger than 1k [15:15] you have to take special arrangement with a reviewer first [15:15] no, automatic allocation, etc. [15:15] or even 800k [15:15] 800 lines i mean [15:15] so reviewers can expect a regular flow [15:15] and interruption in that flow have to be negotiated [15:15] so no surprise of coming one morning and having 2k lines to review [15:16] francis has a good point. reviewers don't care how long a branch was crafted, just the resulting size. [15:16] flacoste, bac i completely agree [15:16] ok, i'll reply to the thread with the above argument [15:16] and suggests a new improvement [15:16] we already have that policy, but the limit is 2k lines. i'm all in favor of lowering that limit [15:16] * flacoste has an action item and is done [15:17] flacoste: thanks! [15:17] * Cover letter [15:17] i would suggest 800 lines [15:17] flacoste: sure. include that in your email [15:17] i think there's no disagreement that a cover letter should now be required. right? [15:18] +1 [15:18] we'll eventually get tool support for this, but for now i don't much care how it's done. someone pastebin'd me a cover letter and that worked fine [15:18] (As much from a developer POV as a reviewer one). [15:19] * barry can't wait for gmb and mwhudson 's tool :) [15:19] * Death to [trivial] (non-reviewers can review?) [15:19] there's a bit of controversy around this one, but i'm still in favor of it [15:19] i really liked bigjools-afk 's suggestion that non-reviewers can get involved in eyeballing trivial changes [15:19] any thoughts on that? [15:20] i agree === bigjools-afk is now known as bigjools [15:20] * bigjools is not really afk :) [15:20] howdy bigjools ! [15:20] hey :) [15:20] I think that is a good way to get everyone involoved [15:20] +1 on that, too. [15:20] +1 on bigjools' suggestion [15:21] * bigjools feels the love [15:21] with the caveat that if the changes really don't appear trivial, kick it back into the normal review process [15:21] -1 on bigjools' [15:21] ddaa: but bigjools is such a likeable guy! === salgado-lunch is now known as salgado [15:21] one of the things the reviewers are responsible for is keeping the longish reviewchecklist and coding style guide in mind [15:22] In my experience, trivial changes (and changes done after merge-conditional) are easy avenues for things that would not go past a trained reviewer [15:23] it depends on how you define trivial [15:23] ddaa has a point [15:23] silly things like column wrapping, make lint, etc. [15:23] or missing tests [15:23] missing test isn't really trivial [15:23] anything requiring a test is not trivial [15:23] right, that was not a good point to make here [15:24] so for this to work, we need a narrow and precise definition of what trivial is [15:24] I'm all in favor of growing the review team as fast as possible, but I do not feel comfortable about this "anybody can review trivial" idea. [15:24] ddaa: would it be enough to say trivial changes can only happen in comments and docstrings? [15:25] is there a lot of those? There's still a risk there: getting comments that contradicts the code is bad [15:26] but I guess a code should always know better than a reviewer about this sort of issue [15:26] So: Is there a lot of those, worthy of this exception? [15:26] * ddaa apologize for his habit of thinking aloud [15:27] ddaa: i don't know [15:27] how about formatting? [15:27] trivial is used for many non-trivial things [15:27] that's the problem we are trying to address [15:27] i would argue that more than 50% of trivial aren't trivial at all [15:28] and that trivial formatting/style/narrative/cleanup are the minority [15:28] we could gather data about this [15:28] flacoste: right, in the end either we forbid trivial, or we need some post-landing review to ensure that trivial is used properly. [15:28] let's sample the last month of trivial landing [15:28] i think the definition is pretty clear - a trivial branch doesn't change the behaviour of the application at all === matsubara-lunch is now known as matsubara [15:28] the point of the second set of eyeballs is that they knock it back if it's not really trivial [15:28] intellectronica: well, that's already the case [15:28] the problem is that this definition isn't respected [15:29] so ddaa is right: forbid it or post-review each one fo them [15:29] flacoste: can we reasonably expect non-reviewers to know when something is not trivial? [15:29] we had a process about the former [15:29] but we haven't kept with it [15:29] barry: experience shows we can't [15:29] in the last 30 days we had 30 trivial landings out of 131 landings in total, ftr [15:29] i say death to trivial [15:29] salgado: and how much of those were trivial by the current definitions [15:30] * sinzui made excellent use of trivial [15:30] all of stubs aren't :-) [15:30] sinzui is exceptional :-! [15:31] the flip side is whether on-call reviewers make death to trivial (alone) manageable [15:31] I would like to point out that death to trivial makes it less likely that people will feel inclined to fix trivial issues [15:31] death to trivial + on-call reviewers +1 [15:32] my concern is that in many cases this will either discourage people from making trivial changes or slow people down while they try to sort out a review (even if it's easy), before starting on the 'real' branch [15:32] flacoste, that's not very easy to find out. I'll be able to tell in a few minutes [15:32] bigjools: maybe the opposite though. if you could make a trivial change, get an approval over irc in 5 minutes, and land it in 10, it might be okay [15:32] Won't on-call reviewers help to make death-to-trivial easier to swallow though? [15:32] i think the discouraging idea is bogus [15:32] barry: that's more effort than it is right now though [15:32] let's see some real data before hand [15:33] but I would suggest killing it for now and see how it goes [15:33] Personally, I find that "making a new branch, and getting it through pqm" is the dominating overhead for trivial fixes. [15:33] thxbye [15:33] intellectronica: there is no need to wait before starting the real change [15:33] meta-point: i think this idea clearly needs more baking and data. let's move it back to the mailing list [15:33] i mean just merge it in your new one [15:34] salgado: if you could spend a few minutes gathering some data and post it to the list, that would be great [15:34] flacoste: i suppose you're right, you can always depend on the trivial branch [15:34] you can merge again later [15:34] I do a trivial commit for almost every assigned task I have to keep my diff smaller. [15:34] ddaa: maybe you could follow up to that thread with your concerns [15:34] fair enough, maybe losing trivial is not so bad after all [15:34] barry: I'm hopelessly behind the lp ML. Anyway, my point is nothing new. [15:35] Regardless of what it is called, the 'trivial' branches will continue because of the need to keep branches focused. [15:35] barry: agreed, empirical data can help sort it out. [15:35] ddaa: k [15:35] Let's move on. [15:35] agreed [15:35] * Partial reviews [15:35] there seems to be some support for this, but also reservations [15:36] really, i think it's mostly to get into the 24h sla [15:36] the idea being that /some/ response within 24h is better than silence [15:36] thoughts? [15:36] * ddaa raises hand [15:37] ddaa: go ahead [15:37] Did only a couple of reviews so far [15:37] Again, from a developer standpoint as much as owt else I'm +1 [15:37] but I found that sometimes issues raised at the start of the review are resolved by the reviewer itself later in the review. [15:38] partial reviews risk causing needless discussion about things that the reviewer would have resolved himself by finishing the review. [15:38] Whether this risk is worth discarding the benefit of faster response time, I do not know. [15:38] ddaa: this can sometimes happen, yes. another thing that can happen is that systemic problems become more apparent later in the review [15:39] I think that partial reviews are good in circumstances where events beyond the reviewer's control prevent them from completing the review. [15:39] Such as conflicts in a branch. [15:39] barry: "new problems found later" is not an issue for partial reviews. What's an issue is "non-issues that cause needless discussion". [15:40] i think that partial reviews should be exceptional [15:40] if we have many partial reviews, something else is broken in our process [15:40] so i think that partial reviews are fine [15:40] flacoste: i agree [15:40] i think it would be best to limit this to cases where the review can't continue for some reason - conflicts, timing, dependencies, etc'... [15:40] but we should monitor how many we do [15:40] flacoste+1 [15:40] small branches should make this rare [15:40] and raise an alert if we have many of them [15:41] partial reviews is a better way to degrade than late reviews [15:41] flacoste: do we need a way to flag partial reviews, e.g. in the subject heading, review status, wiki page? [15:41] that would make it easier to track [15:41] so that's a good idea [15:41] PARTIAL REVIEW: [15:41] insted of REVIEW: [15:41] I vote for adopting partial reviews as a degraded mode of operation. [15:41] we can then easily count how many PARTIAL REVIEWS were done in a cycle [15:41] yeah, that would be easy to add to utilities/review :) [15:42] the problem with the title is that if you read your mail in threads your review material will end up in two threads [15:42] i really like having the complete story in one thread when finalizing a branch [15:43] intellectronica: yeah, the review script doesn't help here. you'd have to do the follow up in response to the original message [15:43] intellectronica: That's okay I think. The important point is "partial review is not the normal mode of operation". [15:44] yep. okay, i'll write this up. is there anything else on this topic? [15:44] 5 [15:44] 4 [15:44] 3 [15:44] 2 [15:44] 1 [15:44] intellectronica: that's what threading should be done based on Reference header,not subject :-) [15:44] cool that's it for me. raise your hand if you have anything not on the agenda [15:45] flacoste: the "review.py" script does not know how to set this header :) [15:45] 5 [15:45] 4 [15:45] 3 [15:45] 2 [15:45] well, the initial message doesn't need one [15:45] and you can't use that script for follow-up? [15:45] 1 [15:45] flacoste: not currently [15:45] MEETING ENDS [15:46] (and on time this week :) [15:46] thanks everybody! [15:46] thx barry === cprov-lunch is now known as cprov === mrevell is now known as mrevell-afk [16:33] hello, can anyone tell me how to use the launchpad translation service with java .properties files ? I remember trying converting the .properties files to .pot (there's an option with gettext) and I submitted a tar that was rejected (as I never saw a result) [16:37] eaqua: hi, for which project did you upload it? [16:37] carlos: netbeans [16:39] eaqua: hmm I don't see any rejection nor pending file to be imported for it [16:39] carlos: https://translations.launchpad.net/netbeans [16:39] eaqua: where did you submitted that tarball ? [16:39] carlos: well, I had a tar in there ages ago, sat in the queue a lot then I forgot about it. never got some email of rejection or something. [16:41] did you change the entries status to 'Delete' or something like that? [16:41] carlos: I uploaded it in my project page. The interface was a bit different back then(15th March or so). but I do remember the queue having tons of pending files to aprove. [16:41] carlos: no, i didn't change to delete. [16:42] hmm, then the only chance is that, for some reason, we rejected it... let me try to see whether I see anything in my outbox... === mrevell-afk is now known as mrevell [16:43] carlos: it was a big tar with lots of .pot files converted from .properties with msginit. maybe the format was wrong or something. [16:43] it's a manual process to accept/reject the initial upload so we should give you an answer... [16:44] found it (I think) [16:44] eaqua: I rejected it and sent you an email [16:45] eaqua: I rejected it because at that time, the project said that it was 'Romanian Translation of NetBeans IDE' [16:45] carlos: yes, that's what I was planning to use it for. [16:45] and that's against our policy [16:45] let me resend you the email [16:45] carlos: I didn't want to start an official netbeans project on launchpad [16:46] carlos: aha, I was just trying to use the translation service, nothing else. [16:46] carlos: you need a full package so to speak :) [16:46] eaqua: well, the problem is that we don't have yet a way to restrict a project translation to a single team [16:47] so that will produce that other language translators start translating netbeans too in Launchpad [16:47] but those translations will be completely wasted and never used [16:47] carlos: makes sense. so was the tar file ok. that is, may I re-create the tar and re-submit it ? [16:48] well, I didn't see anything wrong with the tarball itself, but what you want to do is still against our policy, unless you get the approval of netbeans developers to use Launchpad for translations and you or any of the core developer team agreed on update those .pot file and .po files from time to time [16:48] carlos: do I need to guarantee somehow that any translation will go upstream ? [16:48] in both ways [16:49] either update Launchpad with any update done in their source tree or update their tree with any update done in Launchpad [16:49] eaqua: yeah [16:50] eaqua: we have more details in our policy page (you have it in the email I forwarded to you) [16:50] well, you have it here too, just in case you don't get the email: https://help.launchpad.net/TranslationsImportPolicy [16:50] carlos: hm, this is almost impossible. if my team will show launchpad is usable others might join, but right now people are using desktop-only tools with local files. it would be kinda hard to convince a full migration to launchpad. [16:51] eaqua: you don't really need a full migration, although the offline use case also work from Launchpad because they could download / upload the files in Launchpad [16:51] eaqua: we only require that the developers are aware of that Launchpad usage and that someone take care of the sync in both ways [16:52] if they use Launchpad directly, the sync only needs to be done for the .pot files and they will get all translations from time to time from Launchpad, but that's not a must [16:54] carlos: well, i don't get it. so I will upload the .pot files and start translating in my language. the upstream owners will know about this. I will also notify other teams about this in case some "unaproved" translations in other languages start but it will be their job to use that if they want. where exactly am I breaking the launchpad policy ? [16:55] eaqua: will you upload any other existing translation for other languages? === \sh is now known as \sh_away [16:55] if you don't do that, and there is, for instance a full one for Spanish, someone would start another one in Launchpad [16:55] and that's one of the things we want to avoid [16:56] when you send your translations to netbeans developers, will you include any other update for other languages in Launchpad? [16:56] well, right now the project isn't call "romanian" anymore. so in theory people would just need to upload the spanish .po files. [16:56] if you don't do that we have again some lose efforts [16:57] so what we require is that someone takes the responsibility of preventing this to happen and to do the sync [16:57] it's a cyclic problem: obviously not all teams want/need to use launchpad. but due to the launchpad policy nobody is allowed ? [16:57] i can upload the .po files for other languages from time to time. but they won't be used. [16:58] why they will not be used? [16:58] and the upstream teams for other languages will probably disregard the input unless it's massive (many contributions). [16:58] well, no spanish translator will use launchpad that is. [16:58] as they have their own mailing list and own little set of tools, etc. [16:59] you mean from current Spanish translation team for netbeans I guess [16:59] ok [16:59] yes, as an example. [16:59] what about new languages not available in netbeans? [16:59] oh, I'm fine with that. [16:59] will you send those translations? [16:59] of course, I can do that, or other people will take charge of their own (native) language. [17:00] sure, if you delegate that to someone else [17:00] that's fine [17:00] as long as those translations are not stalled in Launchpad [17:00] i see. [17:00] ok, so I guess the best solution for this is [17:01]