15:00:24 <x1sc0> #startmeeting 15:00:24 <IZBot> Meeting started Tue May 29 15:00:24 2018 UTC. The chair is x1sc0. Plugin info at http://wiki.debian.org/MeetBot. 15:00:24 <IZBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:35 <x1sc0> hi everyone 15:00:43 <x1sc0> anyone available for the QA meeting? 15:02:02 <x1sc0> I guess this is going to be a quick meeting, at least I don't have any topic in mind. Still catching up after the vacation 15:02:36 <djredaux> yes 15:03:14 <x1sc0> hi djredaux, welcome 15:03:43 <x1sc0> maybe we can discuss about the firebird progress, you've been quite involved 15:04:24 <djredaux> I suppose - just kicking the tires 15:04:27 <x1sc0> before you mentioned a couple of issues tbefore 15:04:51 <x1sc0> #topic Firebird migration 15:05:42 <djredaux> Yes, there are few and there are some questions about where the boundaries will be for what the assistant will offer 15:06:23 <djredaux> I think the key now is to think of it as an assistant and not a 100% conversion for everyone. 15:07:59 <x1sc0> 6.1 will be release in mid August, still 2 months and a half to go. Tamas has done a really good work in the last month. I think we still have time for improvement 15:08:16 <x1sc0> but sure, it won't be 100% for 6.1 15:09:17 <x1sc0> or even later, it can take long 15:09:18 <djredaux> Well, for instance some of the example db files from one of the Base books will never migrate via the assistant, or so I suspect. 15:09:49 <x1sc0> right now, which are, in your opinion, the most critical bugs? 15:09:53 <djredaux> Yes and mid august isn't really that far away in this circumstance, more like right around the corner 15:16:23 <x1sc0> you mean tdf#117732 ? 15:16:25 <IZBot> LibreOffice-Base major/high NEW Firebird: Migration: Time values are being changed during migration process (data type TIME and DATETIME) https://bugs.documentfoundation.org/show_bug.cgi?id=117732 15:16:27 <buovjaga> I am listening, just got home 15:16:48 <djredaux> x1sc0: yes that one 15:20:13 <djredaux> tdf#117446 is an issue that, while I doubt it will hit a lot of people, it is worth rethinkng how that is being mapped to firebird types 15:20:15 <IZBot> LibreOffice-Base major/high NEW Firebird: Migration: LibO hangs with data type Binary[VARBINARY] OR Binary(fix)[BINARY] AND data in hsql column exceeds new column size ( 8000 bytes ) https://bugs.documentfoundation.org/show_bug.cgi?id=117446 15:23:03 <x1sc0> I think we should give more priority to the general cases and then to those that will hit less people 15:23:36 <djredaux> if the assistant runs across those it may have to support creating a blob field verses the current solution, depending on the largest value stored in the column, not just the hsql data type the size for those types in HSQL can not be set by the users so asking hsql for size metadata I don't think is useful there. 15:24:10 <djredaux> x1sc0: #agreed, which gets back to it is an assistant (an aid) but not a total solution for all cases 15:26:08 <x1sc0> so right now, if the assistance fails with one of those types, it fails to convert the whole database, or it converts half of it? 15:27:33 <djredaux> x1sc0: currently the assistant only stops processing because of one error, the 30 character identifer limit, all the other soft errors it continues working. You get a partial migration. 15:28:30 <x1sc0> so the user has to finish it manually ? 15:30:02 <djredaux> x1sc0: yes but there is kind of a workflow issue with that - since the assistant does not make a backup of the original file before it starts and it doesn't warn the user to do so before they started it, if the users did not back up and saves the partial migraiton file they have no easy way to see what it is that didn't move. 15:30:57 <x1sc0> ouch, that can be really problematic 15:30:58 <djredaux> There are currently silent losses during migration, a new issue entered today is about one of those 15:32:55 <x1sc0> then, this should be the top priority now, more than supporting types or time/datetime 15:33:40 <x1sc0> otherwise we could break thousands of ddbbs in 6.1 15:33:56 <djredaux> x1sc0: well, I guess, but that was a point of discussion a few weeks back 15:34:35 <x1sc0> and which was the conclusion ? 15:34:54 <djredaux> The offered solution is that the user could by hand change the settings in the file, and since the old hsql files are not removed, it could be reverted back to using the hsql.sdbc 15:35:44 <djredaux> Which is true, but a little dicy every time you ask a user to make a hand change to configuration data in the file after you have opened it as an archive 15:37:15 <djredaux> however at that point the migration assistant, as coded today, will fail when a new run is made because it expects that there is no firebird file in the conents and collides with the one left over from the earlier attempt 15:38:11 <x1sc0> ouch, I think user won't be happy about fixing it manually, we might get a lot of complains 15:39:00 <x1sc0> did this discussion take place in a bug ? 15:39:02 <djredaux> x1sc0: right, it seems that easiest way is just to create a backup of the whole odb file before beginning. 15:39:21 <djredaux> x1sc0: I think it was the mailing list 15:41:45 * x1sc0 is trying to find it 15:43:32 <djredaux> I'm looking also and not finding it - I know Tamas was involved, maybe it was in the comments of an issue 15:46:11 <x1sc0> if you can find it, we can send an email to the dev list to give it more visibility and hear others' opinion 15:47:48 <djredaux> back to your qustion about priorites of open issues -the issue with the file not being totally released IMO should be in that. That gets confusing very easily because until you exit and restart libreoffice those files act like zombies when you try to open them - looks like a firebird sdbc file (according to the UI) but with no tables 15:48:56 <x1sc0> you mean when it fails ? 15:49:28 <djredaux> x1sc0: If any error is generated during the migration attempt it triggers 15:51:16 <djredaux> actually I may need to reword that - there can be some tables - the file will come up as needing to be saved also, which you don't want to do in the case of those with no tables - like I said it causes confusion 15:51:17 <x1sc0> ok, you mean tdf#117352 15:51:19 <IZBot> LibreOffice-Base major/high NEW Firebird: Migration: LibO does not fully release file when ODB file closed without saving after failed migration attempt until LibO session is closed. https://bugs.documentfoundation.org/show_bug.cgi?id=117352 15:51:39 <djredaux> IZBot: yes 15:51:44 <djredaux> x1sc0: yes 15:57:14 <x1sc0> djredaux, so using the file in tdf#117352, it fails to migrate 15:57:16 <IZBot> LibreOffice-Base major/high NEW Firebird: Migration: LibO does not fully release file when ODB file closed without saving after failed migration attempt until LibO session is closed. https://bugs.documentfoundation.org/show_bug.cgi?id=117352 15:57:48 <x1sc0> if I close it, and reopen it ( without closing LibreOffice ) it asks me again to migrate 15:58:28 <djredaux> x1sc0: it did - but it might now, I didn't try that one over this weekend - did it generate an error message to screen during the migration 15:58:45 <x1sc0> djredaux, yes 15:58:58 <x1sc0> the 30 characters error 16:01:03 <x1sc0> oh, this is weird I've tried to reopen the file 5 time ( without closing Libo ) and 1 out of 5 didn't ask me to migrate 16:01:14 <djredaux> x1sc0: maybe it is working now - but that 30 character error does act differently from others - I have a couple good test cases on my disc and I'll run them all today 16:02:13 <x1sc0> so just to have it clear, if a user faces the 30 characters error, it won't mess up their database but it will if they face another error ? 16:02:40 <djredaux> x1sc0: how about I answer that after I run the batch of these files and let you know 16:02:54 <x1sc0> djredaux, sure 16:03:28 <x1sc0> I'm really concern about databases being messed after the migration 16:04:11 <x1sc0> if you find this problem now, please let me know 16:05:20 <djredaux> x1sc0: will do - as an aside to that, I've been making use of the tdf next cloud storing test files in my own area I say yesterday (I think it was) that there is a common area for QA I could move my collection of test files there so that everyone has easier access to them 16:06:31 <x1sc0> yep, it would be fantastic 16:07:17 <x1sc0> although for bugs, it's better to attach the files 16:08:45 <x1sc0> closing the meeting now... 16:08:46 <x1sc0> #endmeeting