[00:53] <Hobbsee> heya Rinchen!
[00:54] <Rinchen> hi there Hobbsee 
[01:24] <Hobbsee> lamont: you're right, btw.  the script is not working.
[01:25] <lamont> Hobbsee: cool.
[01:25] <lamont> I guess.
[01:25] <lamont> I mean, that means it's not just me.
[01:25] <Hobbsee> heh
[01:25] <Hobbsee> yeah
[01:29] <Hobbsee> lamont: any idea on how to go about fixing lpia, btw?
[01:29] <lamont> I think it was fixed..
[01:29] <lamont> so now I'm waiting to see if I'm right
[01:30] <Hobbsee> it's still not taken any builds
[01:30] <Hobbsee> so, unless you've just fixed it, i'd say it's still borken
[01:39] <lamont> iz b0rked
[01:39] <lamont> and on the list for me to work with cprov on tomorrow.
[01:40] <lamont> someohow
[01:40] <lamont> dealing with an escalation at the day job... that just requires 100% of my time
[01:41] <Hobbsee> hehe :)
[01:41] <Hobbsee> fair enough
[01:46] <lamont> 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] <lamont> lifeless: you around?
[02:00] <lamont> 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] <lamont> how do I make that go away?
[02:05] <Hobbsee> lamont: sheesh, how many did you bork?  :)
[02:05] <lamont> Hobbsee: nah - that's something different
[02:05] <lamont> and I fixed that with 'dpkg --purge bzr'
[02:05] <Hobbsee> wasnt meaning that :)
[02:07] <Hobbsee> lamont: palmer appears to have stalled, too.
[02:11] <lamont> heh.  elmo sounds different when he's asleep.
[02:16] <baijum> hi
[02:17] <baijum> when I push my changes to bzr, I am getting an error like this:
[02:17] <baijum> No handlers could be found for logger "bzr
[02:24] <Ubulette> got that yesterday too
[02:24] <lifeless> lamont: yes
[02:25] <lifeless> lamont: get a bzr released this century
[02:25] <lamont> lifeless: it's a buildd machine... iz running edgy
[02:25] <lamont> which it will continue to run.
[02:26] <lamont> I fixed it by nuking bzr
[02:26] <lamont> E: Problem executing scripts DPkg::Post-Invoke 'if [ -d /etc/.bzr ]; then LANG=C /usr/bin/bzr st /etc; fi'
[02:26] <lamont> where does that come from anyway?
[02:26] <Hobbsee> must be time for an upgrade.  i'm surprised it's not running dapper.
[02:26] <lamont> lpia buildds run edgy.  everything else runs dapper
[02:26] <Hobbsee> ahhh
[02:26] <lamont> hppa runs dapper with a gutsy kernel.  go us.
[02:27] <lamont> sadly, nuking bzr wasn't enough: I had to mv /etc/.bzr :)
[02:27] <lamont> and no, you should never run a gutsy kernel on dapper.  there are udev issues.
[02:43] <Fujitsu> Why would the lpia buildds be running edgy? Didn't they only appear post-Feisty?
[03:00] <lamont> the hardware for some of them aren't supported by dapper
[03:00] <lamont> (they run x86 bits outside the chroot)
[03:26] <lamont> oops.  hadn't realized the lpia buildds were blocking slave-scanner
[03:26] <lamont> and fixing the first bug didn't do squat for the overall success of the program
[03:39] <Fujitsu> lamont: That slave-scanner-destroying bug is meant to be fixed tomorrow, right?
[03:40] <lamont> Fujitsu: that requires some cprov/lamont time on the machines, so yeah, it's a tomorrow thing.
[03:41] <Fujitsu> lamont: I mean in 1.1.11.
[03:41] <lamont> 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] <Fujitsu> I saw something targetted along those lines, IIRC.
[03:41] <lamont> oh, no clue on that
[03:41] <lamont> 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] <lamont> I have a hotsite that I'm working on (day job) tomorrow that will seriously affect my availability, though.
[03:43] <lamont> it may even affect my thanksgiving holiday
[03:50] <lifeless> lamont: for old bzr you can 'bzr rm foo; bzr add foo'
[03:50] <lamont> lifeless: ah, cool
[03:50] <lifeless> ciao
[04:35]  * Hobbsee wishes for blackholing ubuntu-core-dev
[04:46] <jamesh> Hobbsee: we're working on it
[04:47] <Hobbsee> 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] <jamesh> it won't be in this week's release though
[04:48] <Hobbsee> pity.  ah well.
[07:33] <gnomefreak> 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] <lifeless> when does the 0.92 support rollout on lp ?
[08:02] <jamesh> lifeless: presumably with the rest of the code this week
[08:03] <lifeless> cool
[08:09] <carlos> morning
[08:32] <Hobbsee> damn, mrevell isnt here yet.
[08:48] <carlos> Hobbsee: he should come soon
[11:30] <ubotu> New bug: #164304 in rosetta "Duplicate empty translations" [Critical,Confirmed] https://launchpad.net/bugs/164304
[11:34] <Ubulette> https://edge.launchpad.net/+builds/palmer  	 Started 22 hours ago
[13:39] <Hobbsee> mrevell: ping
[13:39] <mrevell> hello Hobbsee!
[13:39] <Hobbsee> :D
[13:39]  * Hobbsee --> query
[13:42] <lamont> morning Hobbsee 
[13:42] <Hobbsee> heya lamont!
[13:42] <Hobbsee> lamont: how goes it?
[13:44] <lamont> Hobbsee: showered, shaved, dressed, and heading to work in about 20 seconds
[13:44] <Hobbsee> lamont: well done :)
[13:45] <lamont> :-D
[13:46] <lamont> and a conf call in about 5 hours on the escalation, for which I have much to get done.
[13:46] <lamont> :(
[13:46] <lamont> anyway, out the door
[14:30] <ubotu> 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] <soren> sub-ppa's?
[14:40] <Hobbsee> as in, a team owns a ppa - that there's one for production stuff, and one for random testing stuff
[14:45] <Hobbsee> mpt: you said https://edge.launchpad.net/%7Ekubuntu-members/+editemail was a typo - what's the correct address supposed to be?
[14:48] <Hobbsee> +2 more bugs for me to file.
[14:48] <soren> Hobbsee: Teams can have ppa's already.
[14:48] <Hobbsee> launchpad doesnt deal with big numbers, and dialogs that are mandatory to continue should *not* be marked (optional)
[14:49] <soren> Hobbsee: ...so the issue is a production vs. testing repo?
[14:49] <soren> Hobbsee: Why should that only apply for team ppa's?
[14:49] <Hobbsee> soren: yeah.  figured out the way around it, though
[14:49] <Hobbsee> well, users too if they want it, i guess
[14:50] <soren> Yes?
[14:50] <Hobbsee> register another team, make the first team members of it.
[14:50] <Hobbsee> make the admin the same.  no more problem.
[14:50] <soren> Ngh..
[14:51] <soren> Well, yes. That... works.
[14:51] <Hobbsee> except that the address of it is already published, and it relies on someone copying over a whole bunch of stuff
[14:51] <Hobbsee> well, this is true.  it's a bad and nasty workaround, but it works.
[14:53] <Hobbsee> soren: i never said it was elegant :)
[14:53] <soren> Indeed you didn't :)
[15:00] <gmb> Meeting time?
[15:02] <barry> welcome everybody to this week's ameu launchpad code reviewer's meeting
[15:02] <flacoste> hi barry!
[15:02] <sinzui> me, before keyboard locks me out
[15:02] <barry> who's here to day?
[15:02] <gmb> me
[15:02] <bac> me
[15:03] <intellectronica> me
[15:03] <flacoste> me
[15:03] <barry> mwhudson sends his apologies
[15:04] <barry> ddaa: ping?
[15:04] <bac> statik is still on holiday
[15:04] <intellectronica> BjornT is on holiday, afaik
[15:04] <barry> == Agenda ==
[15:04] <barry>  * Roll call
[15:04] <barry>  * Next meeting
[15:04] <barry>  * Action items
[15:04] <barry>  * Queue status
[15:04] <barry>  * Mentoring update
[15:04] <barry>  * Review process changes
[15:04] <ddaa> pong
[15:04] <barry>    * On-call reviewer (sole responsibility?)
[15:04] <barry>    * 1-2 day branches
[15:04] <barry>    * 24h reviews
[15:04] <barry>    * Cover letter
[15:04] <barry>    * Death to [trivial] (non-reviewers can review?)
[15:04] <barry>    * Partial reviews
[15:04] <barry> salgado-lunch: ping?
[15:05] <barry> SteveA_: ping
[15:05] <barry> oh actually, i think SteveA_ is away
[15:05] <ddaa> me
[15:05] <barry>  * Next meeting
[15:05] <barry> same time and place?  anybody know they will not be able to make it?
[15:06] <barry> cool
[15:06] <barry>  * Action items
[15:06] <barry> both are jml's and i think he's away so we'll skip those
[15:06] <barry> 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] <barry>  * Queue status
[15:07] <barry> it looks pretty good to me
[15:07] <barry> stub and SteveA_ win the stale branch awards for today :)
[15:08] <barry>  * Mentoring update
[15:08] <barry> anything new to discuss here?
[15:08] <barry> 5
[15:08] <barry> 4
[15:08] <barry> 3
[15:08] <barry> 2
[15:08] <barry> 1
[15:08] <barry>  * Review process changes
[15:09] <barry> so i've read through the thread so far and i think a couple of things are emerging
[15:09] <barry> there seems to be consensus about having on-call reviewers, but not banning them from coding on review days
[15:09] <barry> does anybody /not/ like this idea?
[15:09] <flacoste> no
[15:10]  * barry encourages everyone to pick a slot, first come first serve: https://launchpad.canonical.com/OnCallReviewers
[15:10] <flacoste> 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] <flacoste> is needed
[15:11] <barry> flacoste: yep, let's try that. i'll update that wiki page after this meeting
[15:11] <barry> hopefully we can get good timezone coverage, and i'll pass this on to AsiaPac
[15:11] <barry>    * 1-2 day branches
[15:12] <barry> the feedback so far seemed to think this should be a goal but not a requirement
[15:12] <barry> any comments?
[15:12] <barry> ok
[15:12] <flacoste> i have
[15:12] <barry> flacoste: the floor is yours
[15:13] <flacoste> this is something which is really a development process issue
[15:13] <flacoste> not a review process issue
[15:13] <flacoste> altough it does have an impact on the review process
[15:13] <flacoste> but still, i don't think it should be part of the review process improvement discussion
[15:14] <barry> 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] <barry> for the most part
[15:14] <flacoste> right
[15:14] <flacoste> so, from the review process
[15:14] <flacoste> what we should say is: lower branch size
[15:14] <flacoste> if you want to get a review larger than 1k
[15:15] <flacoste> you have to take special arrangement with a reviewer first
[15:15] <flacoste> no, automatic allocation, etc.
[15:15] <flacoste> or even 800k
[15:15] <flacoste> 800 lines i mean
[15:15] <flacoste> so reviewers can expect a regular flow
[15:15] <flacoste> and interruption in that flow have to be negotiated
[15:15] <flacoste> so no surprise of coming one morning and having 2k lines to review
[15:16] <bac> francis has a good point.  reviewers don't care how long a branch was crafted, just the resulting size.
[15:16] <barry> flacoste, bac i completely agree
[15:16] <flacoste> ok, i'll reply to the thread with the above argument
[15:16] <flacoste> and suggests a new improvement
[15:16] <barry> 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] <barry> flacoste: thanks!
[15:17] <barry>    * Cover letter
[15:17] <flacoste> i would suggest 800 lines
[15:17] <barry> flacoste: sure. include that in your email
[15:17] <barry> i think there's no disagreement that a cover letter should now be required.  right?
[15:18] <gmb> +1
[15:18] <barry> 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] <gmb> (As much from a developer POV as a reviewer one).
[15:19]  * barry can't wait for gmb and mwhudson 's tool :)
[15:19] <barry>    * Death to [trivial] (non-reviewers can review?)
[15:19] <barry> there's a bit of controversy around this one, but i'm still in favor of it
[15:19] <barry> i really liked bigjools-afk 's suggestion that non-reviewers can get involved in eyeballing trivial changes
[15:19] <barry> any thoughts on that?
[15:20] <flacoste> i agree
[15:20]  * bigjools is not really afk :)
[15:20] <barry> howdy bigjools !
[15:20] <bigjools> hey :)
[15:20] <sinzui> I think that is a good way to get everyone involoved
[15:20] <gmb> +1 on that, too.
[15:20] <bac> +1 on bigjools' suggestion
[15:21]  * bigjools feels the love
[15:21] <barry> with the caveat that if the changes really don't appear trivial, kick it back into the normal review process
[15:21] <ddaa> -1 on bigjools'
[15:21] <barry> ddaa: but bigjools is such a likeable guy!
[15:21] <ddaa> one of the things the reviewers are responsible for is keeping the longish reviewchecklist and coding style guide in mind
[15:22] <ddaa> 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] <bigjools> it depends on how you define trivial
[15:23] <flacoste> ddaa has a point
[15:23] <ddaa> silly things like column wrapping, make lint, etc.
[15:23] <ddaa> or missing tests
[15:23] <flacoste> missing test isn't really trivial
[15:23] <bigjools> anything requiring a test is not trivial
[15:23] <ddaa> right, that was not a good point to make here
[15:24] <barry> so for this to work, we need a narrow and precise definition of what trivial is
[15:24] <ddaa> 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] <barry> ddaa: would it be enough to say trivial changes can only happen in comments and docstrings?
[15:25] <ddaa> is there a lot of those? There's still a risk there: getting comments that contradicts the code is bad
[15:26] <ddaa> but I guess a code should always know better than a reviewer about this sort of issue
[15:26] <ddaa> So: Is there a lot of those, worthy of this exception?
[15:26]  * ddaa apologize for his habit of thinking aloud
[15:27] <barry> ddaa: i don't know
[15:27] <intellectronica> how about formatting?
[15:27] <flacoste> trivial is used for many non-trivial things
[15:27] <flacoste> that's the problem we are trying to address
[15:27] <flacoste> i would argue that more than 50% of trivial aren't trivial at all
[15:28] <flacoste> and that trivial formatting/style/narrative/cleanup are the minority
[15:28] <flacoste> we could gather data about this
[15:28] <ddaa> 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] <flacoste> let's sample the last month of trivial landing
[15:28] <intellectronica> i think the definition is pretty clear - a trivial branch doesn't change the behaviour of the application at all
[15:28] <bigjools> the point of the second set of eyeballs is that they knock it back if it's not really trivial
[15:28] <flacoste> intellectronica: well, that's already the case
[15:28] <flacoste> the problem is that this definition isn't respected
[15:29] <flacoste> so ddaa is right: forbid it or post-review each one fo them
[15:29] <barry> flacoste: can we reasonably expect non-reviewers to know when something is not trivial?
[15:29] <flacoste> we had a process about the former
[15:29] <flacoste> but we haven't kept with it
[15:29] <ddaa> barry: experience shows we can't
[15:29] <salgado> in the last 30 days we had 30 trivial landings out of 131 landings in total, ftr
[15:29] <flacoste> i say death to trivial
[15:29] <flacoste> salgado: and how much of those were trivial by the current definitions
[15:30]  * sinzui made excellent use of trivial
[15:30] <flacoste> all of stubs aren't :-)
[15:30] <flacoste> sinzui is exceptional :-!
[15:31] <barry> the flip side is whether on-call reviewers make death to trivial (alone) manageable
[15:31] <bigjools> 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] <ddaa> death to trivial + on-call reviewers +1
[15:32] <intellectronica> 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] <salgado> flacoste, that's not very easy to find out.  I'll be able to tell in a few minutes
[15:32] <barry> 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] <gmb> Won't on-call reviewers help to make death-to-trivial easier to swallow though?
[15:32] <flacoste> i think the discouraging idea is bogus
[15:32] <bigjools> barry: that's more effort than it is right now though
[15:32] <flacoste> let's see some real data before hand
[15:33] <bigjools> but I would suggest killing it for now and see how it goes
[15:33] <ddaa> Personally, I find that "making a new branch, and getting it through pqm" is the dominating overhead for trivial fixes.
[15:33] <bigjools> thxbye
[15:33] <flacoste> intellectronica: there is no need to wait before starting the real change
[15:33] <barry> meta-point: i think this idea clearly needs more baking and data.  let's move it back to the mailing list
[15:33] <flacoste> i mean just merge it in your new one
[15:34] <barry> salgado: if you could spend a few minutes gathering some data and post it to the list, that would be great
[15:34] <intellectronica> flacoste: i suppose you're right, you can always depend on the trivial branch
[15:34] <flacoste> you can merge again later
[15:34] <sinzui> I do a trivial commit for almost every assigned task I have to keep my diff smaller.
[15:34] <barry> ddaa: maybe you could follow up to that thread with your concerns
[15:34] <intellectronica> fair enough, maybe losing trivial is not so bad after all
[15:34] <ddaa> barry: I'm hopelessly behind the lp ML. Anyway, my point is nothing new.
[15:35] <sinzui> Regardless of what it is called, the 'trivial' branches will continue because of the need to keep branches focused.
[15:35] <ddaa> barry: agreed, empirical data can help sort it out.
[15:35] <barry> ddaa: k
[15:35] <ddaa> Let's move on.
[15:35] <barry> agreed
[15:35] <barry>    * Partial reviews
[15:35] <barry> there seems to be some support for this, but also reservations
[15:36] <barry> really, i think it's mostly to get into the 24h sla
[15:36] <barry> the idea being that /some/ response within 24h is better than silence
[15:36] <barry> thoughts?
[15:36]  * ddaa raises hand
[15:37] <barry> ddaa: go ahead
[15:37] <ddaa> Did only a couple of reviews so far
[15:37] <gmb> Again, from a developer standpoint as much as owt else I'm +1
[15:37] <ddaa> 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] <ddaa> partial reviews risk causing needless discussion about things that the reviewer would have resolved himself by finishing the review.
[15:38] <ddaa> Whether this risk is worth discarding the benefit of faster response time, I do not know.
[15:38] <barry> ddaa: this can sometimes happen, yes.  another thing that can happen is that systemic problems become more apparent later in the review
[15:39] <gmb> I think that partial reviews are good in circumstances where events beyond the reviewer's control prevent them from completing the review.
[15:39] <gmb> Such as conflicts in a branch.
[15:39] <ddaa> 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] <flacoste> i think that partial reviews should be exceptional
[15:40] <flacoste> if we have many partial reviews, something else is broken in our process
[15:40] <flacoste> so i think that partial reviews are fine
[15:40] <barry> flacoste: i agree
[15:40] <intellectronica> 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] <flacoste> but we should monitor how many we do
[15:40] <ddaa> flacoste+1
[15:40] <barry> small branches should make this rare
[15:40] <flacoste> and raise an alert if we have many of them
[15:41] <ddaa> partial reviews is a better way to degrade than late reviews
[15:41] <barry> flacoste: do we need a way to flag partial reviews, e.g. in the subject heading, review status, wiki page?
[15:41] <flacoste> that would make it easier to track
[15:41] <flacoste> so that's a good idea
[15:41] <flacoste> PARTIAL REVIEW:
[15:41] <flacoste> insted of REVIEW:
[15:41] <ddaa> I vote for adopting partial reviews as a degraded mode of operation.
[15:41] <flacoste> we can then easily count how many PARTIAL REVIEWS were done in a cycle
[15:41] <barry> yeah, that would be easy to add to utilities/review :)
[15:42] <intellectronica> 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] <intellectronica> i really like having the complete story in one thread when finalizing a branch
[15:43] <barry> 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] <ddaa> intellectronica: That's okay I think. The important point is "partial review is not the normal mode of operation".
[15:44] <barry> yep. okay, i'll write this up.  is there anything else on this topic?
[15:44] <barry> 5
[15:44] <barry> 4
[15:44] <barry> 3
[15:44] <barry> 2
[15:44] <barry> 1
[15:44] <flacoste> intellectronica: that's what threading should be done based on Reference header,not subject :-)
[15:44] <barry> cool that's it for me.  raise your hand if you have anything not on the agenda
[15:45] <ddaa> flacoste: the "review.py" script does not know how to set this header :)
[15:45] <barry> 5
[15:45] <barry> 4
[15:45] <barry> 3
[15:45] <barry> 2
[15:45] <flacoste> well, the initial message doesn't need one
[15:45] <flacoste> and you can't use that script for follow-up?
[15:45] <barry> 1
[15:45] <barry> flacoste: not currently
[15:45] <barry> MEETING ENDS
[15:46] <barry> (and on time this week :)
[15:46] <barry> thanks everybody!
[15:46] <bac> thx barry
[16:33] <eaqua> 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] <carlos> eaqua: hi, for which project did you upload it?
[16:37] <eaqua> carlos: netbeans
[16:39] <carlos> eaqua: hmm I don't see any rejection nor pending file to be imported for it
[16:39] <eaqua> carlos: https://translations.launchpad.net/netbeans
[16:39] <carlos> eaqua: where did you submitted that tarball ?
[16:39] <eaqua> 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] <carlos> did you change the entries status to 'Delete' or something like that?
[16:41] <eaqua> 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] <eaqua> carlos: no, i didn't change to delete.
[16:42] <carlos> 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...
[16:43] <eaqua> 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] <carlos> it's a manual process to accept/reject the initial upload so we should give you an answer...
[16:44] <carlos> found it (I think)
[16:44] <carlos> eaqua: I rejected it and sent you an email
[16:45] <carlos> eaqua: I rejected it because at that time, the project said that it was 'Romanian Translation of NetBeans IDE'
[16:45] <eaqua> carlos: yes, that's what I was planning to use it for.
[16:45] <carlos> and that's against our policy
[16:45] <carlos> let me resend you the email
[16:45] <eaqua> carlos: I didn't want to start an official netbeans project on launchpad 
[16:46] <eaqua> carlos: aha, I was just trying to use the translation service, nothing else.
[16:46] <eaqua> carlos: you need a full package so to speak :)
[16:46] <carlos> eaqua: well, the problem is that we don't have yet a way to restrict a project translation to a single team
[16:47] <carlos> so that will produce that other language translators start translating netbeans too in Launchpad
[16:47] <carlos> but those translations will be completely wasted and never used
[16:47] <eaqua> carlos: makes sense. so was the tar file ok. that is, may I re-create the tar and re-submit it ?
[16:48] <carlos> 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] <eaqua> carlos: do I need to guarantee somehow that any translation will go upstream ?
[16:48] <carlos> in both ways
[16:49] <carlos> either update Launchpad with any update done in their source tree or update their tree with any update done in Launchpad
[16:49] <carlos> eaqua: yeah
[16:50] <carlos> eaqua: we have more details in our policy page (you have it in the email I forwarded to you)
[16:50] <carlos> well, you have it here too, just in case you don't get the email: https://help.launchpad.net/TranslationsImportPolicy
[16:50] <eaqua> 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] <carlos> 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] <carlos> 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] <carlos> 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] <eaqua> 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] <carlos> eaqua: will you upload any other existing translation for other languages?
[16:55] <carlos> 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] <carlos> and that's one of the things we want to avoid
[16:56] <carlos> when you send your translations to netbeans developers, will you include any other update for other languages in Launchpad?
[16:56] <eaqua> 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] <carlos> if you don't do that we have again some lose efforts
[16:57] <carlos> so what we require is that someone takes the responsibility of preventing this to happen and to do the sync
[16:57] <eaqua> 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] <eaqua> i can upload the .po files for other languages from time to time. but they won't be used.
[16:58] <carlos> why they will not be used?
[16:58] <eaqua> and the upstream teams for other languages will probably disregard the input unless it's massive (many contributions).
[16:58] <eaqua> well, no spanish translator will use launchpad that is.
[16:58] <eaqua> as they have their own mailing list and own little set of tools, etc.
[16:59] <carlos> you mean from current Spanish translation team for netbeans I guess
[16:59] <carlos> ok
[16:59] <eaqua> yes, as an example.
[16:59] <carlos> what about new languages not available in netbeans?
[16:59] <eaqua> oh, I'm fine with that.
[16:59] <carlos> will you send those translations?
[16:59] <eaqua> of course, I can do that, or other people will take charge of their own (native) language.
[17:00] <carlos> sure, if you delegate that to someone else
[17:00] <carlos> that's fine
[17:00] <carlos> as long as those translations are not stalled in Launchpad
[17:00] <eaqua> i see.
[17:00] <carlos> ok, so I guess the best solution for this is
[17:01] <carlos> hmm, let me check something first
[17:01] <carlos> and I will be back with a proposal 
[17:03] <eaqua> the point is this would be a way to "pitch" launchpad (as well to see if it's useful). I don't see a point in submitting the existing translations as these have existing teams in place and people will be just confused seing stuff in launchpad. but for new teams it's good start to see the "popular" demand. in the end maybe the existing ones will migrate too.
[17:08] <carlos> eaqua: well, if you import everything each time you sync the templates, it helps them to see how it works for them and even to get new contributors for their language
[17:09] <eaqua> can I put a message saying that language X has a separate mailing list and that they might want to join that before submitting to launchpad ? (as the X team doesn't actually us launchpad ?)
[17:14] <eaqua> s/us/use/
[17:14] <carlos> eaqua: yes
[17:14] <carlos> I just discussed this with danilos, another Launchpad Translations admin
[17:14] <carlos> and we agreed that we could setup a Translation group for netbeans
[17:15] <carlos> where we will add a team per existing language that will block it for translation changes
[17:15] <eaqua> read-only basically ?
[17:15] <carlos> yeah
[17:15] <carlos> anyone will still be able to add suggestions
[17:15] <carlos> but will not be approved, it's not ideal, but not so bad...
[17:16] <carlos> in those teams, you could add such warning
[17:16] <eaqua> great. so I just have to re-create the .pot from the .properties files in english and upload them. this will bootstrap the other languages read-write.
[17:16] <carlos> and when other team decides to start using Launchpad is a matter of give them the ownership of that team and they will get access to do translations just like you will be doing since first day
[17:16] <eaqua> I'll also upload at some point the current languages, but these will be read-only.
[17:17] <carlos> eaqua: well, we still want to get all existing languages imported, even if they are not edited in launchpad
[17:17] <carlos> sure
[17:17] <carlos> right
[17:18] <carlos> then you only need to care about your languages and other new languages appearing due to the use of Launchpad (it's an effect we have seen before, once it's available in Launchpad, you get new translations without even ask for them :-P
[17:18] <carlos> eaqua: also, we would like to give you the control of the netbeans translation group so you can add there new teams to block when they appear in netbeans
[17:18] <eaqua> do you know of some other Java-based tool that uses rosetta? I'm not certain msginit is enough as I haven't used .pot / .po files that much (I see them as an intermediary form or .properties :) ).
[17:19] <carlos> or give them the control of that language to the official teams if they decide to move to Launchpad
[17:19] <carlos> eaqua: not that I'm aware of... are those .pot files using IDs instead of English strings ?
[17:20] <eaqua> sounds good. let me first import something so I have a demo for them. then I'll tell the other teams I'll also import their stuff. I don't want to step on any toes there.
[17:20] <carlos> eaqua: we added something for Firefox support that improves that situation, although is not yet ready for .po file to be used...
[17:20] <carlos> so you have:
[17:20] <carlos> msgid "foo-id"
[17:20] <eaqua> carlos: no, .properties are key=value, where key=english string. these are transformed into .po by msginit.
[17:21] <carlos> msgstr "lalala"
[17:21] <carlos> so to see the English string you need something like en.po to compare
[17:22] <carlos> that's not going to be easy neither with Launchpad or any other .po editor
[17:22] <carlos> eaqua: although we plan to add something to deal with that soon
[17:22] <carlos> maybe you prefer to wait until then...
[17:22] <eaqua> how soon ? should I just wait ?
[17:23] <carlos> anyway, whatever you do now, will be compatible with our final 'fix'
[17:23] <carlos> so no need to do any reimport or migration
[17:23] <carlos> eaqua: I don't know, we don't have it scheduled yet
[17:24] <carlos> but seems like we will need it too for Ubuntu mobile, so maybe, in next 4-5 months, but don't take that as a promise, as said, we didn't schedule it yet
[17:24] <eaqua> ok, I'll just start importing things and will see in the future how we migrate.
[17:24] <carlos> ok
[17:24] <eaqua> does rosetta have support to translate whole .html files for example ?
[17:25] <carlos> eaqua: not in a native way
[17:25] <eaqua> or should I create a fake .po with a really long string.
[17:25] <carlos> you can use other tools to get a .pot file though
[17:26] <carlos> eaqua: if it's an xhtml file you can use xml2po -m html
[17:27] <carlos> eaqua: I need to leave right now
[17:27] <eaqua> ok, it seems I'll also have to create some scripts.
[17:27] <eaqua> thanks for the help.
[17:27] <carlos> you are welcome
[17:30] <xenru> Hi there
[17:30] <xenru> I'm adding new project to launchpad
[17:30] <xenru> and want to add translations 
[17:31] <xenru> but I can't find how to do it
[17:31] <xenru> can you help me?
[18:13] <towolf> hi,for joining beta-testers, do i poke someone, or just wait?
[18:18] <stdin> could send an email to launchpad-users@lists.canonical.com
[18:19] <mwhudson> towolf: mrevell is the man you need to get the attention of
[18:19] <mwhudson> he works uk time
[18:19] <towolf> mwhudson: thanks
[21:13] <mpt_> LongPointyStick, +emails
[21:16] <mpt> carlos, is language-by-language use of Translations (as desired for NetBeans) filed as something that needs implementing? Should it be?
[21:18] <carlos> mpt: yeah, Danilo raised that feature a while ago
[21:18] <carlos> to link pofiles or potemplates with persons or teams
[21:18] <carlos> instead of products or sourcepackages
[21:29] <mpt> carlos, I mean, does it have a bug number or a blueprint
[21:29] <carlos> hmm, not sure, let me check
[21:33] <carlos> mpt: no I think we don't have any bug or blueprint for it
[21:35] <mpt> ok, I shall report it
[21:39] <carlos> mpt: sure, thanks
[21:52] <mpt> carlos, eaqua: reported as bug 164420
[21:52] <ubotu> Launchpad bug 164420 in rosetta "Let projects choose which languages are translatable" [Undecided,New] https://launchpad.net/bugs/164420
[21:54] <carlos> mpt: ok, thanks
[22:00] <ubotu> New bug: #164420 in rosetta "Let projects choose which languages are translatable" [Undecided,New] https://launchpad.net/bugs/164420
[22:16] <mpt> hmm,
[22:17] <mpt> Quite often (about once a week, perhaps) someone asks a question about using Launchpad Translations with a particular language
[22:18] <mpt> And they mark the question as being in that language, when it's not, it's in English
[22:20] <mpt> Probably not knowing English very well makes it hard for them to understand the meaning of the language choice
[22:26] <emilian> ok, anyone here I can harass with questions regarding .pot and po files ?
[22:26] <mpt> emilian, carlos or danilos 
[22:26] <emilian> my limited knowledge tells me the pot are the templates while the po are the translated files.
[22:26] <emilian> with msginit -i $file -P I can convert java .properties files to .po files.
[22:27] <emilian> are the .pot files any different ? can I just rename .po to .pot ?
[22:27] <carlos> emilian: you are right about what's a template and a translation file
[22:27] <carlos> pot is a po without translations
[22:27] <carlos> in theory, you could rename a .po file as .pot
[22:27] <emilian> but as I start with .properties files I basically have a translations - english.
[22:27] <carlos> but why do you want to do it?
[22:28] <emilian> well, I'm not sure if a .po is enough to get translations working for other languages.
[22:28] <emilian> I assumed you need a .pot for that.
[22:28] <carlos> the  problem with properties files
[22:28] <emilian> does rosetta take the keys from .po files and expose them to any translator regardless of the language ?
[22:29] <carlos> is that they use an id instead of an English string...
[22:29] <carlos> ok, so I just realised what you mean
[22:29] <carlos> yeah
[22:29] <carlos> we plan to add a feature 
[22:29] <emilian> oh, alrighty then, I guess I'm set :)
[22:29] <carlos> to use en.po or en_US.po or en_GB.po as the base of strings to show to the users
[22:29] <carlos> so they know what to translate
[22:30] <emilian> i just generated and uploaded a whole bunch of en.po files.
[22:30] <emilian> do I need to re-upload those as ro.po files for example ?
[22:30] <emilian> (since you see you're just planning this feature).
[22:31] <carlos> well, you need an empty .po file as the .pot file
[22:31] <carlos> if en.po has English strings, you shouldn't rename it as ro.po
[22:32] <emilian> so I need to write some script to clean the en.po file in order to bootstrap any other language ? (ie. make the .pot)
[22:32] <carlos> emilian: there is a gettext command for that already
[22:33] <carlos> danilos: do you remember the command to do it?
[22:34] <danilos> emilian: you can try playing with msgattrib, msgmerge, and msgfilter
[22:34] <danilos> emilian: though, for generating POT file, you should use xgettext instead
[22:35] <emilian> xgettext seems to extract strings from source files (?). I already have the strings in java .properties files.
[22:41] <ubotu> New bug: #164424 in launchpad-answers "Confusing for "Project:" to have "Distribution" and "Project" choices" [Undecided,New] https://launchpad.net/bugs/164424
[23:02] <emilian> it seems msgfilter can produce a barebone po which kinda looks like a pot (empty translation strings - ""). I've submitted everything. Let's see how rosetta feels about the files...
[23:04] <emilian> carlos: if you aren't busy and have the appropriate privileges could you take a look here ( https://translations.launchpad.net/netbeans/+imports ) and approve / reject the uploads. I would like to see the results before I go to sleep :O
[23:12] <carlos> emilian: sorry, those are a lot of files to approve and is past midnight here..
[23:12] <emilian> carlos: dang, 1:12 am here :( oh well, I'll check again next week.
[23:13] <carlos> emilian: you will get email notifications with each import
[23:14] <emilian> heh, hope they don't end up in the spam again :) thanks for your help and good night !
[23:15] <carlos> np, good night!
[23:35] <ubotu> New bug: #164430 in soyuz "PPA takes too long to build packages" [Undecided,New] https://launchpad.net/bugs/164430