All times are UTC.
00:00:02 <flo-retina> especially as there are 21 of them!!! 00:01:12 <-- dew has quit (Ping timeout) 00:01:32 <flo-retina> for "Slicing error: bug[target_milestone] is 0.2a1, not 0.2" I suspect what happened is we started with a tm of "0.2", then decided to do an alpha, and renamed the existing 0.2 into 0.2a1 and then created a new 0.2 00:01:37 <flo-retina> which makes a very confusing history :-/ 00:02:26 --> dew has joined #instantbird 00:02:31 <flo-retina> I have 8 of these errors, for 10 bugs with the 0.2a1 tm 00:02:47 <flo-retina> that's possible, it would mean 2 bugs have had there milestone set to 0.2a1 after it was renamed 00:03:34 <flo-retina> see bug 2. The tm is 0.2a1, but the history says we set it to "0.2" 00:03:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2 nor, --, 0.2a1, florian, RESO FIXED, Load accounts even when the prpl can't be loaded 00:04:27 <flo-retina> anybody's got time to look at these 10 bugs and tell me which are the 8 of them that have had their TM set to 0.2? https://bugzilla.instantbird.org/buglist.cgi?quicksearch=FIXED%20milestone%3A0.2a1&list_id=6279 00:04:43 <flo-retina> (give me the list as a JS array ;)) 00:05:48 <aleth> less than 8 of them have 0.2 as TM 00:06:07 <flo-retina> that's strange 00:06:13 <aleth> or do you mean in the history? 00:06:16 * aleth is confused 00:06:22 <flo-retina> they all have 0.2a1 displayed in the bug 00:06:31 <flo-retina> but I expect 8 out of the 10 have it set to 0.2 in the history 00:06:53 <flo-retina> and it "magically" goes from 0.2 to 0.2a1 without this change being visible in the history 00:07:11 <aleth> https://bugzilla.instantbird.org/show_activity.cgi?id=113 has no TM info in the history at all 00:07:51 <flo-retina> then the TM was set when filing the bug 00:07:57 <flo-retina> and it's not one I care about :) 00:08:26 <aleth> bug 141 has the pattern you expected 00:08:28 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=141 min, --, 0.2a1, nobody, RESO FIXED, IRC /quit command should not display an error in account manager 00:09:27 <aleth> 192 does not 00:09:45 <aleth> so that's two ;) 00:10:56 <aleth> The other 8 will be the ones for your array... 00:10:59 <Mic-Linux> These have the tm set to 0.2: [2,57,79,158,141,171,170] 00:11:06 <flo-retina> the one where there's some funny business with the URL field is https://bugzilla.instantbird.org/show_activity.cgi?id=590 00:11:07 <Mic-Linux> These don't: [112,113,192] 00:11:46 <flo-retina> hmm, so that means there's one where it was set to 0.2, then renamed to 0.2a1, then set to something else :-/ 00:12:45 <qheaden> Hello. 00:12:51 <Mic-Linux> Hi qheaden 00:12:51 <flo-retina> I wonder why that URL -> see also change causes any problem 00:12:54 <flo-retina> qheaden: hello :) 00:12:57 <qheaden> flo-retina: Are you importing some bugs into BMO? 00:13:16 <flo-retina> qheaden: that's a strange question, given that you sent us a password for that purpose ;) 00:13:16 <aleth> IMPORT ALL THE BUGS 00:13:17 <aleth> scnr 00:13:22 <qheaden> :) 00:13:35 <qheaden> flo-retina: I mean right at this moment? 00:13:40 <flo-retina> qheaden: no 00:13:43 <qheaden> Oh okay. 00:13:47 <flo-retina> qheaden: you can still make changes on BIO 00:13:52 <qheaden> Gotcha. 00:13:58 <qheaden> Are any of the Ib bugs visible on BMO yet? 00:14:02 <flo-retina> no 00:14:04 <aleth> qheaden: There are some test run results on landfill 00:14:06 <flo-retina> and please don't file any there 00:14:33 * qheaden believes that landfill should stay as a landfill. :P 00:14:41 <flo-retina> I'm hoping to launch another full test run on https://bugzilla-dev.allizom.org/ before going to bed 00:15:12 <flo-retina> qheaden: we've probably filed already at least 3,000 bogus bugs there, so yeah, there's quite a bit of junk in there ;) 00:15:19 <qheaden> :P 00:16:28 <-- dew has quit (Ping timeout) 00:17:16 --> dew has joined #instantbird 00:18:15 <flo-retina> rerunning with that list of bogus 0.2 bugs :) 00:18:59 <flo-retina> I still get 5 of these errors :-S 00:19:02 <flo-retina> (I had 8 before) 00:19:58 --> BWMerlin has joined #instantbird 00:20:44 <flo-retina> oops, the query shouldn't have said "Resolution: FIXED" :( 00:20:55 <flo-retina> the other one I found by looking at the logs is https://bugzilla.instantbird.org/show_bug.cgi?id=80 00:20:57 <instantbot> Bug 80 nor, --, 0.2a1, florian, RESO DUPLICATE, Exception when closing a conversation if the account was deleted 00:21:21 <flo-retina> bug 107 00:21:22 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=107 maj, --, 0.2a1, nobody, RESO DUPLICATE, IRC Commands do not work 00:21:49 <flo-retina> https://bugzilla.instantbird.org/show_activity.cgi?id=151 is a mess :( 00:22:03 <aleth> indeed 00:22:38 <flo-retina> 162 is another one 00:23:04 <flo-retina> https://bugzilla.instantbird.org/show_activity.cgi?id=169 is also a mess :( 00:26:16 <flo-retina> so I guess for these 2 I need to check the timestamp of the event to decide of the mapping 00:33:27 <-- Mic-Linux has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 00:34:22 <flo-retina> cool, no more target milestone problem :) 00:35:37 <-- dew has quit (Ping timeout) 00:36:23 <flo-retina> here is how the hack looks: http://hg.instantbird.org/bio-merge/rev/f61d51d52332#l1.37 00:36:26 --> dew has joined #instantbird 00:39:04 <flo-retina> so apparently the problems with the url field happen when someone emptied the URL field 00:39:26 <flo-retina> it seems that "field hasn't been set" and "field has been set to an empty value" isn't fully equivalent 00:39:34 <flo-retina> shouldn't be too hard to workaround I guess 00:40:14 <aleth> hacks are ok in code that only has to work once ;) 00:40:20 <flo-retina> sure :) 00:40:48 <flo-retina> then I'll need to look into the 21 remaining errors = 21 missing attachments 00:41:12 <flo-retina> and after that... well, what's left on the todo pad :-/ 00:41:30 <aleth> the utf8 thing is really annoying 00:41:36 <flo-retina> handling blocks/depends on is the big piece 00:41:42 <flo-retina> aleth: I'll just work around it 00:41:45 <aleth> let's hope it gets fixed soon 00:41:55 <flo-retina> I'm going to assume it won't 00:42:16 <flo-retina> if Gerv does something for us this week-end, I would prefer if it is adding the 5 milestones that we forgot to request 00:45:05 --> mconley has joined #instantbird 00:45:24 <-- dew has quit (Ping timeout) 00:45:24 <flo-retina> I guess I could do with some help on the "- Create the full map of email addresses" step 00:45:44 <flo-retina> for the people who sent us a password, we will use it 00:45:53 <flo-retina> for others, their changes will be replayed by instantbot 00:45:53 --> dew has joined #instantbird 00:46:18 <flo-retina> but even if we do their changes with instantbot, if we know their BMO email, we can add them to the cc list if they were in the BIO cc list 00:46:28 <flo-retina> or set them as assignee 00:47:15 <-- aleth has quit (Quit: exit stage left) 01:01:26 <-- mconley has quit (Input/output error) 01:07:36 <-- dew has quit (Ping timeout) 01:08:20 --> dew has joined #instantbird 01:13:01 <-- dew has quit (Connection reset by peer) 01:14:47 --> dew has joined #instantbird 01:26:09 <-- dew has quit (Ping timeout) 01:27:08 --> dew has joined #instantbird 01:29:43 <-- dew has quit (Ping timeout) 01:30:20 --> dew has joined #instantbird 01:36:28 <-- dew has quit (Ping timeout) 01:36:47 --> dew has joined #instantbird 01:40:06 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 01:48:13 <flo-retina> interestingly, the 21 errors weren't directly related to the 21 missing attachments 01:48:34 <flo-retina> some of the errors were just noise; when the code was doing the right thing already 01:48:50 <flo-retina> it was just something to be expected rather than an error 02:43:41 <flo-retina> actually, I had 21 errors when trying to flag missing attachments, but only 11 missing attachments (some were flagged multiple times) 03:30:13 <flo-retina> we've got 48 events that have encoding problems 03:30:39 <-- wnayes has quit (Quit: wnayes) 04:03:48 <instant-buildbot> build #1064 of linux-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/1064 05:04:32 <flo-retina> so the encoding issue was hiding something else: BzAPI does 'flag' requests using the GET method, not POST. So when the comment is over a certain length, the request fails with "URI too long", even if the encoding is correct. 05:11:01 <flo-retina> all known errors from the previous full test run are fixed! \o/ 05:11:13 <flo-retina> now I need to look at the blocks/depends_on fields 05:23:18 --> nhnt11 has joined #instantbird 05:33:14 --> mconley has joined #instantbird 05:37:50 <instant-buildbot> build #1512 of macosx-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/1512 05:44:02 <-- mconley has quit (Connection reset by peer) 05:44:19 --> mconley has joined #instantbird 05:44:28 <-- nhnt11 has quit (Ping timeout) 06:18:11 <-- mconley has quit (Input/output error) 06:20:36 --> nhnt11 has joined #instantbird 07:26:07 <flo-retina> bug dependencies work: https://landfill.bugzilla.org/bzapi_sandbox/show_activity.cgi?id=14506 ! :) 07:39:54 <instant-buildbot> build #1214 of win32-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1214 08:19:32 --> mconley has joined #instantbird 08:25:43 <-- mconley has quit (Ping timeout) 08:57:27 <-- gerard-majax_ has quit (Quit: Ex-Chat) 08:57:33 --> gerard-majax__ has joined #instantbird 09:15:41 <flo-retina> I started a test import at https://bugzilla-dev.allizom.org/show_bug.cgi?id=916780 09:16:02 <flo-retina> Unless I notice it's completely broken in the next few minutes, I'll go to bed, and assume it will run for 13+ hours. 09:32:29 --> hadi has joined #instantbird 09:35:41 <-- gerard-majax__ has quit (Connection reset by peer) 09:35:47 --> gerard-majax_ has joined #instantbird 09:45:36 --> Even has joined #instantbird 09:45:36 * ChanServ sets mode +o Even 09:51:42 --> igorko has joined #instantbird 09:54:13 --> jb has joined #instantbird 10:08:28 <-- jb has quit (Ping timeout) 10:17:02 <-- igorko has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com) 10:20:09 <-- EionRobb has quit (Quit: Leaving.) 11:28:00 --> aleth has joined #instantbird 11:28:00 * ChanServ sets mode +h aleth 12:05:20 <-- aleth has quit (Ping timeout) 12:40:00 --> aleth has joined #instantbird 12:40:00 * ChanServ sets mode +h aleth 13:02:40 <-- aleth has quit (Ping timeout) 13:20:20 <-- nhnt11 has quit (Ping timeout) 13:21:39 --> nhnt11 has joined #instantbird 13:46:23 <flo-linux> most of the errros so far are ""There is no component named 'www.instantbird.org' in the 'Instantbird Servers' product."", which just means I forgot one line in the component mapping 14:14:27 <-- hadi has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 14:14:44 --> hadi has joined #instantbird 14:45:40 --> unghost has joined #instantbird 15:25:05 --> aleth has joined #instantbird 15:25:05 * ChanServ sets mode +h aleth 15:36:03 <-- aleth has quit (Ping timeout) 15:43:51 --> aleth has joined #instantbird 15:43:51 * ChanServ sets mode +h aleth 16:23:28 <-- aleth has quit (Ping timeout) 16:29:15 --> aleth has joined #instantbird 16:29:16 * ChanServ sets mode +h aleth 16:29:25 --> Mic has joined #instantbird 16:29:32 * Mic is now known as Mic2 16:40:27 <-- Mic2 has quit (Ping timeout) 16:40:31 --> Mic2 has joined #instantbird 16:54:39 --> wnayes has joined #instantbird 16:55:53 <flo-retina> unless we discover something awfully broken, the real import is likely going to happen next night 16:56:55 <-- aleth has quit (Ping timeout) 17:02:45 <Mic2> It will take ages to memorize all bug numbers again... 17:04:33 <Mic2> (that was only fun - just to make sure nobody takes that serious;) 17:16:11 <flo-retina> Mic2: I was shocked to see that I knew the bug number of JS-IRC yesterday 17:16:24 <flo-retina> I was looking for it to test my work on bug dependencies 17:16:40 <flo-retina> I started querying BIO and gmail (my bugmail), but couldn't find it quickly 17:16:51 <flo-retina> then I typed 'randomly' 507 and that was it! 17:41:48 --> jb has joined #instantbird 17:46:59 <-- Mic2 has quit (Quit: Mic2) 17:47:08 <-- jb has quit (Ping timeout) 17:56:42 <-- BWMerlin has quit (Quit: BWMerlin) 19:02:23 <-- Suiseiseki has quit (Ping timeout) 19:03:56 <-- nhnt11 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 19:21:14 --> Suiseiseki has joined #instantbird 19:33:50 --> mconley has joined #instantbird 19:42:05 <-- unghost has quit (Quit: Ð£Ñ Ð¾Ð¶Ñ Ñ Ð¾Ñ Ð²Ð°Ñ (xchat 2.4.5 или ÑÑаÑÑе)) 19:44:13 --> Mic has joined #instantbird 19:44:32 * Mic is now known as Mic2 21:09:28 --> jb has joined #instantbird 21:18:20 --> EionRobb has joined #instantbird 21:21:25 <-- dew has quit (Ping timeout) 21:22:23 --> dew has joined #instantbird 21:37:57 <-- dew has quit (Ping timeout) 21:43:51 <-- jb has quit (Ping timeout) 21:51:32 <flo-retina> Initially I wanted to the import script to stop immediately if a request fails 21:51:57 <flo-retina> but I'm more and more leaning toward letting it continue, and just replay by hand the few events that will have failed randomly 21:52:37 --> dew has joined #instantbird 21:52:44 <Mic2> Does that work or will that mess up things with the order of events? 21:52:49 <Mic2> *might that 21:53:00 <flo-retina> both? :) 21:53:10 <flo-retina> I guess it depends what fails 22:06:48 <-- hadi has quit (Ping timeout) 22:07:08 --> hadi has joined #instantbird 22:08:39 <qheaden> Hello 22:09:18 <qheaden> flo-retina: I just changed the password for BMO, so things should work. 22:10:24 <flo-retina> qheaden: awesome, thanks! :) 22:10:58 <qheaden> Np. Sorry for that delay. 22:11:15 <qheaden> So when will the import start? 22:11:30 <flo-retina> 2-3 hours from now seems likely. 22:11:44 <qheaden> Ok 22:11:50 <flo-retina> the test import on bugzilla-dev seems almost finished (13 bugs left to import) 22:12:04 <flo-retina> I would like us (if some people are still around) to spend some time looking at it to see if there are obvious defects 22:12:13 <flo-retina> I will also inspect the log of the import script 22:12:24 <flo-retina> and then close BIO, and redownload its content, including the latest changes. 22:12:29 <qheaden> Of the official import? 22:12:48 <flo-retina> I don't understand the question 22:13:45 <qheaden> You want us to observe the bugzilla-dev import or the official? 22:14:34 <flo-retina> the bugzilla-dev 22:14:48 <flo-retina> you will have as much time as you want to inspect the final one, but it will be too late to make changes 22:14:49 <qheaden> Oh ok. 22:15:03 * qheaden is outside right now. 22:15:24 <flo-retina> I'm not sure who is around 22:15:33 <flo-retina> finished! 22:15:37 <flo-retina> 781 minutes 22:15:48 <flo-retina> 13hours 22:15:51 <flo-retina> that's consistent 22:16:09 <flo-linux> "// done. Replayed 20903 events. 141 errors." 22:16:10 <qheaden> What is the link to bugzilla-dev? 22:16:59 <flo-retina> qheaden: from https://bugzilla-dev.allizom.org/show_bug.cgi?id=916780 to https://bugzilla-dev.allizom.org/show_bug.cgi?id=919034 22:17:19 <qheaden> Ok 22:17:22 <flo-retina> I guess you can look at the JS-Yahoo bug 22:17:40 <flo-retina> that's hairy one, and you know it more than anybody else, so you are more likely to notice if something is wrong on it 22:19:51 <qheaden> Are you able to send a link? I'm on my phone and navigation is a bit annoying. 22:20:10 <flo-retina> what's the bio number? 22:20:53 <qheaden> 1982 22:22:05 <flo-retina> qheaden: https://bugzilla-dev.allizom.org/show_bug.cgi?id=918731 22:22:12 <qheaden> Thanks 22:22:37 <flo-retina> you may want to login to see more things 22:22:41 * qheaden is about to drive home 22:22:47 <flo-retina> (your password is your temporary BMO one) 22:22:59 <flo-retina> qheaden: you don't have to look at it _immediately_ 22:23:05 <qheaden> I will be on in a few minutes. 22:23:06 * flo-retina doesn't know how far from home qheaden is 22:45:38 <flo-linux> my macbook is horribly slow, the process SystemUIServer (I guess the mac equivalent of the X server) is sucking 20% of CPU, I guess it isn't responsive 22:47:15 <flo-retina> hmm, looks like closing iTunes 'fixed' it :-S 22:53:22 <flo-retina> the error about the 0.1.5 target milestone seems reasonable: https://bugzilla.instantbird.org/show_activity.cgi?id=149 22:54:17 <flo-retina> I'm very tempted to just remove that history entry from the bug's downloaded file 22:55:53 <flo-retina> hmm, I guess I can just skip it in the script 22:57:46 <flo-retina> hmm, or just map it to 0.2a1 22:57:53 <flo-retina> that's probably what 0.1.5 has been renamed into 23:01:27 <-- Tonnes has quit (Ping timeout) 23:01:58 <flo-retina> Mic2 (and others who may be reading) : how do you feel about https://bugzilla-dev.allizom.org/show_bug.cgi?id=917270#c5 ? 23:02:25 --> Tonnes has joined #instantbird 23:02:30 <flo-retina> I'm wondering if we should add another line of auto-generated text explaining that this comment didn't exist in BIO, and that the next comment numbers will be off 23:04:11 <flo-retina> "*** No comment included in the original change, next comment numbers will have an offset ***"? 23:05:38 <-- qlum has quit (Ping timeout) 23:06:27 <-- Tonnes has quit (Ping timeout) 23:07:49 --> qlum has joined #instantbird 23:08:18 --> Tonnes has joined #instantbird 23:08:47 --> aleth has joined #instantbird 23:08:47 * ChanServ sets mode +h aleth 23:09:24 <Mic2> I think pointing out that there's a change in the comment numbers would be nice. 23:09:45 <Mic2> This way people would at least know that this kind of thing could happen... 23:10:16 <flo-retina> I think it would be confusing to point it out in some cases (we already do) and not others 23:10:23 <flo-retina> any idea of what the right wording could be? 23:10:30 <flo-retina> the shorter the better ;) 23:10:36 <flo-retina> aleth may also have ideas :) 23:11:39 <-- Tonnes has quit (Connection reset by peer) 23:11:39 <-- qlum has quit (Ping timeout) 23:13:22 --> qlum has joined #instantbird 23:14:40 <aleth> I was a little confused by "original change" as it's a new attachment, not a "change" (the change is of the bug) 23:15:27 --> Tonnes has joined #instantbird 23:18:03 <flo-retina> aleth: is it? 23:18:14 <flo-retina> which comment are you looking at exactly? 23:18:16 <aleth> How about "Attmnt 526 originally attached to bio 507 at (date) without a comment (subsequent comment numbers may be shifted)" 23:18:38 <hadi> hm 23:18:43 <flo-retina> aleth: I think there's some confusion here. Attaching without a comment isn't possible at all. 23:18:57 <aleth> I'm certainly confused. 23:19:01 <flo-retina> aleth: the *change* I was talking about is marking an attachment obsolete, or setting a flag 23:19:24 <aleth> Maybe that should be more explicit. 23:19:37 <flo-retina> can you link me to what you are looking at? 23:20:02 <aleth> https://bugzilla-dev.allizom.org/show_bug.cgi?id=917270#c5 23:20:51 <flo-retina> aleth: you will better understand what's going on if you login 23:21:15 <flo-retina> if you login you'll see the line saying "Attachment #805568 - Attachment is obsolete: true" grouped with that comment 23:21:41 <flo-retina> (password for your account there is the temporary BMO password you emailed me) 23:21:53 <aleth> OK, if that's there I guess it makes sense the way it is 23:22:23 <flo-retina> what I was discussing with Mic is adding another line of auto-generated text, explaining that comment numbers will be off 23:22:28 <flo-retina> and I wasn't sure how I could best phrase that 23:22:50 <aleth> The bit in brackets I posted earlier is quite short 23:23:17 <flo-retina> which one is this? 23:24:03 <aleth> "... without a comment (subsequent comment numbers may be shifted)" 23:24:57 <aleth> or better "any subsequent comment numbers will be shifted" 23:26:22 <flo-retina> so you would remove the "***" at the end of the first line, and just continue the same sentence? 23:27:03 <aleth> yes, I'd add "without a comment" to the same sentence 23:27:50 * flo-retina has filed more bugs in a week than in his entire life 23:28:02 <aleth> :D 23:28:09 <-- EionRobb has quit (Quit: Leaving.) 23:28:31 <flo-retina> I just tweaked the script a bit to add this comment when resolving the bug: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919040#c2 23:28:48 <aleth> You can now measure your productivity in bugs per hour ;) 23:28:48 <flo-retina> we decided to not include it for when only some fields have been updated (eg the whiteboard) 23:28:59 <flo-retina> aleth: ahah :) 23:29:13 <flo-retina> aleth: well, it takes me 13 hours to file 2,2k bugs 23:29:28 <flo-retina> _and_ fix a significant number of them! :) 23:29:56 <aleth> That's why they're Instantbugs. 23:30:51 <aleth> That resolving comment looks good to me. 23:31:39 <flo-retina> aleth: here is how it looks: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919041#c2 23:32:25 <aleth> Hmm, maybe it should be s/any/so 23:32:45 <flo-retina> I was wondering if we should s/without a comment/without comment/ 23:33:25 <aleth> It's shorter, so that seems good 23:34:18 <flo-retina> I dislike the "post" word which seems wrong for a change without comment 23:34:59 <aleth> You could use "change" or "modification" there too? 23:35:26 <flo-retina> I was thinking of making it "change", yes 23:35:41 <flo-retina> the logic is getting a bit complicated in the code, but I don't really mind, as long as I don't completely mess it up :) 23:38:57 <flo-retina> aleth: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919042#c2 23:39:02 <flo-retina> is this ready? 23:40:08 <aleth> s/without comment.../was without comment, so any subsequent comment numbers will be shifted 23:40:30 <aleth> would be better I think. (Third pair of eyes would be useful at this point ;) ) 23:40:35 <aleth> qheaden ? 23:43:17 <-- aleth has quit (Ping timeout) 23:43:22 <flo-retina> how do I close BIO? 23:49:32 <-- Suiseiseki has quit (Client exited) 23:49:42 --> Suiseiseki has joined #instantbird 23:53:40 * qheaden gets home and finishes his dinner. 23:58:17 <flo-retina> final download started, any change made on BIO from now on won't be migrated.