[12:23] <kiko-zzz> I'm on holida
[12:23] <kiko-zzz> y
[12:23] <kiko-zzz> what am I doing answering all these emails!!21!
[12:24] <kiko-zzz> ddaa, is it about SVN? :)
[12:25] <ddaa> yes
[12:26] <kiko-zzz> cool
[12:26] <kiko-zzz> should I stay around to read it, or can I read it tomorrow?
[12:26] <ddaa> Even though one knows that svn sucks, I'm still surprised now and then by how incredibly it does so.
[12:27] <ddaa> kiko-zzz: no reply is expected
[12:27] <kiko-zzz> aha
[12:27] <ddaa> I mean, if svn was a woman it would be a porn star!
[12:27] <lifeless> ddaa: score
[12:27] <lifeless> excellent bug
[12:28] <ddaa> lifeless: so we have been automatically DoSing random SVN server on the internet for like months...
[12:28] <lifeless> choosing to run svn implies tolerance
[12:32] <ddaa> lifeless: please make sure the bzr serve is bit better in that respect...
[12:32] <lifeless> sure
[12:32] <ddaa> like, if it receives bad input, it should send some rude message to the client, close the connection and NOT abort!
[12:34] <ddaa> sure that would be entertaining
[01:19] <lifeless> mmm
[01:19] <lifeless> https://launchpad.net/distros/ubuntu/edgy/+source/tickcount/+packaging
[01:19] <lifeless> seems that this page has been borked
[01:20] <lifeless> try to find the tickcount product in there
[01:22] <lifeless> ah
[01:22] <lifeless> we're still not enforcing have a product series
[01:30] <lifeless> kiko-zzz: https://launchpad.net/products/bzr/+distributions
[01:30] <lifeless> IIRC you were fixing those ?
[06:44] <jamesh> stub: I did up an SQL patch to rename the bugzilla-importer user to bug-importer.  Would it be possible to run it on the production db?
[06:45] <jamesh> well, an SQL file
[06:47] <stub> Sure.
[06:48] <stub> Does it need to be run as part of a code rollout? (eg. it renames a celebrity?)
[06:48] <jamesh> there is no celebrity at the moment (other than in my sourceforge-import branch that hasn't been merged yet)
[06:49] <stub> Ok. I'll rename bugzilla-importer to bug-importer on production now.
[06:49] <jamesh> the only thing that would stop working in production is the bugzilla-import script that we aren't running
[06:50] <stub> Changed via the UI
[06:50] <jamesh> brilliant.
[06:51] <jamesh> stub: this was the SQL I was going to get you to run: https://sodium.ubuntu.com/~andrew/paste/fileD7oIj4.html
[06:51] <jamesh> would it be possible to change the email too?
[06:52] <stub> Is that a valid email address?
[06:52] <jamesh> no
[06:53] <stub> I've hidden it anyway.
[06:53] <jamesh> well, it is a validated email address in the db (needed for login), but there is no mailbox behind it
[06:53] <stub> Why does that user need to be able to login?
[06:53] <jamesh> the script logs in with it
[06:53] <stub> via http?
[06:54] <stub> This sounds rather wrong
[06:54] <jamesh> no
[06:55] <jamesh> I mean it sets up the an interaction/principal with it when running (since some LP code breaks when there is no principal)
[06:55] <stub> Hmm... so the email address is there to hide a deeper bug.
[06:57] <jamesh> couldn't log in as a user without a preferred email in the script
[06:59] <stub> That would be a bug.
[07:01] <stub> Surprised it still worked, as the bug-importer user doesn't have a password. So there is some dodgy code that is detecting valid users where we don't want it, and it is doing it incorrectly too.
[07:16] <lifeless> stub: we still have products w/o product series occuring
[07:16] <lifeless> stub: I think RequireProductSeries is clearly not implemented
[07:16] <stub> Yes - there is a bug open on that.
[07:17] <lifeless> ok, as long as thou knowest
[07:18] <stub> I have some similar constraint work to do, so I might try enforcing it at the DB level to shake out the bugs
[07:19] <jamesh> lifeless: I think I can see the problem: products created from .../products/+new get a default series, but products created from .../projects/foo/+newproduct don't
[07:19] <jamesh> because the trunk series actually gets created in the browser code rather than db code
[07:19] <jamesh> and that code only occurs in one of the relevant view classes
[07:20] <lifeless> jamesh: surely it should be db code?
[07:20] <lifeless> its domain constraints after all
[07:20] <jamesh> lifeless: correct.
[07:31] <jamesh> lifeless: I've got the dyson changes mostly done
[07:32] <jamesh> haven't done any renaming though
[07:42] <lifeless> cool!
[07:46] <jamesh> lifeless: I've made it so that the file glob can contain slashes (e.g. foo-*/bar-*.tar.gz), so we can match limited heirarchies still
[07:46] <jamesh> but won't by default
[07:46] <lifeless> excellent
[07:46] <lifeless> thats exactly what I hoped for
[07:47] <jamesh> adding a sane_version() check should stop it from exploding like it did on the grass tarball too
[07:49] <jamesh> the dyson code is using the HCT unittest.TestCase subclass for its test cases, which makes things a little hard to debug
[07:49] <jamesh> since it redirects stderr, you don't see the actual error messages ...
[07:50] <lifeless> oh eww
[07:50] <lifeless> does it barf stderr in the failure ?
[07:50] <jamesh> well, the tracebacks that would be printed to stderr get captured
[07:51] <jamesh> making the output from test.py not that useful
[07:51] <jamesh> I've been changing the tests to plain unittest.TestCase where they aren't using features from hct's Scaffold class
[08:04] <lifeless> feel free to fix Scaffold
[08:04] <lifeless> capturing stderr is bogus
[08:05] <jamesh> lifeless: what do you think of "productreleasefinder" as a new name for dyson?
[08:05] <lifeless> good
[08:06] <lifeless> clear
[08:06] <lifeless> precise
[08:06] <lifeless> will annoy ddaa 
[08:06] <jamesh> it is a bit long, but beats UTRF :)
[08:06] <lifeless> wins on all fronts
[08:06] <lifeless> :)
[08:07] <jamesh> we don't seem to display the details of any of the files attached to product releases in the webapp, btw
[08:07] <jamesh> (at least, I haven't found where yet)
[08:07] <lifeless> we dont yet
[08:07] <lifeless> thats fine
[08:07] <lifeless> even a good thing :)
[08:13] <jamesh> why's that a good thing?
[09:18] <lifeless> jamesh: oh , because its a little conspriacy theorist to be backing up all those releases :)
[09:19] <carlos> morning
[09:20] <danilos> morning carlos 
[09:21] <carlos> danilos: hey
[10:03] <SteveA> morning
[10:11] <carlos> danilos: meeting time?
[10:23] <jamesh> morning SteveA 
[10:25] <carlos> hmm, I'm having a weird error with tests
[10:25] <carlos> https://sodium.ubuntu.com/~andrew/paste/fileNpO6Nc.html
[10:25] <carlos> any idea?
[10:26] <jamesh> carlos: do you have baz installed?
[10:26] <carlos> is it now a dependency?
[10:27] <SteveA> carlos: why do you need to run these tests?
[10:27] <carlos> SteveA: I just execute 'make check'
[10:27] <SteveA> don't do that
[10:27] <jamesh> I think it is for some of the importd tests (til they get switched over to bzr fully)
[10:27] <SteveA> because it runs lots more tests than you need to run
[10:27] <SteveA> and it will take a lot of time
[10:27] <SteveA> use: python test.py canonical.launchpad
[10:28] <SteveA> that takes less time
[10:28] <SteveA> pqm will run all the tests
[10:28] <carlos> ok, I didn't know we should change the command to run tests..
[10:28] <carlos> SteveA, jamesh: thanks
[10:28] <jamesh> SteveA: these importd tests are under canonical.launchpad.scripts.importd
[10:28] <SteveA> jamesh: ok :-)
[10:28] <carlos> hmm, so I still need to install bazaar
[10:29] <SteveA> or, use a better test command line
[10:29] <SteveA> to run just the tests you're interested in
[10:29] <SteveA> python test.py canonical.launchpad.ftests
[10:29] <SteveA> that will run launchpad tests but not the importd ones
[10:29] <jamesh> carlos: couldn't hurt.  In either case it is a lot quicker to limit the tests you run to the area you're working on
[10:30] <carlos> I guess I should also run test.py canonical.launchpad.tests right?
[10:30] <carlos> jamesh: well, I usually run just one test
[10:30] <carlos> but I did some sampledata changes
[10:30] <jamesh> ah.
[10:30] <carlos> and wanted to detect any other test breakage I just introduced
[10:47] <danilos> carlos: sorry, xchat didn't play the sound to notify me of the ping
[10:47] <stub> Launchpad is going down in 15 mins for its regular code update. Estimated downtime is under 10 minutes.
[10:47] <carlos> danilos: don't worry
[10:47] <carlos> stub: aren't you waiting for the data migration?
[10:48] <jamesh> stub: this'll include the pillar stuff, right?
[10:48] <stub> carlos: No. Once the code is fixed and tested, we can schedule the downtime then with mdz and co.
[10:48] <stub> jamesh: Pillar stuff is already landed as far as I know.
[10:49] <carlos> stub: the code is fixed already, I'm just doing some tests for other tests that I would break while adding the new tests
[10:49] <carlos> so I'm able to merge the changes into rocketfuel
[10:49] <carlos> in fact, my code changes are in your review queue since yesterday to be completely sure that you agree with the fix
[10:49] <jamesh> stub: really?  There is a "launchpad" project and "launchpad" product at the moment
[10:49] <jamesh> (in production)
[10:50] <stub> ok. Then it will include that. 
[10:50] <stub> r3908
[10:53] <carlos> stub: I think the testing server you gave me on Monday has its hard disk full
[10:53] <carlos> stub: https://sodium.ubuntu.com/~andrew/paste/filejviqPR.html
[11:06] <sivang> morning 
[11:20] <carlos> sivang: morning
[11:22] <stub> carlos: There is now more space on that server
[11:24] <carlos> I know, I was testing the script again
[11:25] <carlos> I was just pointing you the problem because I think you said the testing server for python guys is there
[11:25] <sivang> sabdfl: let me know if you received the email with the patch.
[11:26] <carlos> stub: btw, could you approve my changes to fix the script to open Edgy translations ?
[11:27] <carlos> stub: https://devpad.canonical.com/~jamesh/pending-reviews/carlos/launchpad/migrate-translations/full-diff
[11:28] <stub> carlos: r=stub
[11:28] <carlos> stub: ok, thanks
[11:31] <stub> carlos: So you were happy with the results of your script on staging and/or carbon?
[11:32] <carlos> yes, but I wanted to run it again today to be completely sure but got the error I told you
[11:33] <carlos> also, I forgot to get the time it got to run
[11:52] <stub> ok. You running it on staging, or should I build a fresh db on carbon to run against?
[11:53] <stub> carlos: ^^
[11:53] <carlos> it depends
[11:53] <carlos> staging will take a lot of time
[11:53] <carlos> carbon will be fast
[11:53] <carlos> I only want to time it
[11:54] <carlos> so it depends on what run will be helpful for you (I guess carbon one)
[12:15] <elmo> stub: ping?
[12:15] <stub> elmo: pong
[12:15] <elmo> stub: xmlrpc server down deliberately?
[12:16] <stub> I think todays landing moved it onto the same port as rest of the Launchpad HTTP traffic
[12:16] <stub> So the Apache rules will need to be adjusted. Want an RT ticket?
[12:17] <elmo> please
[12:17] <stub> elmo: What are you using to test btw? An actual XML-RPC request or just seeing if the server is responding?
[12:18] <elmo> -P"<?xml version='1.0'?><methodCall> <methodName>concatenate</methodName> <params> <param> <value><string>ubuntu</string></value> </param> <param> <value><string>rocks</string></value> </param> </params> </methodCall>" -s 'ubuntu rocks'
[12:19] <stub> heh
[12:38] <stub> carlos: Are you abusing asuka at the moment?
[12:38] <carlos> stub: I guess the language pack export script does
[12:39] <stub> carlos: Can you kill it?
[12:39] <carlos> sure
[12:39] <carlos> but that's on mawson
[12:39] <carlos> the database process will take a bit until it detects that I killed the script
[01:05] <stub>       Note: HTTP/1.1 servers are allowed to return responses which are       not acceptable according to the accept headers sent in the       request. In some cases, this may even be preferable to sending a       406 response. User agents are encouraged to inspect the headers of       an incoming response to determine if it is acceptable.  
[01:06] <stub> So always returning UTF-8 is not a violation of rules at all, which is good :)
[01:15] <LarstiQ> stub: mja 
[01:20] <heno> I'm trying to set up a bzr mirror on LP
[01:20] <heno> https://launchpad.net/people/henrik/+branch/onboard/devel
[01:21] <heno> The Mirror version is not a working branch yet, do just have to wait for it to sync later today?
[01:31] <jelmer> heno: yep, it takes up to a day (usually faster though)
[01:31] <heno> jelmer: ok, cool
[01:32] <heno> and from then on we can all just push stuff into that branch I guess
[01:32] <jordi> hey
[01:32] <jordi> carlos?
[01:32] <carlos> jordi: hi
[01:32] <carlos> how's going?
[01:32] <heno> do I need to set up a team to have multiple maintainers?
[01:33] <LarstiQ> heno: do you want to have your branch hosted on launchpad, or mirrored?
[01:33] <heno> LarstiQ: hosted ideally
[01:33] <carlos> stub: launchpad gives me a 'Bad Gateway' error
[01:33] <heno> didn't see an option for that though
[01:33] <jordi> carlos: as good as it can go on your first day. :)
[01:33] <stub> carlos: works for me
[01:34] <jordi> works for me too
[01:34] <carlos> stub: sorry, I was in launchpad.dev instead of launchpad.net ....
[01:34] <LarstiQ> heno: but I just push to sftp://bazaar.launchpad.net/~person/product/branch
[01:34] <carlos> jordi: holidays should be longer ;-)
[01:34] <LarstiQ> heno: person can also be a team, and then all the members can access it too
[01:34] <jordi> carlos: are you going to finishup xaralx now? If so, tell me when it's executed, and I can reply to his version 0.7 stuff
[01:35] <quail> http://radio.localfoss.org:8000/osota.mp3 every wednesday night at 9:30pm (UTC +1000)
[01:35] <heno> LarstiQ: right. I should probably set up an 'onBoard' team
[01:35] <LarstiQ> heno: right
[01:35] <carlos> jordi: yes, I will request the removals today
[01:36] <LarstiQ> heno: and the push to sftp://bazaar.launchpad.net/~onBoard/onboard/devel 
[01:36] <carlos> jordi: do we have a bug report about not showing who did a translation ?
[01:36] <carlos> jordi: I fixed that already, but I'm not able to find a bug about it
[01:37] <heno> LarstiQ: right, Does that need to be to 'sftp://onboard@bazaar.... ?
[01:37] <LarstiQ> heno: no
[01:38] <LarstiQ> heno: you use your own user to login, and team membership determines if you can access ~team
[01:38] <heno> cool
[01:40] <carlos> jordi: found
[01:41] <jordi> carlos: oik
[01:41] <jordi> carlos: ok I just replied to Neil with instructions regarding his new POT
[01:41] <jordi> I guess he'll want to just rename 0.4 to trunk.
[01:42] <carlos> jordi: yeah, just rename it
[01:46] <heno> Can I change the owner of s branch, rename it or delete it?
[01:47] <heno> the 'devel' branch is now registered under 'henrik' but it should be under 'onboard'
[01:48] <LarstiQ> stub: ^^?
[01:48] <heno> I could just register a 'main' branch under onboard and use that, but it starts getting untidy
[01:48] <heno> https://launchpad.net/people/henrik/+branch/onboard/devel
[01:50] <LarstiQ> heno: though there is no reason you can't also use 'devel' as a name for the onboard owned branch
[01:50] <stub> You can't rename or delete branches at the moment, and it is a real pita for admins to do it for you.
[01:50] <LarstiQ> stub: is this something for the faq?
[01:51] <heno> stub: ok, should I just set up a new one under 'onboard' and let the old one lay dormant?
[01:51] <stub> Probably, yeah. Who is looking after that at the moment?
[01:51] <stub> heno: That would be best. Eventually we will have the feature to at least hide it.
[01:51] <LarstiQ> heno: that is what I would do, yes.
[01:52] <heno> ok, thanks
[01:52] <heno> before I set one up, is there a difference between a hosted and mirrored branch?
[01:52] <heno> Can I actually set up a 'hosted' one?
[01:53] <LarstiQ> heno: I don't know about differences, but I create hosted ones just by directly pushing 
[01:53] <heno> ah ok, I'll try that
[01:53] <LarstiQ> and after that editing the information page
[01:53] <heno> I was using the web interface
[01:53] <heno> right
[01:54] <LarstiQ> though I suppose I could use register-branch for that last step
[01:54] <heno> an 'upload tarball to host' feature would be cool
[01:54] <heno> more intuitive
[01:55] <carlos> jordi: I just sent the request
[01:55] <jordi> carlos: yay!
[01:57] <LarstiQ> heno: I think that is covered in https://launchpad.net/products/launchpad-bazaar/+spec/branch-tarball-imports
[01:57] <heno> thanks, I'll look
[01:58] <LarstiQ> well, not much to see I'm afraid
[02:21] <mpt> carlos, it's bug 80
[02:21] <Ubugtu> Malone bug 80 in rosetta "cannot see who put in bad translation" [Wishlist,In progress]  https://launchpad.net/bugs/80
[02:27] <mpt> oh, you found it :-)
[02:45] <jordi> mpt: you pinged me a few days ago
[02:45] <jordi> I guess there was someone needing help, but if it was something else...
[02:46] <jordi> ah, you asked about me being around
[02:46] <jordi> I'm back now
[02:46] <mpt> jordi, remember the Kashubian plurals from July 15th
[02:47] <jordi> mpt: yes, I'm finding out what happened to those
[02:47] <jordi> danilunch: ping?
[02:50] <jordi> sigh, 100 held messages, 100 spams
[02:51] <mpt> jordi, and Andrea Vacondi's message from July 19th
[02:51] <mpt> Vacondio, rather
[02:51] <jordi> carlos: remember the mail I sent about pending plural forms? Were they added to the DB?
[02:51] <jordi> let me check that one out
[02:51] <carlos> jordi: hi
[02:51] <carlos> hmm
[02:51] <carlos> I don't think I have done it...
[02:51] <carlos> I don't even remember such email...
[02:51] <jordi> let me dig
[02:52] <jordi> ugh, only sent to danilo
[02:52] <jordi> damn
[02:54] <jordi> mpt: I see no such mail
[02:54] <jordi> oh, July 11
[02:55] <jordi> mpt: *shrug*, I think I answered the same question on another mail two days later or so
[02:55] <jordi> I can do it again tho
[02:56] <jordi> carlos: og maciel says whenever a new ooo gets imprted, translations entered through rosetta are marked fuzzy
[02:56] <jordi> makes sense?
[02:57] <carlos> jordi: no it doesn't 
[02:57] <jordi> it's in rosetta-users
[02:59] <carlos> jordi: I don't see the email...
[03:00] <carlos> just found it
[03:00] <jordi> ok
[03:00] <jordi> carlos: 3PM, leaving office, but will be back at 5 or earlier.
[03:00] <jordi> chat later
[03:00] <carlos> ok
[03:00] <carlos> later
[03:02] <stub> carlos: The db on carbon has been reset btw.
[03:03] <carlos> ok, I will run my code again
[03:03] <carlos> and give you the amount of time to execute it
[03:03] <carlos> so we can plan the migration
[03:23] <kiko> morning
[03:27] <Hobbsee> hey, if i revoke my old key, and create a new key, and add it to LP, what happens with regarding uploading packages?
[03:31] <kiko> Hobbsee, if your new key is in the accepted keyring, nothing should change.
[03:32] <Hobbsee> kiko: cool. how would i get it into the keyring again? just upload it to launchpad?
[03:32] <kiko> Hobbsee, one sec.
[03:36] <Hobbsee> ok
[03:43] <kiko> hmmm
[03:45] <kiko> Hobbsee, it should work as expected, yes.
[03:54] <Lure> hi all
[03:54] <Lure> my lure@ubuntu.com stopped to worked
[03:54] <Lure> since I was replacing my GPG key, it my be related to that
[03:55] <Lure> I have wrote to postmaster@ubuntu.com, but did not get any response
[03:55] <Lure> can somebody here look into this? It would be appreciated...
[03:57] <kiko> Lure, are you getting bounces when writing to it? 
[03:57] <salgado> stub, the 'Specifications' menu item's link is broken in production.  I guess it's related to some vhosting thing
[03:58] <Lure> kiko: exactly - <lure@ubuntu.com>: User unknown in virtual alias table
[03:58] <kiko> Lure, what's your launchpad ID?
[03:58] <salgado> stub, nevermind, just saw on the other channel that you're aware of it
[03:59] <Lure> kiko: https://launchpad.net/people/lure
[03:59] <kiko> yep
[04:00] <kiko> Lure, so it appears that yes you are still an ubuntu member. hmmm
[04:00] <Lure> kiko: I did change my GPG key in LP - this involved signing new CoC with new key
[04:01] <kiko> Lure, I don't think it should matter though
[04:01] <kiko> Lure, did you do so today?
[04:01] <Lure> kiko: no, it was at least a week ago, I just noticed that no mails were sent for some days and then tried it and it failed
[04:01] <kiko> Lure, let me check. one moment.
[04:01] <Lure> kiko: this is why I thought it may be related
[04:03] <kiko> Lure, I've asked a sysadmin to look into it, hang tight there
[04:03] <Lure> kiko: thanks
[04:12] <kiko> Lure, there's a loop in the config apparently. still looking into it.
[04:25] <BjornT> kiko: hi. would you have time for a pre-implementation call today? it's about adding a bugtracker to a product, i found some issues i'd like to discuss.
[04:25] <kiko> BjornT, sure, that'd be great. I need to finish up this week's launchpad release but there should be enough time
[04:26] <BjornT> kiko: cool. ping me when you are ready.
[04:28] <bradb> mpt: ping
[04:39] <stub> Bah. I need a page test that connects to https://, as my code sniffs the URL to see if it is https:// so it knows if it should set the Secure attribute on the cookie. But it doesn't work :-P
[04:40] <stub> So I appear to have a feature I can't test :-(
[04:40] <kiko> stub, you mean using testbrowser and https doesn't work?
[04:40] <stub> Yup
[04:41] <kiko> you seem to be right
[04:41] <kiko> there are no other cases either
[04:46] <carlos> kiko: Do you have 5 minutes?
[04:47] <kiko> carlos, I want to say yes, but I'm kinda fucked. yes
[04:47] <carlos> I think I found a bug in our batching code
[04:47] <carlos> kiko: ok, don't worry then
[04:47] <kiko> carlos, tell me
[04:48] <carlos> kiko: http://gollum.pemas.net/distros/ubuntu/hoary/+lang/hr/+index?start=0&batch=2
[04:48] <carlos> and http://gollum.pemas.net/distros/ubuntu/hoary/+lang/hr/+index?start=2&batch=2
[04:48] <carlos> if you see the link for the templates with the name 'man'
[04:48] <carlos> both are the same
[04:49] <carlos> but, if you look at http://launchpad.dev/distros/ubuntu/hoary/+lang/hr the links aren't duplicates
[04:49] <carlos> so seems like the batching code is doing something weird while batching that list...
[04:52] <kiko> let me see.
[04:52] <kiko> carlos, that host isn't answering..
[04:52] <carlos> hmm
[04:52] <carlos> sorry
[04:52] <carlos> gollum.pemas.net:8086
[04:53] <kiko> Zero Sized Reply
[04:55] <salgado> carlos, you have to add that hostname to your main_hostname config variable
[04:56] <carlos> salgado: right, thanks
[04:56] <carlos> kiko: try again
[04:56] <carlos> my router sucks so I cannot check that hostname
[05:00] <kiko> trying again
[05:00] <kiko> ah
[05:00] <kiko> action
[05:01] <kiko> http://launchpad.dev/distros/ubuntu/hoary/+source/evolution/+pots/man/hr/+translate
[05:01] <kiko> http://launchpad.dev/distros/ubuntu/hoary/+source/pmount/+pots/man/hr/+translate
[05:01] <kiko> carlos, they are not actually the same, eh?
[05:01] <carlos> right, are different
[05:02] <carlos> two different sourcepackages
[05:02] <kiko> carlos, so I didn't understand your problem.
[05:02] <kiko> what should the links be?
[05:02] <carlos> kiko: that's the right value
[05:03] <carlos> but when you look at the batched pages
[05:03] <carlos> the links are the same
[05:03] <carlos> instead of different
[05:03] <carlos> hmm
[05:03] <carlos> now are different?
[05:03] <kiko> are you confused?
[05:03] <carlos> am I getting mad ?
[05:03] <carlos> kiko: yeah, I'm confused
[05:04] <carlos> even pqm rejected my merge request because got the same error
[05:06] <carlos> kiko: take a look now
[05:06] <carlos> I see them equal after restarting the server
[05:09] <kiko> ah.
[05:09] <carlos> kiko: do you see it now?
[05:10] <kiko> carlos, yes. the problem you are having is that your query is probably producing ambiguous ordering.
[05:10] <carlos> I see
[05:10] <kiko> yes/
[05:10] <kiko> reload this page a few times:
[05:10] <kiko> http://gollum.pemas.net:8086/distros/ubuntu/hoary/+lang/hr/+index?start=1&batch=2
[05:10] <kiko> you'll see for yourself.
[05:11] <kiko> so, bugs in batching code: zero. bugs in rosetta code: 1. I win!
[05:11] <carlos> kiko: ;-)
[05:12] <carlos> thanks
[05:15] <BenC> hey, would it be much trouble to make the "Dist" selection for a bug default to "nothing", or allow it to be changed after the fact?
[05:16] <kiko> BenC, when you indicate that the bug is also present in another distribution, BenC?
[05:17] <BenC> well, people add a dist target to a bug, and it gives the the "dist" and "source" selection page
[05:17] <BenC> it defaults to Baltix
[05:17] <BenC> and some people just forget to change it, and then there's no way to change it later, so we get lots of Baltix cruft being rejected in bug reports :)
[05:18] <kiko> BenC, yeah, we should fix that. can you give me an example of a bug?
[05:20] <BenC> #55929
[05:24] <BenC> oh, and thanks a LOT for switching the comment fonts on lp to monospace :)
[05:24] <kiko> BenC, thank mpt ;)
[05:24] <BenC> makes reading all the formatted paste a lot easier
[05:24] <BenC> mpt: thanks!
[05:26] <jordi> danilos: when mailing stub, you mail the launchpad list too
[05:27] <kiko> BenC, so for that bug, did you click it as "also affects +distribution" and then chose baltix by mistake? 
[05:27] <BenC> I didn't, someone else did
[05:27] <kiko> BenC: https://launchpad.net/products/launchpad/+bug/55929/+activity
[05:27] <Ubugtu> Malone bug 55929 in linux-source-2.6.15 "DMA not enabled for IDE disks" [Untriaged,Unconfirmed]  
[05:27] <BenC> but they didn't clock Baltix by mistake, they just didn't select Ubuntu, so it defaulted to what was selected
[05:27] <kiko> BenC, it says you did :-P
[05:27] <BenC> ok, maybe I did :)
[05:27] <kiko> heh
[05:28] <BenC> I just grabbed that bug from a random search :)
[05:28] <kiko> it's fine, anyway, it's not anybody's fault but launchpad's
[05:28] <matsubara> kiko, BenC: bug 50018
[05:28] <Ubugtu> Malone bug 50018 in malone "Linux Distribution field should be a neutral default" [Low,Confirmed]  https://launchpad.net/bugs/50018
[05:28] <kiko> matsubara, that's not the right fix, I suspect -- well the UI there needs changing.
[05:29] <BenC> that's pretty much the type of fix I was looking for
[05:29] <BenC> but being able to change it would be good too
[05:31] <kiko> agreed.
[05:34] <danilos> jordi: ok, sure
[05:37] <kiko> carlos, danilos: I need that rosetta highlights document, covering the past two weeks, NOW.
[05:37] <carlos> kiko: ok
[05:37] <kiko> one-two paragraphs is fine
[05:38] <carlos> danilos: do you have time to prepare it now ?
[05:38] <kiko> it should cover what's in the rollout
[05:38] <danilos> carlos: yeah, it's ready already :)
[05:38] <carlos> kiko: I don't think we did any merge that ended in todays rollout
[05:39] <kiko> carlos, that's a shame
[05:39] <danilos> carlos: now I am not sure what you're talking about? highlights or pluralforms query?
[05:39] <carlos> kiko: danilos had a bunch of merges that got merged on Monday
[05:39] <kiko> but you can cover work that was done in the production instance, or whatever.
[05:39] <kiko> edgy translations progress
[05:39] <kiko> etc
[05:39] <carlos> and I was on holidays + with Edgy translations
[05:39] <carlos> sure
[05:40] <danilos> what was the last revision that got rolled out today? my merges should fix a couple of annoying bugs
[05:40] <carlos> danilos: https://launchpad.canonical.com/LaunchpadProductionStatus 
[05:40] <danilos> carlos: we also need to talk about ubuntu i18n position
[05:40] <carlos> danilos: subscribe to that page so you know exactly what's in production
[05:40] <carlos> danilos: I know, but I don't have enough time today for all those things....
[05:41] <carlos> danilos: let's finish the documentation kiko asked us for last Monday
[05:41] <carlos> kiko: I guess you got the initial email on Monday, right?
[05:41] <carlos> danilos: and tomorrow, we have the meeting about the open position
[05:42] <carlos> danilos: is that ok for you?
[05:43] <danilos> carlos: sure
[05:43] <kiko> carlos, yep
[05:43] <carlos> ok
[05:59] <kiko> SteveA, do you know what PillarGotchis are?
[05:59] <jamesh> kiko: product/distro/project logos
[06:00] <SteveA> kiko: I do
[06:00] <kiko> jamesh, wow, that's a new one. nobody mention that on the ML?
[06:00] <jamesh> kiko: tamagotchi -> hackergotchi -> pillargotchi
[06:00] <kiko> jamesh, but stub's patch is just for infrastructure, yes?
[06:01] <jamesh> which one?
[06:01] <kiko> revno: 3898
[06:02] <jamesh> guess it is just the DB changes
[06:02] <kiko> ok.
[06:06] <kiko> jamesh, SteveA: do you know what toini.py is going to be used for, btw?
[06:06] <jamesh> kiko: changing launchpad.conf from XML to a .ini file
[06:07] <jamesh> so we have something easier to work with than ZConfig
[06:07] <kiko> great that people openly discuss these things
[06:07] <kiko> instead of hiding them inside [trivial]  commits!
[06:07] <jamesh> we did ... in person
[06:07] <kiko> that's a rather smug definition of "openly"
[06:09] <jamesh> yep.  We should post more about these things on the list.  I should probably post something more about the new formlib stuff (since I've just mentioned it at the meeting and pointed people at the docs)
[06:09] <kiko> jamesh, I was /about/ to ask you to write a one-line description of how cool that is so it can go into the release announcement now
[06:11] <salgado> SteveA, so, I need that because I use the request inside the else part, to get the shipit layer provided by it
[06:13] <jamesh> kiko: the "pillargotchi" stuff is part of the new UI stuff (and an idea we've had before, to allow projects to add limited branding to their LP pages)
[06:14] <jamesh> kiko: I know there were talks of simplifying the config machinary, but didn't know the specifics
[06:16] <kiko> oookay
[06:16] <kiko> jamesh, about formlib I meant though
[06:18] <jamesh> kiko: I was referring more to openly discussing things -- I don't think there is a concious effort not to keep the team aware of what's being done
[06:20] <jamesh> kiko: a lot of this stuff is just fallout from face to face meetings, so it isn't too surprising to see UI related stuff going in without much discussion on the list while the UI sprint is going on
[06:20] <SteveA> salgado: bbaib
[06:20] <jamesh> kiko: do you want a short description of the formlib stuff now, or would waiting til tomorrow when I can compose a full email be okay?
[06:21] <jamesh> kiko: and are you after a developer oriented description or user oriented description?
[06:21] <kiko> jamesh, user oriented, and one-paragraph is fine.
[06:25] <jamesh> kiko: here goes: We have begun using zope.formlib for forms in Launchpad, and will be converting existing forms over to the new infrastructure.  This common infrastructure will allow us to roll out improvements to all forms such as better error display and AJAX based on-the-fly validation.
[06:26] <kiko> jamesh, wooo! 10 points to you
[06:29] <jamesh> kiko: at the moment there isn't much to see from a user perspective.
[06:29] <kiko> I know. that's fine
[06:31] <SteveA> salgado: fine.  I see now.  Please add a comment saying that you need the request if there is no rootsite, and also for handling the different shipit sites.
[06:31] <salgado> SteveA, sure, will do that
[06:31] <SteveA> salgado: other than that, the infrastructure changes are fine with me.
[06:32] <salgado> SteveA, cool, thanks for the review.  I'll find someone to review the rest and will add a note that you're okay with the infrastructure changes
[06:57] <carlos> see you!
[07:05] <jordi> danilos: er, which is the last mail you got from neil?
[07:05] <danilos> jordi: one from yesterday I think
[07:06] <danilos> jordi: actually, I got one today
[07:07] <danilos> just that carlos left :(
[07:07] <danilos> btw I think his timezone is wrong, or his mails take really long time to get here
[07:07] <danilos> jordi: Date: Wed, 16 Aug 2006 11:10:53 +0100, and I got it just now
[07:09] <jordi> does it talk about the branch rename?
[07:10] <jordi> oh silly
[07:10] <jordi> I just found the email
[07:16] <ddaa> hey, any hint where I can look for inspiration to do complex form validation (involving the combination of three fields) using LaunchpadFormView?
[07:19] <salgado> ddaa, inspiration?  have you checked the validate() method?
[07:20] <ddaa> mh, yeah, quick look at LaunchpadFormView is useful
[07:21] <ddaa> I assumed it was the same crazy mess as the old stuff, but it's not :)
[07:21] <salgado> ddaa, GeneralFormView has a validate() method for ages already
[07:21] <salgado> ages == a few months, actually. ;)
[07:22] <ddaa> *nod* since my webapp foo is so low, I prefer asking before going on random tracks
[07:28] <DktrKranz> hello
[07:29] <DktrKranz> i've got a problem with ubuntu wiki
[07:29] <DktrKranz> it seems my account has been deleted
[07:29] <DktrKranz> any hint?
[07:45] <mdz> BjornT,bradb: who can set milestones on bugs?
[07:46] <seb128> mdz, kiko, whoever is concerned: what team membership do I need to set a milestone?
[07:46] <seb128> hum, mdz faster ;)
[07:47] <sabdfl> sivang: why would this patch fail to apply cleanly? did you merge recent changes?
[07:48] <kiko-fud> seb128, mdz: bug contact or owner for the relevant context.
[07:49] <mdz> kiko: the bug contact is ubuntu-bugs, of which seb128 is a member, but he can't set milestones apparently
[07:49] <seb128> I can't set milestone for totem neither
[07:49] <seb128> and I'm package maintainer for that one
[07:50] <milosz> how do i link to an external package
[07:51] <mdz> seb128: did this just change recently, or has it been a problem for a while?  I thought this was fixeud
[07:51] <mdz> fixed
[07:52] <kiko> seb128, can you give me an example bug?
[07:52] <seb128> mdz: it's an issue since between dapper and the Paris summit IIRC
[07:52] <seb128> kiko: https://launchpad.net/distros/ubuntu/+source/totem/+bug/4229
[07:52] <Ubugtu> Malone bug 4229 in totem "Totem receives BadAlloc when playing very large movies using Xv" [Medium,Confirmed]  
[07:52] <seb128> kiko: random one, I just picked a totem bug
[07:56] <mpt> bradb, pong
[07:56] <kiko> seb128, can you by any change change the milestone if you first clear out the package name?
[07:57] <kiko> errr
[07:57] <kiko> seb128, can you by any chance change the milestone if you first clear out the package name?
[07:59] <seb128> kiko: clear the package name?
[07:59] <seb128> like reassing the task to "Ubuntu"?
[08:00] <kiko> seb128, yes. use staging if you prefer
[08:00] <seb128> kiko: https://launchpad.net/distros/ubuntu/+bug/7839 by example doesn't list the milestone option
[08:00] <Ubugtu> Malone bug 7839 in Ubuntu "Ubuntu bug reporting tools need to point to Ubuntu bug systems" [High,Confirmed]  
[08:02] <milosz> it seams like i can register an external CVS/SVN branch along along with a path to the source tar balls, but i cannot register a release series for a bzr branch with tarballs
[08:03] <kiko> mdz, does this only affect seb128, or all developers?
[08:04] <ddaa> salgado: how do I quote text in the message to LaunchpadFormView.setFieldError?
[08:04] <seb128> kiko: when I spoke with other people that was everybody, but that was some time ago (like around Paris summit)
[08:04] <milosz> for example i have no way of uploading a debian package, uploading/linking to a source package: https://launchpad.net/products/drapes/0.5-pre/0.4.95
[08:05] <seb128> kiko: I mentionned it during the summit but didn't really bother since because we are not in period where we set a lot of milestoned bugs yet
[08:05] <ddaa> I want to given an error message that includes a hyperlink
[08:05] <kiko> seb128, I thought this was fixed and tested, which is why I'm confused now by what you are saying. bradb, ping?
[08:06] <seb128> kiko: I was not able to set importance for some time which has been fixed
[08:06] <seb128> kiko: maybe it has been fixed for the milestone for other people but not for me then
[08:07] <salgado> ddaa, if you add an "<a href="foo">foo</a>" it comes out escaped in the page?
[08:07] <ddaa> Not tried yet.
[08:07] <seb128> sfllaw: can you set the milestone of bugs?
[08:07] <ddaa> But if I do that I need to escape the strings I inject.
[08:07] <kiko> seb128, so importance works but milestone doesn't? ARGH. how annoying
[08:07] <ddaa> hence my question
[08:07] <seb128> kiko: yep
[08:07] <seb128> kiko: but "importance" is available for ubuntu-qa team
[08:08] <seb128> kiko: ie: bug triagers
[08:08] <seb128> kiko: where milestone is not supposed to be
[08:08] <kiko> seb128, oh? milestone is supposed to be available to whom? drivers only?
[08:08] <seb128> dunno, that was my question
 mdz, kiko, whoever is concerned: what team membership do I need to set a milestone?
[08:08] <seb128>  hum, mdz faster ;)
[08:08] <kiko> ah.
[08:09] <sfllaw> seb128: Nope, I can't.
[08:09] <seb128> k
[08:09] <seb128> kiko: I think previous discussion went to the same point
[08:10] <seb128> like "what team is supposed to be able to do that"
[08:10] <salgado> ddaa, isn't cgi.escape() what you want?
[08:10] <seb128> and that was something to sort between you and mdz
[08:10] <mdz> kiko: the bug contact should be able to set it
[08:10] <kiko> seb128, checking.
[08:10] <mdz> until such time as we have some workflow for nominations of milestone targets
[08:10] <ddaa> salgado: since it's encapsulated in canonical.launchpad.validators._quote, I thought it was off-limits
[08:11] <kiko> mdz, meaning anybody in ubuntu-qa should be able to do it?
[08:11] <seb128> no
[08:12] <mdz> kiko: ubuntu-bugs is the bug contact
[08:12] <kiko> mdz, ubuntu-qa is a member of ubuntu-bugs.
[08:12] <mdz> kiko: yes
[08:12] <mdz> as are ubuntu-dev, u buntu-core-dev, etc.
[08:12] <mdz> s/u b/ub/
[08:12] <kiko> right
[08:12] <kiko> but well
[08:12] <seb128> I'm not sure bug triagers should be able to set the milestone
[08:12] <kiko> are you suggesting that the permissions for importance and milestone should be the same?
[08:12] <seb128> that's something for the maintainer usually
[08:12] <mdz> seb128: let's not argue ideal semantics here; I'm trying to fix your problem
[08:13] <seb128> mdz: right, but I'm not sure that giving milestone to the whole ubuntu-qa is the way to solve it ;)
[08:13] <kiko> mdz, it won't be fixed immediately, and the proper fix might not be too hard, so...
[08:13] <mdz> it's better for more people to be able to set it than fewer
[08:13] <seb128> right
[08:13] <kiko> I'd rather you discussed it and decided which is best.
[08:13] <mdz> kiko: experience with these issues shows that it takes a long time and a lot of discussion to get it right
[08:13] <mdz> kiko: meanwhile, we're completely unable to use the feature
[08:13] <mdz> at all
[08:14] <kiko> mdz, short-term solution, add seb to drivers.
[08:14] <kiko> if you do want a short-term solution
[08:14] <mdz> kiko: that is a poor solution
[08:14] <kiko> mdz, it is at least immediate, requiring no code changes 
[08:14] <mdz> we've added people to drivers as workarounds in the past
[08:14] <mdz> and the underlying problems have never been fixed
[08:15] <kiko> mdz, well, in this case I don't think we know what the underlying problem is yet.
[08:15] <mdz> kiko: the proper fix is too hard
[08:15] <kiko> so I don't think rushing to the code to fix something...
[08:15] <kiko> oh?
[08:15] <mdz> the proper fix is that anyone should be able to nominate a bug for a milestone, and the release team approve those nominations
[08:16] <mdz> I think rushing is absolutely the right thing to do here; it's been a problem for months now and nothing has been done
[08:17] <kiko> mdz, I think you have failed to communicate clearly what needed to be done. if you had, it would have been done!
[08:17] <kiko> it's not a large change -- two methods
[08:18] <kiko> I'm more concerned that this will once more prove insufficient for what you want
[08:18] <mdz> what do I need to do? file a bug in malone with a 'crippling development' tag?
[08:18] <kiko> mdz, is there no bug filed on this?!
[08:18] <mdz> I just looked and I can't find one
[08:18] <mdz> at least not an open one
[08:18] <kiko> it's been broken for months and yet no bug has been filed. tsk tsk. :)
[08:19] <kiko> mdz, so, to clarify, you think the behaviour for milestone editing should be identical to that of importance handling?
[08:19] <mdz> dude, we've had at least one prior conversation about this in this very channel
[08:20] <mdz> kiko: that is my recommendation for an immediate solution, yes
[08:20] <mpt> Report Bugs
[08:20] <kiko> mdz, yeah, but sometimes IRC is too transient a medium. anyway, I'll file a bug for you
[08:20] <mdz> this feature, and then later its access control, were both implemented without good requirements
[08:21] <mdz> so it's not clear how they should be used, or whether they are what we need
[08:21] <mdz> I'd like to gather requirements and do this right, but now is not the time
[08:21] <kiko> mdz, this is hardly an argument for rushing, though. unless you want to have this discussion again in this channel...
[08:21] <kiko> anyway
[08:22] <mdz> kiko: what would be a good argument?  this was working sufficiently for us, then it was broken by a change.  would you prefer to revert the change or make this small adjustment?
[08:23] <kiko> mdz, I am just saying we should consider better what needs to be done to avoid us wasting time on this again. 
[08:23] <kiko> if it is /really/ just matching importance to milestone perms, then fine.
[08:23] <mdz> kiko: I agree, but that doesn't address the immediate problem
[08:23] <kiko> mdz, the immediate problem, /today/, is only solvable by adding seb to drivers today
[08:23] <mdz> we need a two-phase solution: 1) get the team able to use milestones again, 2) re-think milestones and make them do what we want
[08:23] <kiko> ok.
[08:24] <mdz> this is not a seb problem, it is a problem for all developers
[08:25] <mdz> kiko: I will discuss milestones with the team next week during our scheduled bug workflow discussion and pass on the feedback to you
[08:25] <mdz> but that will take weeks
[08:25] <kiko> okay
[08:26] <kiko> https://launchpad.net/products/malone/+bug/56618
[08:26] <Ubugtu> Malone bug 56618 in malone "Milestone restrictions are too restrictive for Ubuntu" [Untriaged,Unconfirmed]  
[08:26] <mdz> meanwhile, is ubuntu-drivers the best short-term solution you can offer?
[08:27] <kiko> mdz, I've filed a bug and am going to ask somebody to fix it ASAP. but it won't get rolled out today.
[08:27] <mdz> disabling access control for milestones entirely would be perfectly acceptable to me in the short term
[08:27] <kiko> mdz, you can add ubuntu-core-dev to drivers for now...
[08:27] <kiko> mdz, it's not done in the database. it's done in the code.
[08:27] <mdz> but disabling access control for the stuff that ubuntu-drivers can do, not so much
[08:28] <mdz> I'm not entirely sure of everything ubuntu-drivers can do
[08:28] <kiko> approve spec and sprint nominations, I believe.
[08:29] <mdz> ubuntu-drivers is the registrant for the ubuntu distro
[08:29] <kiko> yeah, it can also do pretty crazy stuff I guess
[08:29] <kiko> I hadn't noticed that
[08:29] <kiko> how weird though
[08:29] <kiko> there is a driver slot but nobody uses it.
[08:30] <kiko> mdz, is milestone setting akin to approving a spec for a distrorelease? or more akin to setting importance?
[08:30] <sabdfl> drivers should also be able to approve bugs, for release management purposes
[08:30] <jordi> danilos: do you think you'll manage with the plural forms request?
[08:30] <kiko> sabdfl, well, ubuntu's driver is currently NULL. :)
[08:30] <sabdfl> milestones should require no approval
[08:30] <sabdfl> kiko: and edgy's?
[08:31] <kiko> ubuntu drivers. a bit redundantly.
[08:31] <kiko> (since the registrant is also ubuntu drivers)
[08:31] <kiko> eeeenyway
[08:31] <sabdfl> the "set of drivers" for a distrorelease is (a) the release driver, (b) the distro driver, and if both of those are none, then I believe the distro owner/registrant takes the job
[08:31] <sabdfl> i don't think the distrorelease registrant is a factor
[08:32] <mdz> I find this all very confusing
[08:32] <sabdfl> we only changed the "registrant" on the distro/release because it was being used in an overloaded way, for a role, and there was no way to specify the role
[08:32] <sabdfl> mdz: how can i help?
[08:32] <kiko> I was about to say that. 
[08:32] <mdz> my position in the past is that the most robust solution to access control for most of our problems is a good, smooth nomination process
[08:32] <sabdfl> nomination of waht
[08:32] <mdz> most things which need access control
[08:33] <mdz> importance changes, status changes, milestone changes
[08:33] <mdz> spec targeting (we have approvals there)
[08:33] <mdz> uploads
[08:33] <sabdfl> i can only speak for blueprint
[08:33] <sabdfl> with specs, registering a spec on a product/distro requires no permission
[08:34] <mdz> the answer in most cases for things that we want to be access-controlled is that we should liberally allow people to try, but require that the action be confirmed by an authority
[08:34] <sabdfl> anyone can do it
[08:34] <sabdfl> targeting it to a release/series DOES require a nomination/approval process
[08:34] <sabdfl> though in future, i would like products/distros to be able to turn that off if they want to run in "lightweight" mode
[08:34] <mdz> anyone should be able to upload a package to edgy, but unless they're in ubuntu-dev it should sit in a queue where someone in ubuntu-dev needs to review and approve it
[08:34] <sabdfl> you have exactly that in blueprint
[08:34] <sabdfl> mdz: disagree in that case, because of the consequences of a click fuckup
[08:34] <kiko> sabdfl, well, the unapproved specs do show up in listings, though
[08:35] <mdz> anyone should be able to say that they think a bug's status should be raised, but a QA member should have to approve it before it takes effect
[08:35] <sabdfl> we will have PPA's for that
[08:35] <sabdfl> upload to PPA, and request a sync
[08:35] <mdz> anyone should be able to say that a bug is relevant for a release milestone, but the release team gets the final say
[08:35] <sabdfl> kiko: they only show up in listings of unapproved specs ;-)
[08:35] <mdz> anyone should be able to request a sync or backport, but the archive admins or backport team need to OK it
[08:35] <sabdfl> agree
[08:35] <sabdfl> did you find the drivers part confusing?
[08:36] <mdz> sabdfl: if you're concerned about click fuckups, the approval process for that one can be more involved, requesting confirmation or something. no reason to reject the idea out of hand.
[08:36] <mdz> sabdfl: I find the different roles we have today confusing, yes
[08:36] <sabdfl> bug targeting to releases iwth nomination/approval has been requested since July last year, but it's now under development
[08:36] <mdz> it's not clear what privileges are associated with each slot
[08:37] <sabdfl> "drivers" is a common term for "the people wot decide yes or no to bugs or features"
[08:37] <sabdfl> at least, in mozilla-speak ;-)
[08:37] <mdz> however
[08:37] <mdz> we have two things called 'drivers'
[08:37] <mdz> we have an 'ubuntu-drivers' team, which holds certain privileged slots
[08:37] <sabdfl> kernel-speak?
[08:37] <mdz> like registrant of the ubuntu distro
[08:37] <sabdfl> well, that's dumb, ain't it
[08:37] <sabdfl> it should not be that way
[08:37] <mdz> then there is a 'driver' slot on some objects
[08:37] <mdz> which kiko says is unused
[08:38] <sabdfl> incorrect
[08:38] <sabdfl> so, you only NEED a driver for a release
[08:38] <mdz> ubuntu's driver is NULL
[08:38] <sabdfl> because anybody can file a bug on the distro, and nobody gets to approve or decline that, same for a spec
[08:38] <sabdfl> right, because you only NEED a driver for the release
[08:38] <sabdfl> and that is set, correctly
[08:38] <sabdfl> it is possible to specify an OVERALL driver, for the distro
[08:39] <sabdfl> and a specific driver, for a specific release
[08:39] <sabdfl> both have "driver" permissions on a release
[08:39] <mdz> so you need to be a driver for the distro to file a bug if it's non-null?
[08:39] <sabdfl> NO!
[08:39] <sabdfl> the point being drivers are only USED on a release
 ubuntu's driver is NULL
 because anybody can file a bug on the distro, and nobody gets to approve or decline that, same for a spec
[08:39] <mdz> oh, sorry, you were continuing your sentence, not responding to me
[08:39] <sabdfl> exactly - nobody gets to approve or decline, so you don't need a "driver" on a distro
[08:39] <sabdfl> yes
[08:40] <sabdfl> so why have it on both distro and release?
[08:40] <sabdfl> because drivers also make backporting decisions
[08:40] <sabdfl> so I would have you, colin, a very small team have drivers on Ubuntu (the distro)
[08:40] <sabdfl> you can approve anything in any release as a result
[08:40] <sabdfl> make Pitti the driver on Dapper, say (well, a small "dapper backport team")
[08:41] <sabdfl> and make a broader QA team the driver on Edgy
[08:41] <sabdfl> now, anybody can propose stuff to dapper or edgy
[08:41] <sabdfl> you can approve anything anywhere (with colin + fabio, the core team)
[08:41] <sabdfl> and sfllaw etc can also take care of Edgy, where the focus is
[08:41] <sabdfl> make sense?
[08:41] <mdz> OK, I now understand your concept for drivers
[08:41] <mdz> but today, we don't have most of that
[08:41] <sabdfl> it can be NULL on both distro and distrorelease
[08:41] <sabdfl> you have it all for specs
[08:42] <mdz> yes, and only that as far as I'm aware
[08:42] <mdz> there's nothing else to approve
[08:42] <sabdfl> if it is NULL on both, then the distro.owner/registrant is used
[08:42] <sabdfl> well, hence my driving hard for a long time to get BugTask.distrorelease
[08:42] <sabdfl> that should give you really good QA
[08:42] <sabdfl> simon and team of volunteers can manage the firehose
[08:43] <mdz> so now that I'm clear on what you mean by drivers, I have an additional issue (how to clean up the privileged teams to match that), as well as my original issue (how to fix the current situation with milestones)
[08:43] <sabdfl> you look at a defined SET of bugs-for-the-release only
[08:43] <sabdfl> what's the current situation with milestones?
[08:43] <sabdfl> milestones should have NO restrictions - they are fast and loose and freeform
[08:43] <mdz> the situation is that the development team is unable to set milestones on bugs
[08:44] <mdz> this has apparently been true for a couple of months now.  I thought it had been resolved, but seb128 brought it to my attention today that it's still a problem
[08:44] <sabdfl> !
[08:44] <sabdfl> that's a bug
[08:44] <mdz> that's why I'm here
[08:44] <mdz> to talk about how to address that bug
[08:44] <sabdfl> i was thinking that ANYBODY should be able to set that field
[08:45] <sabdfl> though perhaps it woulod be better to allow assignee's, and drivers
[08:45] <mdz> again, I think that anyone should be able to propose it, and the release team approve it
[08:45] <sabdfl> the idea is that a milestone is something that individual developers can use to agrregate their personal "this is what I'm tracking for the next week or two"
[08:45] <sabdfl> mdz: disagree
[08:45] <sabdfl> the idea is to have a heavyweight process, AND a lightweight process
[08:45] <mdz> I don't want to argue the blue sky version right now
[08:45] <mdz> I want to solve my team's problem
[08:46] <sabdfl> you need to get the bug fixed, but you were asking for nomination/approval on milestones, which i'm against
[08:46] <sabdfl> separate conversations
[08:46] <mdz> I absolutely was not; if you read back, you'll see that
[08:46] <sabdfl> (19:45:27) mdz: again, I think that anyone should be able to propose it, and the release team approve it
[08:46] <mdz> that is someday, I'm talking about now
[08:46] <mdz> we can disagree about someday another time
[08:47] <sabdfl> let me split up my sentence
[08:47] <mdz> please, pretty please, help me with my today problem
[08:47] <sabdfl> (a) you need to get that bug fixed
[08:47] <sabdfl> that is between you and kiko and bradb
[08:47] <sabdfl> (b) you were asking for nomination/approval on milestones, which i'm against
[08:47] <mdz> that is the discussion we were having when we were sidetracked by this discussion about drivers
[08:47] <sabdfl> that's the conversation i was having
[08:48] <mdz> ok, can we put that conversation on hold until we can give it the attention it deserves?
[08:48] <sabdfl> kiko: the drivers thing all clear on your side?
[08:48] <kiko> sabdfl, yes, clearer. the fact that it's non-obvious, though, warrants special UI consideration
[08:49] <mdz> I think it deserves a real requirements gathering session before taking a hard stance on how it should work, i.e. discussing with the people who will be using it
[08:50] <mdz> I'm happy to do that during the sprint
[08:50] <mdz> and pass on the feedback to LP
[08:50] <mdz> or we can arrange something else
[08:51] <mdz> but forcing workflow on us without discussion is what gave us this milestone privilege bug, and others like it
[08:51] <kiko> mdz, I think the requirements weren't communicated well. I actually reviewed the original patch that restricted importance -- I think time has eroded some of that history though
[08:52] <mdz> kiko: as you say, the thrust of that patch was to change access control for importance, and we got that right in the end.  though the milestone bit of it seemed to be something of an afterthought
[08:52] <kiko> okay.
[08:53] <mdz> are we agreed on the quick fix for bug 56618, or do we need to talk about it further?
[08:53] <Ubugtu> Malone bug 56618 in malone "Milestone restrictions are too restrictive for Ubuntu" [Critical,Confirmed]  https://launchpad.net/bugs/56618
[08:54] <kiko> mdz, I just need to find somebody to do it.
[08:54] <mdz> ok, thank you
[08:54] <mdz> would you like to talk about a requirements gathering process now, or some other time?
[08:55] <danil[out] > btw, beer fest is on in belgrade :)
[08:55] <mdz> I think probably sabdfl should be involved in that discussion, since he has strong feelings about this
[08:55] <kiko> what's beer?
[08:55] <mdz> beer? it's not even noon yet
[08:55] <kiko> mdz, a meta-requirements-gathering-process discussion or a discussion to gather requirements about driver-related permissions?
[08:56] <danil[out] > kiko: that's a liquid resembling piss but which gets better after you drink 2l of it (unlike piss: no, I didn't try it :)
[08:56] <mdz> kiko: the meta discussion
[08:56] <mdz> it's become clear to me during the discussion we just had that there is disagreement over the meta process
[08:56] <danil[out] > see ya around
[08:56] <kiko> danil[out] , I don't like piss very much so I think I'll pass
[08:56] <danil[out] > kiko: yeah, I'm not going there for the beer, though :)
[08:57] <kiko> mdz, well, that discussion sounds pretty brief to me: "Q: should changes in permissions and workflow should be carefully considered? A: yes." ...
[08:57] <mdz> kiko: the question I want to address is "how do we ensure that we make the best decisions about workflow for distro-related processes implemented in Launchpad?"
[08:57] <kiko> mdz, the important part is actually doing the careful consideration
[08:57] <mdz> kiko: I think it's worth formalizing how we do the careful consideration
[08:58] <mdz> since we've tripped over this many times, despite best intentions on both sides
[08:59] <mpt> How am I supposed to read them now
[09:00] <sabdfl> kiko: for the record, i expressed quite clearly in the docklands sprint my requirement that series targeting be heavyweight with permissions, and milestones be lightweight, so i'm surprised that a change to milestone targeting was made without discussion with me
[09:01] <kiko> mpt, there's this great thing, userContent.css
[09:02] <kiko> sabdfl, I think it's just a bug. 
[09:02] <kiko> sabdfl, at any rate, the permissions have been grown organically.. importance has gone through a similar shakeout.
[09:04] <sabdfl> i don't mind the importance stuff, i never expressed a requirement there, but restricting targeting to milestones is a different matter
[09:05] <sabdfl> distroreleases/series -> heavyweight, milestones -> lightweight
[09:05] <kiko> sabdfl, I'm sorry, I don't recall the rationale for the restriction, and it's going to be fixed
[09:05] <LarstiQ> I get how series is heavier than milestones. But I'm not entirely clear on how milestones themselves are supposed to work then.
[09:06] <kiko> LarstiQ, I think for upstreams milestones end up coinciding with releases that are upcoming
[09:06] <kiko> LarstiQ, and for distroreleases, the thinking is that they coincide with the milestone releases.
[09:06] <sabdfl> kiko: thanks, and will you also keep an eye out for other issues like that?
[09:06] <kiko> sabdfl, heh. that's a lot of issues! :)
[09:06] <sabdfl> sorry - i meant spotting the same issue if it comes up again
[09:07] <sabdfl> other occurrences of this one
[09:07] <LarstiQ> kiko: right, but then there is how that ties into the rest of launchpad
[09:07] <sabdfl> LarstiQ: a milestone is a "marker point in time"
[09:07] <sabdfl> it could correlate to a release, or just a date
[09:07] <LarstiQ> kiko: overall, my biggest complaint about lp would be the (perceived?) lack of documentation
[09:07] <sabdfl> and launchpad lets you tag onto that point a bunch of things that you want to track
[09:07] <kiko> sabdfl, well, there is now an explicit bug on the topic, and the test will implement what that bug says.. it's not a lot but there's at least some paper trail
[09:07] <sabdfl> then keep a bookmark where you get a chart of your progress towards that point
[09:08] <LarstiQ> sabdfl: so far that is all pretty standard. And I understand you want no restrictions on how they get used.
[09:08] <sabdfl> the original idea was to let anyone to target anything to a milestone
[09:08] <LarstiQ> sabdfl: The question that leaves for me, is how does that result in project workflow?
[09:09] <sabdfl> unfortunately, the distro team didn't have the option for proper releas emanagement on distrorelease, so they have been using milestones in that way
[09:09] <LarstiQ> that sounds familiar
[09:09] <sabdfl> LarstiQ: the project workflow itself comes more from the distrorelease/series targeting
[09:10] <sabdfl> say you are gearing up to make a 1.2 major release of your project
[09:10] <sabdfl> you create a series
[09:10] <sabdfl> and you appoint release managers for that series, who decide what bugs and features need to get fixed in it
[09:10] <sabdfl> then people can nominate bugs and features
[09:10] <sabdfl> and the release managers (drivers) approve/decline those
[09:10] <sabdfl> everyone can see the chart of features
[09:10] <sabdfl> and bugs
[09:11] <sabdfl> along the way, you might have milestones
[09:11] <sabdfl> you don't also want a heavyweight process for milestones
[09:11] <sabdfl> or nobody will use it
[09:11] <sabdfl> or they will UNDER-use it
[09:11] <LarstiQ> you can't attach something to more than one milestone, right?
[09:11] <sabdfl> or they will use it like they should be using distrorelease/series release management
[09:12] <LarstiQ> which makes sense at first thought
[09:12] <LarstiQ> but what if people disagree?
[09:12] <sabdfl> does it make sense to promise to do something by monday and friday?
[09:12] <LarstiQ> sabdfl: yes
[09:12] <sabdfl> the idea is that the person who MATTERS is the person who is doing the thing
[09:12] <sabdfl> LarstiQ: how does it make sense to do "XYZ by Monday AND Friday"?
[09:13] <LarstiQ> misread your question, sorry
[09:13] <sabdfl> ok
[09:13] <sabdfl> it only makes sense to plan to do something concrete by a particular milestone
[09:13] <sabdfl> though it does need to be easy to "slip" a bunch of things at a time
[09:14] <LarstiQ> right
[09:14] <sabdfl> say you get close to a milestone, and its clear you're not going to get to 10 things
[09:14] <LarstiQ> and if only the people who do the work set milestones, I guess that will work
[09:14] <sabdfl> should be easy to bump them to the next milestone
[09:14] <sabdfl> yes, that's what i was musing about earlier
[09:15] <sabdfl> (19:45:01) sabdfl: though perhaps it woulod be better to allow assignee's, and drivers
[09:15] <sabdfl> in other words, the assignee, or the driver, can set a milestone
[09:15] <sabdfl> it's like "i want to do this by that date" or "i'm in charge and i want to do this by that date"
[09:15] <sabdfl> but
[09:16] <LarstiQ> that makes sense, but perhaps it is not needed when people can really use series
[09:16] <sabdfl> having it freeform might be cool too - you see "the set of things people thought should be done by this date"
[09:16] <sabdfl> i agree, so i think it should stay freeform until we have more experience with it
[09:16] <LarstiQ> sabdfl: right, and I was thinking more freeform tagging style with multiple milestones
[09:16] <sabdfl> and of course, while we have proper release management
[09:16] <sabdfl> LarstiQ: well, there we will differ :-)
[09:16] <sabdfl> though i'm keen to see how people use tags on bugs
[09:17] <sabdfl> if it works nicely, i might even stick them in specs too
[09:17] <LarstiQ> sabdfl: I haven't thought it out, so I'll go with single milestones for now :)
[09:17] <LarstiQ> at least it is clear to me how _you_ think they should work
[09:32] <kiko> BjornT, ping?
[09:32] <BjornT> kiko: pong
[09:32] <kiko> BjornT, want to do that call?
[09:34] <BjornT> kiko: sure
[09:39] <kiko> where's my phone...
[09:43] <LarstiQ> a python trojan, how nice
[09:47] <kiko> BjornT, -> privmsg?
[09:58] <mdz> BjornT: are tags not included in the activity log?
[09:59] <kiko> mdz, no.
[09:59] <mdz> kiko: bug?
[10:01] <kiko> mdz, yes, though the galore of bugs in the activity log is because it really should be done in a better way.
[10:01] <mdz> kiko: should I file a bug report or no?
[10:04] <kiko> mdz, you should, yes.
[10:06] <mdz> kiko: I think that listing all known tags in a portlet is not useful when there are more than a few
[10:07] <kiko> mdz, agreed -- did you see my email on this topic yesterday?
[10:07] <mdz> no, launchpad@ ?
[10:07] <kiko> I think launchpad-users CC: launchpad
[10:17] <sivang> re
[11:09] <markrian> I just tried to join the bugsquad on launchpad, but got an email telling me my request to join was declined, and that first I need to join bugsquad...
[11:09] <markrian> I've been told that's a launchpad bug. Can anyone help me join bugsquad?
[11:09] <kiko> markrian, sure. 
[11:10] <kiko> sfllaw, ping?
[11:11] <kiko> markrian, did you join by using https://launchpad.net/people/bugsquad/+join -- ?
[11:11] <markrian> kiko, yes, I did
[11:12] <kiko> markrian, what's your launchpad name?
[11:12] <sfllaw> kiko: Pong.
[11:12] <markrian> kikp, markrian
[11:13] <kiko> sfllaw, what's the procedure for joining the bugsquad?
[11:13] <sfllaw> markrian: ubuntu-qa is not the BugSquad.
[11:13] <sfllaw> kiko: You join the bugsquad team.
[11:13] <sfllaw> Acceptance is basically automatic.
[11:13] <markrian> Hmm...
[11:13] <kiko> sfllaw, oh. did he try ubuntu-qa/+join?
[11:13] <sfllaw> Yup.
[11:16] <sabdfl>   >>> browser.open('http://blueprint.launchpad.dev/products/firefox/+addspec')
[11:16] <sabdfl>   >>> browser.url
[11:16] <sabdfl>   'http://blueprint.launchpad.dev/products/firefox/+addspec'
[11:16] <sabdfl> kiko: does that actually test that the page could be opened?
[11:17] <sabdfl> if it 500'd, or 404'd, would the browser.url be different?
[11:19] <kiko> sabdfl, if it failed, an exception would be raised, I believe
[11:28] <markrian> So, what's the news? Can I not join the bugsquad at the moment?
[11:29] <kiko> markrian, you should use that URL I provided you above instead of the one you tried to use originally.
 markrian, did you join by using https://launchpad.net/people/bugsquad/+join -- ?
[11:30] <kiko> markrian, sorry I thought that was clear from sfllaw's hint above.
[11:30] <kiko> you tried to join the wrong team.
[11:30] <kiko> which is why you were denied
[11:30] <markrian> Oh I see, I didn't catch that. Thanks :)
[11:31] <kiko> :)
[11:48] <kiko> Seveas, ping?