[Libreoffice] minutes of tech. steering call ...
* Present: + Rainer, Michael Stahl, Christian, Norbert, Cor Nouws, Bjoern, Lionel, Stephan, Eike, Kendy, Caolan, Cedric, Petr, Lubos * Completed Action Items + create 'lightproof' git repo on freedesktop for Laszlo (Michael) + review pending labels patch if possible (Bjoern) + cherry-pick lightproof to Beta2 (post Beta1) (Andras) + disable gtk3 except in experimental mode (Michael) + add this layout feature into a product build (Cedric) + make it dependent on a getenv() to avoid callcatcher + need to download install libpostgresql for Mac/Windows (Fridrich) + enable Java 7 in 3.4.5, suck and see in RC1 (Stephan) + add fixing bugassistant to top #10 easy tasks page (Petr) * Pending Action Items + [slow progress] extract 64bit build hardware from firewall (Kendy / Admins) + [in progress] come up with a list of QA heros (Rainer) + add tinderbox name to build-id (Norbert) + cleanup old test build server directories (Thorsten) + setup linux build system to build gtk3 support by default for this (Michael) + rename VCL API to make it GetBeamerFoo fix (Michael) + get Rainer setup with git commit access (Michael) + forward access details to Thorsten (Rainer) * Action Items * Sexy new type-safe small printf / format logic (Lubos) AA: + make it clear the SAL_INFO etc. macros are internal only for 3.5 (Stephan) + delay changes strings until LibO 4 ? (Stephan) + not necessarily the printf format; faster without it (Lubos) + just fixing the '+' operator can help too (Lubos) + consensus for inclusion of printf style in master if Lubos wants to do it * Release Engineering update (Petr) + 3.5.0 B1 is out + first feedback from pre-release: good. + much better than Beta 0 / a promising start + thanks to all that helped + 3.5.0 B2 + tag / deadline on Monday + 3.4.5 - tag delayed by two days + builds already on pre-release ftp site, synching to mirrors for announce soon, delay not that large in the end. + branch libreoffice-3-4-5 for this release + most-annoying bugs important for release * QA - bug hunting sessions (Cor) + not easy to get lots of people involved + bug hunting planned for Wed 28 / Thur 29th of December + another one planned for RC1 Jan Fri 20th / Sat 21th of Jan + promotion on TDF blog / twitter etc. + litmus and random testing * QA update (Rainer) + spreadsheet advanced filters problems, cf. mail on list + regressions discussions + component_getFactory issue is dominant (Caolan) + presenter console, language crash on popups, etc. + re-asses with fixes in master + planning to publish document + please track that query ... + http://tinyurl.com/7z9ozoc + bug hunting sessions on IRC - joining in with Cor + bugzilla submission assistant - lots of work currently + pending integration of link in the help menu for 3.5 AA: + get a permanant re-direction link for bug assistent (Thorsten) AA: + hack up the Help-File bug menu item QA awesome git bibi fun (Bjoern) + lots of binaries compressed into one git repo + allows bisection to find when it first appeared + 50+ installs into ~750Mb + built every 64th commit on master - 50% succeeded + having bisected - only a ~200 commit range + maybe visible from the git log + is it a universal install (Kendy) + built on a recent Ubuntu, but with internal libs (Bjoern) + tinderbox integration might be good + is there a script to add a package to git ? (Norbert) + script is in dev-tools (Bjoern) + could automate a once-per-day git repo creation + some of the magic is in the re-pack 4Gb - 750Mb. + Norbert to investigate it working on Mac, will it bloat up + have to copy images, not DMGs * Mitch / MSI building update (sends his regrets) * cairo / Fedora 16 etc. version nasty (Michael) + prolly specific to some (non-default) theme AA: + upgrade the internal cairo to latest stable to fix (Fridrich) + could we break things vs. an old system cairo (Petr) * postgresql bits AA: + add postgresql to 3.5 feature page (Lionel) AA: + checking pg baseline on windows (Fridrich) * Robust subsequenttests to a third category: tail_build tests (Michael/Stephan) + discuss next time: * Next time: + skip 22nd and 29th TSC calls unless an emergency strikes
Re: [Libreoffice] minutes of tech. steering call ...
Hi *, On Thu, Dec 15, 2011 at 6:40 PM, Michael Meeks michael.me...@suse.com wrote: QA awesome git bibi fun (Bjoern) [...] + Norbert to investigate it working on Mac, will it bloat up + have to copy images, not DMGs nitpickDMGs are the images (disk images, similar to a iso, i.e. an in-file filesystem) - so one has to use the extracted version / the version before it gets packed. /nitpick Smoketests already creates such a flat tree, but it is also easy to mount the image and copy the files from the mounted image. (Installation on Mac works by simply copying the files from the dmg to any folder on your harddisk) ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, Dec 15, 2011 at 1:46 PM, Christian Lohmaier lohmaier+libreoff...@googlemail.com wrote: Hi *, On Thu, Dec 15, 2011 at 6:40 PM, Michael Meeks michael.me...@suse.com wrote: QA awesome git bibi fun (Bjoern) [...] + Norbert to investigate it working on Mac, will it bloat up + have to copy images, not DMGs nitpickDMGs are the images (disk images, similar to a iso, i.e. an in-file filesystem) - so one has to use the extracted version / the version before it gets packed. /nitpick Smoketests already creates such a flat tree, but it is also easy to mount the image and copy the files from the mounted image. (Installation on Mac works by simply copying the files from the dmg to any folder on your harddisk) yes that is what I meant during the call... we may get better git compression by using the content of the mounted dmg rather than committing the dmg itself (*)... but then... number will talk ultimately... I'll experiment with both and compare :-) Norbert (*) git should have a easier time to find redundancies across build that way. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote: + cleanup old test build server directories (Thorsten) This is done - there were beta0 builds from the Linux/Windows Release config still around, but since beta0 was not so nice anyway ... ;) + 3.4.5 - tag delayed by two days + builds already on pre-release ftp site, synching to mirrors for announce soon, delay not that large in the end. Might take a day longer, system is still syncing 3.5 + bugzilla submission assistant - lots of work currently + pending integration of link in the help menu for 3.5 AA: + get a permanant re-direction link for bug assistent (Thorsten) AA: + hack up the Help-File bug menu item https://www.libreoffice.org/get-help/bug/ is not what we want? Cheers, -- Thorsten pgpuoUs8DiFCZ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi Thorsten, *, On Thu, Dec 15, 2011 at 9:30 PM, Thorsten Behrens t...@documentfoundation.org wrote: Michael Meeks wrote: + bugzilla submission assistant - lots of work currently + pending integration of link in the help menu for 3.5 AA: + get a permanant re-direction link for bug assistent (Thorsten) AA: + hack up the Help-File bug menu item https://www.libreoffice.org/get-help/bug/ is not what we want? No - as that is tied to the current site layout/structure. For links added to LO itself, never-ever-changing (or better: always working) ones should be used. A proposal for such common URL has been hub.libreoffice.org/whatevertask?optional=parameterslike=versionand=distribution so hub.libreoffice.org/file-a-bug or something like that is what is wanted here. That will then redirect to the get-help/bug page, or when the version is ancient suggests this version is stone-age, we suggest to try a newer version instead of wasting time filing a bug when no new releases are going to be made on that codeline or ah, you're using distro, have a look at those known bugs/file bugs regarding whatever in distro-bugtracker, all other bugs go here → get-help/bugs ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Christian Lohmaier wrote: A proposal for such common URL has been hub.libreoffice.org/whatevertask?optional=parameterslike=versionand=distribution Yep, recall that - wanna work on this, you seem to have spent quite some thought on it already? Cheers, -- Thorsten pgpWkkRW3kXQG.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] Java 7 support in LO 3.4.5 (was: [Libreoffice] minutes of tech. steering call ...)
On Mon, 2011-12-12 at 19:53 +, Pedro Lino wrote: Uninstalled Java 6 rev 29. Run LO 3.4.4. Executed File, Wizard, Letter. Reported missing Java Run LOdev 3.5.0 Build ID: f923851-7f15fca-1f1fd1a-ca8e46d-5bcbce4. Executed File, Wizard, Letter. LOdev crashed. Gosh; when you say 'crashed' - it took down the whole office suite ? that is a pretty horrendous existing bug it'd be nice to fix. Conclusion LO 3.4.4 works like a charm but won't detect Java 7; Right there is no support there. LO 3.5.0 crashes on Wizard execution if Java is not installed or was not detected. Works as expected when Java is detected or selected. So - on this basis, it sounds like supporting Java 7 is something we should be doing, if only to avoid the crashes when it is not present ;-) Having said that - the relevant components will be disabled if there was no Java on the system at install time. One question: if both Java versions are installed and I do not specify which one to use, which version is used? You can select it in tools-options IIRC, otherwise the latest version. Thanks so much for testing, ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Java 7 support in LO 3.4.5 (was: [Libreoffice] minutes of tech. steering call ...)
Hi all Would be great if somebody could check Java 7 more thoroughly, for both upcoming LO 3.4.5 and 3.5. Some findings about Java 7 under Win XP Pro x86 SP3: Uninstalled Java 6 rev 29. Run LO 3.4.4. Executed File, Wizard, Letter. Reported missing Java Run LOdev 3.5.0 Build ID: f923851-7f15fca-1f1fd1a-ca8e46d-5bcbce4. Executed File, Wizard, Letter. LOdev crashed. Installed Java 7 rev 1 without rebooting Run LO 3.4.4. Executed File, Wizard, Letter. Reported missing Java Run LOdev 3.5.0 Build ID: f923851-7f15fca-1f1fd1a-ca8e46d-5bcbce4. Executed File, Wizard, Letter. LOdev crashed. Run again LOdev 3.5.0 Build ID: f923851-7f15fca-1f1fd1a-ca8e46d-5bcbce4. Went to Options, Java, selected Version 1.7.0_01 Executed File, Wizard, Letter. Wizard worked as expected. Uninstalled Java 7. Rebooted Installed Java 7 rev 1 and rebooted Run LO 3.4.4. Executed File, Wizard, Letter. Reported missing Java Run LOdev 3.5.0 Build ID: f923851-7f15fca-1f1fd1a-ca8e46d-5bcbce4. Executed File, Wizard, Letter. Wizard worked as expected. Conclusion LO 3.4.4 works like a charm but won't detect Java 7; LO 3.5.0 crashes on Wizard execution if Java is not installed or was not detected. Works as expected when Java is detected or selected. One question: if both Java versions are installed and I do not specify which one to use, which version is used? -- Pedro ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 2011-12-08 at 16:19 +, Michael Meeks wrote: * gtk3 backend + change the configure to default to 'on' for this + not feasible to build on our legacy machines So - just to wind Fridrich up ;-) I had a wonderful idea of making a 'stubify' perl script that would provide an ABI identical (but empty) library (via some custom assembler) / pkgconfig files etc. such that we could compile link the gtk3 backend even on really old systems. Not done yet, but ... on the TODO stack ;-) HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-qa] Java 7 support in LO 3.4.5 (was: [Libreoffice] minutes of tech. steering call ...)
On 12/08/2011 05:19 PM, Michael Meeks wrote: + back-port Java 7 to 3.4 if no show-stopping regressions in B0 (Stephan) AA: + enable Java 7 in 3.4.5 check RC1 feedback (Stephan) Support for Java 7 (both Linux and Windows) is now also enabled for the upcoming LO 3.4.5. I just checked on Linux that a JRE 1.7.0_01 can be enabled on the Tools - Options... - LibreOffice - Java tab page, and that File - Wizards - Letter... (which uses Java) looks reasonable. Would be great if somebody could check Java 7 more thoroughly, for both upcoming LO 3.4.5 and 3.5. Thanks, Stephan ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Java 7 support in LO 3.4.5 (was: [Libreoffice] minutes of tech. steering call ...)
Support for Java 7 (both Linux and Windows) is now also enabled for the upcoming LO 3.4.5. I just checked on Linux that a JRE 1.7.0_01 can be enabled on the Tools - Options... - LibreOffice - Java tab page, and that File - Wizards - Letter... (which uses Java) looks reasonable. Would be great if somebody could check Java 7 more thoroughly, for both upcoming LO 3.4.5 and 3.5. I'm new to this QA system, but wouldn't it be useful to know when (date/time) this was added? There isn't a 3.4.5 branch yet so I assume this can be tested on the master? The latest Win daily is from Dec 7th so it probably doesn't include that fix? Is there a list of functions that depend on Java? Or a Java test for LO? ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice] minutes of tech. steering call ...
* Present: + Rainer, Stephan, Eike, Fridrich, Norbert, Kendy, Mitch, Bjoern, Michael, Tor, Lionel, Caolan, Cedric, Thorsten, Andras, Kohei * Completed Action Items + python/wizards merge for 3.5 strip old versions (Michael) + send Monty mail about other options (Michael) + hunt systemic per-tinderbox errors (Rainer) + abandoned for now + file soffice paramater issues as most-annoying (Lionel) + look at dev-builds with desktop integration for linux (Petr) + remove --enable-release-builds until RCs (packagers) + back-port Java 7 to 3.4 if no show-stopping regressions in B0 (Stephan) AA: + enable Java 7 in 3.4.5 check RC1 feedback (Stephan) * Pending Action Items + [in progress] extract 64bit build hardware from firewall (Kendy / Admins) + [in progress] come up with a list of QA heros for next meeting (Rainer) + need to download install libpostgresql for Mac/Windows (Michael) + add tinderbox name to build-id (Norbert) AA: + review pending labels patch if possible (Bjoern) * Action Items * Release Engineering update (Petr) + 3.5.0 Beta 1 feature freeze hit, branched etc. + builds originally quite broken, but much better now + may be delayed until late today / tomorrow + smaller smoke-testing window than hoped for + delayed by accidental re-base of -3-5 on master + tag monday / slip slightly. + move 3.4.5 RC1 freeze out to mid-week + individuals need to carefully cherry-pick their fixes to the branch + please test bigger fixes on master and only cherry-pick when the tinderboxes like you ... AA: + cleanup old test server directories (Thorsten) * verbose builds left and right + tinderboxes switched to not produce huge amounts of log output + default is not churn during build * gtk3 backend + change the configure to default to 'on' for this + not feasible to build on our legacy machines AA: + disable gtk3 except in experimental mode (Michael) * lightproof grammar checker (Andras) + python extension, long history, around for years + lightweight, no large dependencies + Laszlo integrated it with normal dictionary extensions + can include it into the dictionaries/ module + committed to master, seems to work well: + windows + Linux, English + Hungarian + where is the up-stream ? + no public repo / just tar-balls + Laszlo would like a repo on freedesktop AA: + create 'lightproof' git repo on freedesktop for Laszlo (Michael) + horror grammer checker leaks fixable findable with internal python + fewer languages supported, but tool for migrating rules in progress + currently we bundle nothing = no functional regression + can be used in parallel with LanguageTool + lightproof - conservative checker - blogk post to follow. AA: + we will cherry-pick to Beta2 (Caolan, Andras) (Petr) * default display issue (Michael / Caolan) + quite some research done, but not fixed ... + 'Primary' on Windows == LCD display, ditto on Linux AA: + rename VCL API to make it GetBeamerScreen (Michael) * QA update (Rainer) + Bugzilla assistant + some problems with it; around 20 bugs https://bugs.freedesktop.org/buglist.cgi?query_format=advancedshort_desc=BUGZILLAASSISTANTbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFObug_status=PLEASETESTshort_desc_type=allwordssubstrcomponent=WWWproduct=LibreOffice + need to think what to do with it + requires manual updating per version AA: + forward access details to Thorsten (Rainer) AA: + get Rainer setup with git commit access (Michael) AA: + add fixing it to top #10 easy tasks page (Petr) + 3.5 release + concerns around: https://bugs.freedesktop.org/show_bug.cgi?id=36677 + was always wrong in the past - but afflicts Windows 7 + luckily shipping the fix in 3.4.5 helps this + Bug hunting session (Cor) - regrets. + http://wiki.documentfoundation.org/QA/Improving_QA-Release-3.5#Bug-hunting_session * Remote login for testing branches / new work on (Lionel) + we could use Voruppe to allow people to test stuff (Fridrich) + Norbert happy to create one-shot tinderboxes to target feature branch * debugging re-builds (Cedric) + re-building whole tree with dbgutil is a nightmare + having binary incompatible tree is silly (Bjoern) + missing dump-as-xml code; switched to dbgutil + problems
Re: [Libreoffice] minutes of tech. steering call ...
Hi Lionel, On Fri, 2011-12-02 at 01:49 +0100, Lionel Elie Mamane wrote: 1) Change configure.in to detect / use the MariaDB lib instead of / alternatively to the MySQL C Connector. I see not reason not to leave people the choice; Makes sense. Note that we still (maybe?) have a GPL problem with using the C++ connector. Maybe, because MySQL stuff used to not be straight-GPL, but GPL + exceptions for open source projects. So - we are an LGPL project as a tactic, since we compete with a Microsoft Office that appears to be free (since it is semi-ubiquitous) for ISVs; and many of them depend on it and in doing so reinforce that ecosystem. Bundling with MySQL's (IMHO horribly busted) weirdo license connector: which is effectively a GPL licensed piece. Asking ISVS to GPL all their software (or pay money to Oracle not to) by linking effectively GPL mysql stuff into our core seems rather non-optimal. That's why I'm so excited about the potential for Monty's library (quite apart from the new feature possibilities working better with MariaDB). But of course, that'd also necessitate re-writing the mysqlc connector to use his C API (this is perhaps the easiest approach vs. waiting for / working on a new LGPL mysql C++ library alike). So your argument is great, as far as it goes ie. for our distribution; but it potentially harms rather an important tactic for people writing extensions :-) HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
* Present: + Eike, Rainer, Andras, David, Lionel, Stephan, August Bjoern, Norbert, Caolan, Kendy, Petr, Mitch, Michael S. Tor, Kohei, Cedric, Monty * Completed Action Items + help out Lionel with a deeper dive into fdo#39950 (Caolan) + flatten un-maintained NLPSolver into our git repo (Michael) + [in progress] default to TM safe (non-TDF) branding (Thorsten) + ask Christian wrt. Mac / PPC (on-list) + remove bit-rotted pch work, or file easy hack for that (Norbert) + enable on-line updates for QA in cross-compiled dailies (Kendy) + unit tests passing, enabled in master, will be enabled in Beta1. + enable Java 7 for Windows in master, poke qa list too (Stephan) + move slow calc tests over to 'make subsequentcheck' (Markus) * Pending Action Items + [in progress] extract 64bit build hardware from firewall (Kendy / Admins) + back-port Java 7 to 3.4 if no show-stopping regressions in B0 (Stephan) + come up with a list of QA heros for next meeting (Rainer) + python/wizards merge for 3.5 strip old versions (Michael) * Action Items * Kill testtool (August) + string / cleanup is hindered by testtool (August) + should we kill it completely for 3.6 ? (Stephan) + still in git - so can be ressurected (Norbert) + around 1/2 of the basic/ code is hooks for testtool (August) * remove test-tool post the 3.5 branch all its hooks. * MariaDB intro (Monty) + original MySQL company product creator + MariaDB increasingly visible in the market featureful + 100% drop-in replacement for C connector + identical protocol, fully interoperable + MariaDB adds extra stuff, but handshakes first + client-side is ABI compatible with old mysql C library + can continue to use the C++ connector; and get that to use MySQL C library (Lionel) + how much work is that ? + new features + progress reporting in long runing table operations + plan to start collaboration next year + never shipped the C library in the past (Lionel) + would be good to bundle MariaDB's client library + commit to fix any bugs related to LibreOffice in MariaDB AA: + send Monty mail about other options (Michael) * Release Engineering update (Petr) + 3.5 Beta0 should be available today as pre-release ftp + mirrored for tomorrow + feature-freeze is on Monday (noon) + double code review not required until nearer RC1 = bug fix committer should cherry-pick themselves + tripple cross-company code review for features until nearer RC1 + exceptions: artwork, unit-tests until RC1 + tinderboxes: will attack the libreoffice-3-5 branch primarily + branch immediately on feature-freeze (Petr, Caolan) + tag on Tuesday ? + concerns wrt. hit run Friday commits (Norbert) + expect twitchiness - it's release time ... + cherry-picking from master to the branch default mode post 3.5 * use dev builds for beta builds ? (Petr) + gives us keyid builds, and parallel installability + no desktop integration under linux AA: + look at improving that for linux (Petr) AA + remove --enable-release-builds until RCs (packagers) * Enable postgresql extension in distro-config (Michael) + needs a with-system-libpq etc. for Debian (Norbert) AA: + need to download install libpostgresql for Mac/Windows (Michael) + can enable for Mac etc. by default. * FOSDEM dev-room papers reminder: + please file talks + http://wiki.documentfoundation.org/Marketing/Events/Fosdem2012 * Cross-compiling MSIs building (Mitch) + not much progress this week * QA Update (Rainer) + significant increase of bugzilla activity, several more reports contributors + master - not in good shape + new windows builds each few hours + each new build several new bugs, and several disappear + eg. crash on every spreadsheet close + error messages on save / blocker stuff + then disappear again; the same day. + expected to calm down when we branch = no new action now + Q. is it correlated with one tinderbox ? AA: + hunt systemic per-tinderbox errors (Rainer) + MingW / cross-compiled tinderboxes not so good (Petr) + not related to this + so buggy, testing stopped + why is it so (Kendy) + regressions from time to time +
Re: [Libreoffice] minutes of tech. steering call ...
Hi Michael, On Thursday, 2011-12-01 16:21:09 +, Michael Meeks wrote: * DateTime default constructor fix (Eike) + looses ~500 places to call gettimeofday by mistake umm.. would be nice, but.. seems that didn't come across correctly. There are about 100 places out of 400, I'll come up with more detailed numbers later. + will commit later today / be warned. Yup :-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpM8CwnOAAVJ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (01-12-11 17:21) * QA Update (Rainer) + Cor to organise a bug-hunting session for B1 next weekend. Working to get some support :-) Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Le 01/12/2011 17:21, Michael Meeks a écrit : * MariaDB intro (Monty) + original MySQL company product creator + MariaDB increasingly visible in the market featureful + 100% drop-in replacement for C connector + identical protocol, fully interoperable + MariaDB adds extra stuff, but handshakes first + client-side is ABI compatible with old mysql C library + can continue to use the C++ connector; and get that to use MySQL C library (Lionel) + how much work is that ? Just FYI, because I seem to be the only one building it, the mysql native connector on Mac OSX no longer builds since the libmysqlconncpp library version bump commit. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, Dec 01, 2011 at 04:21:09PM +, Michael Meeks wrote: * MariaDB intro (Monty) + 100% drop-in replacement for C connector + identical protocol, fully interoperable + MariaDB adds extra stuff, but handshakes first + client-side is ABI compatible with old mysql C library + can continue to use the C++ connector; and get that to use MySQL C library (Lionel) + how much work is that ? Modulo any bad surprise in the C++ connector build system proper, on the LibO side it seems we only have to: 1) Change configure.in to detect / use the MariaDB lib instead of / alternatively to the MySQL C Connector. I see not reason not to leave people the choice; we want to build *our* official builds with MariaDB lib, but people are free to do otherwise on their local libs (GPL restrictions come into effect only for things one redistributes). 2) Change the definition of MYSQL_LIBFILE in mysqlc/source/makefile.mk Note that we still (maybe?) have a GPL problem with using the C++ connector. Maybe, because MySQL stuff used to not be straight-GPL, but GPL + exceptions for open source projects. Is this exception still valid for new versions released by Oracle, and does it give us enough wiggle room that we are happy with it? Yes it is still valid: MySQL Connector/C++ is licensed under the GPLv2 or a commercial license from Oracle Corporation. There are special exceptions to the terms and conditions of the GPLv2 as it is applied to this software, see the FLOSS License Exception http://www.mysql.com/about/legal/licensing/foss-exception.html. As to enough wiggle room, my reading of it is that it exempts LibreOffice from the requirements of the GPL, even if LibreOffice is linked against MySQL Connector/C++. We only have to obey the GPL on the connector itself, something which we have no intention of not doing: we ship the patches we apply and the build system used as part of our sources. So my analysis is that we don't have a GPL-problem with the Connector/C++. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, Dec 01, 2011 at 10:35:45PM +0100, Alex Thurgood wrote: Le 01/12/2011 17:21, Michael Meeks a écrit : * MariaDB intro (Monty) + original MySQL company product creator + MariaDB increasingly visible in the market featureful + 100% drop-in replacement for C connector + identical protocol, fully interoperable + MariaDB adds extra stuff, but handshakes first + client-side is ABI compatible with old mysql C library + can continue to use the C++ connector; and get that to use MySQL C library (Lionel) + how much work is that ? Just FYI, because I seem to be the only one building it, the mysql native connector on Mac OSX no longer builds since the libmysqlconncpp library version bump commit. Feel free to send me a build log showing the failure and/or make it an official bug report that you assign to me. Do you have boost/variant.hpp installed? That's the only thing I broke on purpose. One now needs boost/variant.hpp for the MySQL C++ Connector. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 25/11/11 15:13, Bjoern Michaelsen wrote: On Fri, Nov 25, 2011 at 11:20:50AM +0100, Michael Stahl wrote: DISPLAY=:42 ./soffice --accept=pipe,name=$USER;urp; --norestore --nologo -env:UserInstallation=file:///tmp/xyz instead of that monster you cant now run: make debugrun on Linux(*), which ... then attach gdb to soffice.bin will do that too. then run subsequenttests e.g. make subsequentcheck OOO_TEST_SOFFICE=connect:pipe,name=$USER Instead of that you can now: make subsequentcheck gb_JunitTest_DEBUGRUN=T And have one shell running gdb and the other running the test. thanks a lot, that's a lot simpler and should finally make subsequenttests so easy to debug that even mmeeks can do it ;) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 2011-11-24 at 23:38 +0100, Bjoern Michaelsen wrote: However, we are not so much interested in interactively working with soffice in the subsequenttest. Rather than return to the 60s I'd still like to have an interactive debugger :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi Bjoern, On Fri, 2011-11-25 at 05:56 +0100, Bjoern Michaelsen wrote: One allnigher later, its to late for opinions. Implemented with: This looks like a real improvement, that will make subsequentcheck much more useful, and me (at least) more likely to care about running it :-) Still might need some tuning (core file location for example, superfluous gdb output), but it basically works: ulimit -c unlimited make subsequentcheck I was wondering whether we could not hook the existing crash-reporter SEGV code, and dump the 'backtrace' output in a file-name pulled from an environment variable (that we could easily set in the makefile rule). But of course working from the core file we can get more information post-mortem debugging / inspection in theory. It seems like soffice.bin crashed during the test excution! Found a core dump at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user, moving it to /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user/core.SfR2 [...] Lovely :-) and a hint at the full log: see full error log at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/done.log make[1]: Leaving directory `/mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw' So - (for me) the only missing piece now is the ability to quickly (ie. 12 minutes) get back to running precisely the failing test; Is it easy / possible to print a message at the end (after all this goodness) saying: run:\ncd sw; make foo_baa_sw_subsequent_check_baz_biff_boff ? :-) Thanks again for this - a really big improvement :-) ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 24/11/11 21:23, Caolán McNamara wrote: On Thu, 2011-11-24 at 16:26 +, Michael Meeks wrote: + subsequentcheck + number of ways to improve it (Caolan) the way i've always debugged it is something like: DISPLAY=:42 ./soffice --accept=pipe,name=$USER;urp; --norestore --nologo -env:UserInstallation=file:///tmp/xyz then attach gdb to soffice.bin then run subsequenttests e.g. make subsequentcheck OOO_TEST_SOFFICE=connect:pipe,name=$USER can run this in a loop as well... + Bjoern has a nice write-up of how to debug it here: i.e. sommat like a) just move that out of dev-tools into bin or solenv/bin b) tweak it to honour $COLORTERM/$TERM -e c) add a handle SIGPIPE nostop noprint pass d) get the definitely correct pid in there --- e) get the tooling to catch the disconnected error and say that LibreOffice crashed, rather than the current somewhat obscure error f) spit out a line liner to rerun the first failing test in isolation with soffice server under gdb this would of course be very useful when running the tests non-interactively such as on tinderboxes. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, Nov 25, 2011 at 09:48:22AM +, Michael Meeks wrote: So - (for me) the only missing piece now is the ability to quickly (ie. 12 minutes) get back to running precisely the failing test; Is it easy / possible to print a message at the end (after all this goodness) saying: run:\ncd sw; make foo_baa_sw_subsequent_check_baz_biff_boff ? :-) Done. Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, Nov 25, 2011 at 08:58:06AM +, Caolán McNamara wrote: On Thu, 2011-11-24 at 23:38 +0100, Bjoern Michaelsen wrote: However, we are not so much interested in interactively working with soffice in the subsequenttest. Rather than return to the 60s ... Austin PowersYeah, Baby, yeah!/Austin Powers *SCNR*, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, Nov 25, 2011 at 11:20:50AM +0100, Michael Stahl wrote: the way i've always debugged it is something like: DISPLAY=:42 ./soffice --accept=pipe,name=$USER;urp; --norestore --nologo -env:UserInstallation=file:///tmp/xyz then attach gdb to soffice.bin then run subsequenttests e.g. make subsequentcheck OOO_TEST_SOFFICE=connect:pipe,name=$USER can run this in a loop as well... Feel free to add that hint to solenv/gbuild/JunitTest.mk in a concise manner. Bonus points for something like: gdb -ex at $! ... Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, Nov 25, 2011 at 11:20:50AM +0100, Michael Stahl wrote: DISPLAY=:42 ./soffice --accept=pipe,name=$USER;urp; --norestore --nologo -env:UserInstallation=file:///tmp/xyz instead of that monster you cant now run: make debugrun on Linux(*), which ... then attach gdb to soffice.bin ... will do that too. then run subsequenttests e.g. make subsequentcheck OOO_TEST_SOFFICE=connect:pipe,name=$USER Instead of that you can now: make subsequentcheck gb_JunitTest_DEBUGRUN=T And have one shell running gdb and the other running the test. Best, Bjoern (*) from gbuild modules or toplevel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi *, On Thu, Nov 24, 2011 at 5:26 PM, Michael Meeks michael.me...@suse.com wrote: * Pending Action Items + ask Christian wrt. Mac / PPC (Fridrich) As I keep seeing this without being aware of any mail/question regarding this - Is that Christian me? I'd guess so since I run the Mac/PPC tinderbox, but... :-) So what is the question? I'm pretty sure this one can be answered via mail and doesn't need to wait for me attending the call again :-) * Release Engineering update (Petr) + 3.5.0-beta0 - coming soon, kicking the tires of the build process / stabilising + commit deadline is Monday Nov 28 (next Monday) Oh, crap - should probably nominate https://bugs.freedesktop.org/show_bug.cgi?id=42720 as blocker sooner than later... + feature freeze is 1 week later + Please check most annoying 3.5 bugs: + https://bugs.freedesktop.org/show_bug.cgi?id=37361 + Windows error / during installation + extension registration / terminal launch issues I'd suggest to add document file save to MS formats to that list. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, 2011-11-25 at 15:17 +0100, Christian Lohmaier wrote: * Pending Action Items + ask Christian wrt. Mac / PPC (Fridrich) As I keep seeing this without being aware of any mail/question regarding this - Is that Christian me? I'd guess so since I run the Mac/PPC tinderbox, but... :-) Hah :-) indeed - Fridrich just didn't show up for some weeks sadly. The question was: can you do the Mac / PPC release builds for the next release ? if not Fridrich can prolly handle them, but it'd be more ideal if that can be spread around. So what is the question? I'm pretty sure this one can be answered via mail and doesn't need to wait for me attending the call again :-) Too true :-) Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
* Present: + Thorsten, Stephan, Mitch, Eike, Andras, David, Bjoern, Kendy, Caolan, Michael S, Petr, Rainer, Lionel, Tor, Markus * Completed Action Items: + add merged msi details to 3.5 release page (Andras) + add unexpected mingw regressions to MingW 'most-annoying' (Rainer) + send ssh keys for Linux build machine access to Fridrich (Caolan) + concrete debug proposal for the public list (Stephan) + poke at and 'adopt' some easy hacks: http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill (All) + tinderbox owners should change names Thorsten to prune server (All) + looks lots prettier ~done * Pending Action Items + [in progress] default to TM safe (non-TDF) branding (Thorsten) + [in progress] enable on-line updates for QA in cross-compiled dailies (Kendy) + [in progress] extract 64bit build hardware from firewall (Kendy / Admins) + come up with a list of QA heros for next meeting (Rainer) + ask Christian wrt. Mac / PPC (Fridrich) + python/wizards merge for 3.5 strip old versions (Bjoern) * Action Items * Release Engineering update (Petr) + 3.5.0-beta0 - coming soon, kicking the tires of the build process / stabilising + commit deadline is Monday Nov 28 (next Monday) + feature freeze is 1 week later + Please check most annoying 3.5 bugs: + https://bugs.freedesktop.org/show_bug.cgi?id=37361 + Windows error / during installation + extension registration / terminal launch issues * Java 7 (Stephan) + requests / concern about it + already enabled for Linux + we should enable for Windows + duplicate the entry from XML file from Linux - Windows sanity check. + rumoured instability with Java 7 + is it generally fixed / still broken ? AA: + enable Java 7 for Windows, post qa list to give it a try (Stephan) * Unit tests issue (Markus [Moggi]) + calc unit tests take around 30 seconds now + move some of them to tinderboxes / defer building + we have tons of filter tests - ~20 files to import calc etc. + make subsequentcheck - the solution (Stephan) + the JUnit UNO API tests are a pain (Michael) + can we use 'make build' instead ? + concerned to run some basic tests every time + have lots of tests, that are nice, but don't need to be executed every time. + no need for more different test rules (Bjoern) + add them to subsequentcheck + if we run just cppunittests in subsequenttests (Bjoern) + fast easier to debug + ie. disable Java, and avoid undebuggable uno tests + tests should be executed with tinderboxes, useful (Markus) + have found problems, l10n issues etc. + subsequentcheck + number of ways to improve it (Caolan) + Bjoern has a nice write-up of how to debug it here: + http://sweetshark.livejournal.com/2271.html + can't we just run 'make build' and then 'make' + want to extend the tests yet further ... AA: + move some slow tests over to 'make subsequentcheck' (Markus) + should be a ~trivial makefile rename / tweak + make subsequentcheck afterwards * Officially kill bit-rotted pch work (Norbert in absentia) + eager to kill them, they're unmaintainable, bit-rots with each commit (Kendy) + tried to use them once 6 momths ago, failed miserably (Tor) AA: + remove them, or file easy hack for the same (Norbert) * NlpSolver (Michael) + un-maintained, Sun extension, no live up-stream + flatten it into git as a module instead * Cross-compiling MSIs building (Mitch) + slow but steady, continuing build.pl etc. re-factor * QA Update (Rainer) + had to leave early. * bug priority handling (Lionel) + https://bugs.freedesktop.org/show_bug.cgi?id=39950 + vs. wrong icon issue - severity AA: + help out diving deeper into it next week (Caolan) + is it a missing copy-constructor ? * Cor's bug reporting context ? + table of who found what 3.5 bugs, how good they are ? + T-shirt prizes ? + resources low for triage, can we easily assess quality of bug-reports for a fair metric ? + discuss with Rainer next time. * 3.5 most annoying bugs ... + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361hide_resolved=1 -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 2011-11-24 at 16:26 +, Michael Meeks wrote: + subsequentcheck + number of ways to improve it (Caolan) + Bjoern has a nice write-up of how to debug it here: i.e. sommat like a) just move that out of dev-tools into bin or solenv/bin b) tweak it to honour $COLORTERM/$TERM -e c) add a handle SIGPIPE nostop noprint pass d) get the definitely correct pid in there --- e) get the tooling to catch the disconnected error and say that LibreOffice crashed, rather than the current somewhat obscure error f) spit out a line liner to rerun the first failing test in isolation with soffice server under gdb C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 24 Nov 2011 20:23:22 + Caolán McNamara caol...@redhat.com wrote: On Thu, 2011-11-24 at 16:26 +, Michael Meeks wrote: + Bjoern has a nice write-up of how to debug it here: i.e. sommat like a) just move that out of dev-tools into bin or solenv/bin b) tweak it to honour $COLORTERM/$TERM -e c) add a handle SIGPIPE nostop noprint pass d) get the definitely correct pid in there --- e) get the tooling to catch the disconnected error and say that LibreOffice crashed, rather than the current somewhat obscure error f) spit out a line liner to rerun the first failing test in isolation with soffice server under gdb Hmm, I just had another crazy idea, since we are mostly interested in two things from the junit test: - does the product work as expected? that works reasonably well as long as the test doesnt crash however crashes are icky to detect reliable from the outside - if it crashes, we want to have a backtrace However, we are not so much interested in interactively working with soffice in the subsequenttest. So how about a very old fashioned and almost forgotten way to debug: creating a core dump! For bonus points one could then even print the stacktrace of a crashed test right from make subsequentcheck. Opinions? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 24 Nov 2011 23:38:28 +0100 Bjoern Michaelsen bjoern.michael...@canonical.com wrote: However, we are not so much interested in interactively working with soffice in the subsequenttest. So how about a very old fashioned and almost forgotten way to debug: creating a core dump! For bonus points one could then even print the stacktrace of a crashed test right from make subsequentcheck. Opinions? One allnigher later, its to late for opinions. Implemented with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=74f44646ba5b400cc39d78940677f136711459b5 http://cgit.freedesktop.org/libreoffice/core/commit/?id=279473f1ed6cd3bb6f6d2b8b9c75529b91836e39 http://cgit.freedesktop.org/libreoffice/core/commit/?id=1cec66388eac81af2197da4fbf8fd2b00c56c7a5 http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1b57be652ac532ebddb3e3e53dddc35ae420f31 Still might need some tuning (core file location for example, superfluous gdb output), but it basically works: ulimit -c unlimited make subsequentcheck gives you a full soffice stacktrace: It seems like soffice.bin crashed during the test excution! Found a core dump at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user, moving it to /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user/core.SfR2 [...] Program terminated with signal 11, Segmentation fault. #0 0x2adaed22ffbd in sw::mark::MarkManager::MarkManager (this=0x325add0, rDoc=..., __in_chrg=optimized out, __vtt_parm=optimized out) at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw/source/core/doc/docbm.cxx:310 310 int i = *(reinterpret_castint*(NULL)); #0 0x2adaed22ffbd in sw::mark::MarkManager::MarkManager (this=0x325add0, rDoc=..., __in_chrg=optimized out, __vtt_parm=optimized out) at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw/source/core/doc/docbm.cxx:310 [...] While only showing the essentials of the Java stacktrace: 1) contents_flows_to(complex.accessibility.AccessibleRelationSet) com.sun.star.lang.DisposedException at $Proxy13.loadComponentFromURL(Unknown Source) at util.DesktopTools.openNewDoc(DesktopTools.java:247) at util.WriterTools.createTextDoc(WriterTools.java:51) at complex.accessibility.AccessibleRelationSet.before(AccessibleRelationSet.java:168) Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:392) and a hint at the full log: see full error log at /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/done.log make[1]: Leaving directory `/mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw' Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
* Present: + Eike, Bjoern, Andras, Michael, Tor, Norbert, Stephan, Caolan, Kohei, Michael S, Thorsten, Lionel, Mitch * Completed Action Items + add easy hack to kill PRODUCT in favour of DBG_UTIL (Bjoern) + ask wrt. hacking php to improve easy-hacks presentation (Bjoern) + reply to Peter's RFC wrt. tail_build (Norbert) * Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dailies [in progress] (Kendy) + [in progress] extract 64bit build hardware from firewall (Kendy) + come up with a list of QA heros for next meeting [in progress] (Rainer) + ask Christian wrt. Mac / PPC (Fridrich) + add unexpected mingw regressions to MingW 'most-annoying' (Rainer) + send ssh keys for Linux build machine access to Fridrich (Caolan) + [in progress] concrete debug proposal for the public list (Stephan) * Release Engineering update (Petr) + updated the schedule for 3.4.5 and 3.5.0 as decided on the last meeting. See the announce at http://lists.freedesktop.org/archives/libreoffice/2011-November/020724.html + IMPORTANT: deadline for beta0 is less than two weeks from now + finally have daily builds for Windows at http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/master/ http://dev-builds.libreoffice.org/daily/Windows_2008R2/master/ but not sure how often the build is broken + is nervous by the still opened blocker https://bugs.freedesktop.org/show_bug.cgi?id=42227 + Radek on it. * Python / Wizards code / merge (Bjoern) + some minor problem blocking it AA: + merge for 3.5 strip old versions and await user testing (Bjoern) * Easy Hacks - poke at them ... (Bjoern) + some easy hacks need owner / caretakers triage: http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill * Lionel Elie Mamane + been hacking on Base + fixing things that annoy him + shepherding the postgresql driver in for 3.5 * new MSI packaging (Andras) + hack-week project to make single MSI with all langs VC++ restribs + merged to master and ready to go for 3.5 AA: + add details to 3.5 release page (Andras) + some cleanups still required; help-pack testing etc. + drops NSIS requirement + default to it for 3.5 ... * consistent tinderbox naming scheme (Thorsten, Norbert) + Pedro Lino suggested that + names turning up in other scripts + seems that it might make it easier for the QA guys, if the names began with the target platform, followed by an identifier, so that the structure of dev-builds.libreoffice.org/daily is clearer. Rainer? + helps users find the right downloads from dev-tools domain too + problems of specificity: Win2008r2 eg. ? + platform=os-version-arch@id_free-form-user-friendly-info eg. MacOSX-10.6.0-Intel@25_no_moz_no_binfilter AA: + tinderbox owners should change names Thorsten to prune server (All) * Meeting Timing + doodle poll confirms current time = sticking with that. * Cool stuff: + Android + proceeding slowly but surely + can package lots of libs into an Android pkg + more and more unit tests running: sal fine eg. + onto the C++ UNO bridge. + lots of strange restrictions on package production and unpacking, lots to investigate + nothing useful for end-users yet. + Layout code (Caolan) + latest of 19 other people's attempts + stripped existing obsolete bits from the code + OptimalSize hooks are there from previous attempts + hapless Word-Count dialog victim being tackled + prototyping bits on top of that: + XML reader etc. after that + .src file conversion to a 'fixed' layout ? + no layout inference. + python uno scripting (Lionel) + named structure member initialization + remaining 'build' patches (Bjoern) + finally getting merged or killed, 20 down to 10 * Cross-compiling MSIs building (Mitch) + knee-deep in re-factoring build / make_installer perl code + to create helpful utility functions for msi creation -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, Nov 17, 2011 at 9:42 AM, Michael Meeks michael.me...@suse.com wrote: * consistent tinderbox naming scheme (Thorsten, Norbert) + Pedro Lino suggested that + names turning up in other scripts + seems that it might make it easier for the QA guys, if the names began with the target platform, followed by an identifier, so that the structure of dev-builds.libreoffice.org/daily is clearer. Rainer? + helps users find the right downloads from dev-tools domain too + problems of specificity: Win2008r2 eg. ? + platform=os-version-arch@id_free-form-user-friendly-info eg. MacOSX-10.6.0-Intel@25_no_moz_no_binfilter AA: + tinderbox owners should change names Thorsten to prune server (All) Please see https://wiki.documentfoundation.org/Development/Tinderbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi, On 2011-11-10 at 17:34 +, Michael Meeks wrote: + ideally, done as a patch + needs windows experimentation etc. + where does 'assert' output on windows go ? When we hit an assert on Windows, it shows a message box with the message + file + lineno, and possibility to Abort / Ignore / Attach the debugger. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
* Present: + Norbert, Eike, David, Stephan, Michael, Bjoern, Andras, Petr, Caolan, Thorsten, Cedric, Fridrich, Tor, Christian * Completed Action Items + rotate top #10 easy-hacks on front-page (Bjoern) + poke UI / Translation issue bug#42388 (Andras) + a normal l10n bug... + think about Linux build / up-load work (Caolan) + RedHat to handle it AA: + send ssh keys for access to Fridrich (Caolan) + update wiki to mark 3.3.5 as skipped (Petr) + proposal for closer in 3.4.5 release (Petr) + connect to Fridrich's machine fix Win32 build failure (Michael, Bjoern) + finally it builds ! * Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dailies [in progress] (Kendy) + come up with a list of QA heros for next meeting [in progress] (Rainer) + ask wrt. hacking php to improve easy-hacks presentation (Bjoern) + extract 64bit build hardware from firewall (Kendy) + ask Christian wrt. Mac / PPC (Fridrich) + add unexpected mingw regressions to MingW 'most-annoying' (Rainer) * Meeting time: + please update the doodle poll: http://www.doodle.com/d7cxxvfhergqhhqg * Release Engineering update (Petr) + Proposal for a one-off 3.4.5 release + due-to extended 3.5 dev cycle + http://wiki.documentfoundation.org/ReleasePlan/3.5#3.5.0_release + have a Beta0 - 1 week earlier than feature-freeze (just for Cor ;-) + skip Beta 2 - for 3.4.5 RC1 + skip Beta 4 - for 3.4.5 RC2/release + does it affect a 3.5.6 release. + Dec 5th feature freeze details (Petr/Michael) + branch immediately on feature-freeze (Petr, Caolan) + new onegit makes this much easier + should we wait for green tinderboxen ? - prolly not, stabilise on branches + double code review not required until nearer RC1 = bug fix committer should cherry-pick themselves + tripple cross-company code review for features until nearer RC1 + exceptions: artwork, unit-tests until RC1 + tinderboxes: will attack the libreoffice-3-5 branch primarily * QA update (Rainer) + we missed Rainer * FOSDEM / conference pieces + please submit your LibreOffice dev-room talks to: http://wiki.documentfoundation.org/Marketing/Events/Fosdem2012 + block out your 4-5 Feb * debug-levels / modes clarity (Bjoern/Stephan) + writer debugging, DBG_UTIL symbols all gone to OSL_DEBUG_LEVEL 2 + other things depend on this, so can't build in a product version (?) + missing common understanding of how to use: + NDEBUG, DBG_UTIL, OSL_DEBUG_LEVELs etc. + when are they binary compatible / incompatible etc. + Stephan's master plan + assertions should abort (one day) + all these issues are related. + prefer to move it to the mailing list + gather use-cases there ... + iterative way to get there required (Thorsten) + need to document what is there now (Bjoern) AA: + produce a fleshed out concrete proposal for the public list (Stephan) + assertion failures ? + should they be enabled in product build ? + if ability to recover - why assert ? + tracing - printing progress as we go along + need to capture semantics of tracing, warning, errors etc. + assert == logically impossible, or shouldn't happen ... + bin compat should be orthogonal to asserts/tracing (Norbert) + corrupt input currently being flagged by 'asserts' + problem - old asserts, did not abort = we got lots of them. + DBG_UTIL doesn't work on windows - runtime problems (Tor) AA: + add easy hack to kill PRODUCT in favour of DBG_UTIL (Bjoern) + ideally, done as a patch + needs windows experimentation etc. + where does 'assert' output on windows go ? + what about the 'debugwindow' (ctrl-alt-shift-d) + should we dump it ... yes. * Make binfilter depend on tail_build + not a big issue, will happen as/when needed or someone wants that. + other modules prevent that currently; cf. 'extensions' AA: + reply to Peter's RFC (Norbert) * UNO API tagging - compile time flags in .hdl ? + difficulty between uses impls. + source code, or object level ? + unclear how we can do better guesses ... + in-house extensions etc. + theoretically impossible to derive
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, Nov 10, 2011 at 11:34 AM, Michael Meeks michael.me...@suse.com wrote: * Make binfilter depend on tail_build + not a big issue, will happen as/when needed or someone wants that. + other modules prevent that currently; cf. 'extensions' Errata: other module are on the critical path for merging thing into tail_build before binfilter become a 'blocker' to further progress. but binfitler as a dependency of tail_build _can_ be done righ now Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
2011/11/3 Michael Meeks michael.me...@suse.com: * QA update (Rainer) + problems with UI translations for Farsi / Arabian AA: + chase it down cf. bug#42388 (Andras) I made a comment and closed the bug. It is not a bug that we can fix, translation is missing. Farsi is at ~50%. OTOH Arabic is at 96%, it is much better. Both languages have an active translator team. It just takes time to finish the translation. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
* Present: + Stephan, David, Eike, Andras, Norbert, Rainer, Caolan, Cedric, Petr, Fridrich, Kohei, Kendy, Michael * Completed Action Items + review Noel's OLE automation fix for 3.4.4 (Petr) + package Liberation fonts on Win32 (Fridrich) * Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dailies [in progress] (Kendy) + come up with a list of QA heros for next meeting [in progress] (Rainer) + rotate top #10 easy-hacks on front-page (Bjoern) + ask wrt. hacking php to improve easy-hacks presentation (Bjoern) * Release Engineering + diversifying build work AA: + think about Linux build / up-load work (Caolan) AA: + extract 64bit build machine from firewall (Kendy) + Norbert volunteered for OS/X, Thorsten as a deputy AA: + ask Christian wrt. Mac / PPC (Fridrich) + co-ordination on IRC + ML's + need fallbacks for everyone. + 3.3.5 + will not come - no significant fixes to justify AA: + update wiki to mark it as skipped (Petr) + 3.4.4 update (Petr) + RC2 build up-loading now, for announce soon + sudden rush of 3.4.x fixes impact on schedule + lots of people nominating most annoying bugs + lots of patches merged to 3.4 around deadline + post conference back-porting flurry (Kohei) AA: + on hold / proposal for closer 3.4.5 (?) next time (Petr) + 3.4.5 on schedule + freeze in 1 month * Security list (Michael) + set it up at freedesktop: populate with all our list members + add Dennis as the intermediate moderator etc. * QA update (Rainer) + problems with UI translations for Farsi / Arabian AA: + chase it down cf. bug#42388 (Andras) + bugzilla performance issues + error/search problems - post update + bug #41983# is tracking it + mingw build testing + three curious problems, expected fixed + kendy tracking down odd regressions AA: + point kendy at original bug numbers, and add to MingW most annoying bugs (Rainer) * Most annoying bug review (Rainer) ... * Hiding string helpers in random places (Michael) + previously avoided adding potential problems for later trading convenience for indefinite maintainability + with flag day coming - can change the tradeoff expand the UNO ABI more rapidly + ergo moving selected comphelper bits into sal/ * Windows build breakage / spamming (Caolan) AA: + connect to Fridrich's machine fix build failure (Michael) -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Eike, Michael, Thorsten, Stephan, Andras, Fridrich, Kendy, Tor, David, Norbert, Rainer, Michael S, Bjoern, Caolan, Petr * Completed Action Items + adding l10n code is currently done by pair of VB Scripts need to grok port these to a better tool. (Andras) + port it to perl instead + asked for a static URL for bug filing from Florian (Rainer) + pull together existing QA stats for Cor's research (Rainer) * Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dailies ... (Kendy) + unit test written for on-line updating + come up with a list of QA heros for next meeting [in progress] (Rainer) * Agenda items + pending action items + release mgmt bits (Petr) + 3.5.0 feature freeze reminder: Dec 5th + most annoying bugs in 3.5.x tracked here: https://bugs.freedesktop.org/show_bug.cgi?id=37361 + Radek working on shape import regression + 3.4.4 tagged on Tuesday, and RC1 builds up-loading to mirrors, announce tomorrow; on track. + Monday - deadline for RC2(/final) AA: + review Noel's OLE automation fix (Petr) + 3.3.x release + solitary calc crasher fix, and a branding issue = no new 3.3.x + install Liberation fonts on Windows (Caolan) + not needed since they're drop-in replacements for existing fonts + no harm in shipping it on Windows + why exactly is it necessary / some UI issue / bug ? + packaging is a nice thing to hide Win32 fallback bugs (Fridrich) AA: = package them (Fridrich) + feature/gtk3 merge aftermath (if any) (Michael) + fixed several nasties Stephan identified + nothing else rearing its head + QA update (Rainer) + http://wiki.documentfoundation.org/User:RBd/Workbench/Draft0#TSC_Call_2011-10-27 + added ver 3.4.4rc1 to bugzilla + QA team wiki page coming along + potential collaboration with Ubuntu QA team + can we switch bugzilla to new workflow status ? + legacy / needinfo consideration ongoing + easy hacks research / contributors: + can poll them to see what they'd like + consolidated easy hacks dissection (Bjoern) + using the words 'easy hack' less on the list due to bugzilla migration + how is the wiki page created (?) + auto-generated from a bugzilla feed = add a new easy hack - it appears in the wiki + manual intervention for new categories / skill-sets + how is the ordering generated ? + done by bugzilla id ? + selection of top-ten sample easy hacks, done manually + refreshed every ~two weeks AA: + do some rotation of easy-hacks top-ten (Bjoern) + adding easy hacks is easy and fun: http://wiki.documentfoundation.org/Development/Easy_Hacks_Bugzilla_Whiteboard_Status + how do we change the presentation ? AA: + ask wrt. hacking php to improve presentation (Bjoern) + mingw update (Mitch) + not here this week + Bjoern at UDS next week -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 10/21/2011 02:06 AM, Kevin Hunter wrote: At 4:52pm -0400 Thu, 20 Oct 2011, Michael Meeks wrote: http://wiki.documentfoundation.org/Development/LibreOffice4 + getting stuck into Windows / mingw build etc. From the wiki page, one of the concerns is binary incompatibility. I assume this is in reference to extensions? Question: is there merit to moving toward an enforced sub-process model for extensions? My first thought is that this would do a couple of things: [...] 5. That API definition will be a *lot* of work, but hopefully somewhat thought out already through only a mild reengineering of the current binary API. The UNO API is already there. Or what do you mean? [...] The upside is that if we're talking a major version change, /now/ would be the time to do this. A downside is that you would still need to maintain (and build!) the UNO runtime for the MSVC ABI. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi Kevin, On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote: From the wiki page, one of the concerns is binary incompatibility. I assume this is in reference to extensions? Sure; of course we only export a reasonably small ABI, the 'ure' (big chunks of which are in-lined C++ methods that call SAL_CALL C functions that we havn't changed and should cross-compile nicely). The C++ helper classes (it is hoped) due to windows direct linking, and a different ABI anyway shouldn't conflict. My hope was(is) that UNO can shine here (with some tweaks) as a bridging technology between the ABIs - at some fairly minimal performance cost. At least, given Stephan's expertise a little testing, it might just work. That would of course mean shipping some duplicate legacy MSVC++ compiled libraries, but ... surely do-able. Question: is there merit to moving toward an enforced sub-process model for extensions ? It is an interesting idea; of course in theory UNO makes this easy, in reality - I would scream and run away from cross-process component usage. Debugging reference leaks / cycles / etc. is bad enough in-process, never-mind cross-process; or worse between many (external) components. 3. It would allow extensions to still be built with MSVC, regardless of what compiler the LO core project uses. It may well solve this problem of course. My experience with the debuggability and lifecycle management of the Bonobo component model (which was heavily cross-process), was really an extremely negative one, and that on Linux with really fast IPC. Naturally, if people want to write their extensions that way, they can, currently I imagine the only related grief is prolly around deployment. If you're interested in it as a model, it would prolly be worth playing with the deployment of such extensions. But of course, I personally think there is much lower hanging fruit in the calc core ;-) ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
At 4:39am -0400 Fri, 21 Oct 2011, Michael Meeks wrote: [one /could/ work toward interprocess extensions ... ] But of course, I personally think there is much lower hanging fruit in the calc core ;-) Noted and agreed! I'm just sticking my nose in all things LO, probably stepping on toes as I do (sorry!). I was more posing the question that I wasn't aware had gone by. However, it sounds like y'all've already thought about that, or it's a everyone already knows this answer. Cheers, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
At 4:11am -0400 Fri, 21 Oct 2011, Stephan Bergmann wrote: On 10/21/2011 02:06 AM, Kevin Hunter wrote: 5. That API definition will be a *lot* of work, but hopefully somewhat thought out already through only a mild reengineering of the current binary API. The UNO API is already there. Or what do you mean? I was talking about an API that is not dependent on an ABI. But I freely admit I know very little about ABIs, so I may have just conflated that term. See below. The upside is that if we're talking a major version change, /now/ would be the time to do this. A downside is that you would still need to maintain (and build!) the UNO runtime for the MSVC ABI. This may be the crux of what I'm not getting, but why? Why can't a protocol be, say, text-based via (local, or other) socket? In my mind, I see two independent programs, from two different compilers, using the OS and something akin to pipes to communicate. I admit it might a smidgen slower to do it that way, but do people actually use LO in HPC scenarios? (And I fully accept that they might, I just haven't seen it yet in my various interactions.) Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 10/21/2011 11:08 AM, Kevin Hunter wrote: At 4:11am -0400 Fri, 21 Oct 2011, Stephan Bergmann wrote: On 10/21/2011 02:06 AM, Kevin Hunter wrote: 5. That API definition will be a *lot* of work, but hopefully somewhat thought out already through only a mild reengineering of the current binary API. The UNO API is already there. Or what do you mean? I was talking about an API that is not dependent on an ABI. But I freely admit I know very little about ABIs, so I may have just conflated that term. See below. The upside is that if we're talking a major version change, /now/ would be the time to do this. A downside is that you would still need to maintain (and build!) the UNO runtime for the MSVC ABI. This may be the crux of what I'm not getting, but why? Why can't a protocol be, say, text-based via (local, or other) socket? In my mind, I see two independent programs, from two different compilers, using the OS and something akin to pipes to communicate. I admit it might a smidgen slower to do it that way, but do people actually use LO in HPC scenarios? (And I fully accept that they might, I just haven't seen it yet in my various interactions.) That's all already there with UNO. Only, for any code to make use of that, it needs to talk with bridge code that handles the (intra- or inter-process) communication. That bridge code (which is necessarily ABI-specific) is also already there. The only thing is that, if you wanted to give up building LibO with MSVC and switch to MinGW, but wanted to retain the MSVC-specific bridge code (so that old extensions can continue to run, in- or out-of-processes), you could not give up building LibO with MSVC completely, because you would still need to build that bridge code with MSVC. Designing a new communication protocol would not buy you anything. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 10/21/2011 10:39 AM, Michael Meeks wrote: Hi Kevin, On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote: From the wiki page, one of the concerns is binary incompatibility. I assume this is in reference to extensions? Sure; of course we only export a reasonably small ABI, the 'ure' (big chunks of which are in-lined C++ methods that call SAL_CALL C functions that we havn't changed and should cross-compile nicely). The C++ helper classes (it is hoped) due to windows direct linking, and a different ABI anyway shouldn't conflict. My hope was(is) that UNO can shine here (with some tweaks) as a bridging technology between the ABIs - at some fairly minimal performance cost. At least, given Stephan's expertise a little testing, it might just work. That would of course mean shipping some duplicate legacy MSVC++ compiled libraries, but ... surely do-able. It would not suffice to ship them, one would also need to build them. Kind of back to square one. Question: is there merit to moving toward an enforced sub-process model for extensions ? It is an interesting idea; of course in theory UNO makes this easy, in reality - I would scream and run away from cross-process component usage. Debugging reference leaks / cycles / etc. is bad enough in-process, never-mind cross-process; or worse between many (external) components. Note that freshly installed extensions *are* routinely loaded off to an external uno process. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, 2011-10-21 at 14:51 +0200, Stephan Bergmann wrote: That would of course mean shipping some duplicate legacy MSVC++ compiled libraries, but ... surely do-able. It would not suffice to ship them, one would also need to build them. Kind of back to square one. For windows - shipping a pre-canned set of compiled compatibility libraries doesn't look too disgusting to me; at least - it seems a lot less disgusting than using MSVC++ and cygwin :-) tar xf ure-bincompat-win32-tgz is not in itself such a horrific outcome from a cross-compiled solution (assuming the build of that is well documented, should you happen to have lots of time and a proprietary system + compiler to do it). Clearly someone needs to build them once. HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On 10/21/2011 03:57 PM, Michael Meeks wrote: On Fri, 2011-10-21 at 14:51 +0200, Stephan Bergmann wrote: That would of course mean shipping some duplicate legacy MSVC++ compiled libraries, but ... surely do-able. It would not suffice to ship them, one would also need to build them. Kind of back to square one. For windows - shipping a pre-canned set of compiled compatibility libraries doesn't look too disgusting to me; at least - it seems a lot less disgusting than using MSVC++ and cygwin :-) tar xf ure-bincompat-win32-tgz is not in itself such a horrific outcome from a cross-compiled solution (assuming the build of that is well documented, should you happen to have lots of time and a proprietary system + compiler to do it). Clearly someone needs to build them once. There will invariably be situations were things in there will need to get fixed. And if that code is only built once in a year, it will bitrot and no longer build in a year from now. Been there with moz_prebuilt. No thanks. :) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Stephan, Petr, Michael, Andras, Mitch, Thorster, Rainer, Michael Stahl, Caolan, Tor, Kendy, Eike, Bjoern, Norbert * Completed Action Items + publicise our list of ODF proposals / extensions (Thorsten) http://wiki.documentfoundation.org/Development/ODF_Implementer_Notes + add potential removal of two-layer LibO to LibreOffice 4plan http://wiki.documentfoundation.org/Development/LibreOffice4 * Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dalies ... (Kendy) + adding l10n code is currently done by pair of VB Scripts need to grok port these to a better tool. (Andras) + default to Andras' new MSI building method and release-note when done (Andras) + come up with a list of QA heros for next meeting (Rainer) * Agenda items + pending action items + release mgmt bits (Petr) + 3.4.4 RC1 freeze on Monday - get things in fast. + 3.5.0 feature freeze Dec 5th + conference summary / round-up + Awesome. (Bjoern) + easy hacks dissection (Bjoern) AA: + do more analysis on Rainer's numbers (Bjoern) + about to merge feature/gtk3 (Michael) + compiles on Mac, and MingW without issues + poke me if you have concerns + Gerrit Migration: + http://wiki.documentfoundation.org/Development/GerritMigration + start on dev-tools repo as a test case + get people's accounts setup etc. + concerns wrt. removing visibility of patches on list (Caolan) + happy enough given custom tooling to integrate with list + tinderbox / security fun - suck and see. + no major objections = proceed. + QA update (Rainer) + check the 3.3.5 branch + most prolly no new release / no new QA load etc. + Bugzilla upgrade + many thanks to Tollef + have the 'UNCONFIRMED' state - by default + around 2k un-reviewed bugs, as 'NEW' needs to be UNCONFIRMED cf. legacy whiteboard status. + too much E-mail spam changing them + Bug submission assistant + no OS selection (can detect that) + used frequently, 40+ new reports + reports using assistant are viewed as higher quality + should we include this into the help menu for 3.5 ? + Rainer - yes AA: + needs a static / fixed URL from Florian (Rainer) + can always turn it off / make it different if problems. AA: + pull together existing QA stats for Cor's research (Rainer) + Mitch + getting stuck into Windows / mingw build etc. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
At 4:52pm -0400 Thu, 20 Oct 2011, Michael Meeks wrote: http://wiki.documentfoundation.org/Development/LibreOffice4 + getting stuck into Windows / mingw build etc. From the wiki page, one of the concerns is binary incompatibility. I assume this is in reference to extensions? Question: is there merit to moving toward an enforced sub-process model for extensions? My first thought is that this would do a couple of things: 1. This would protect LO from any extensions' instability. If an extension attempts an illegal operation, only it would be shut down, not whole of LO. 2. By only shutting down a buggy extension, we reduce potentially misleading bug reports from users who wouldn't otherwise know the difference. 3. It would allow extensions to still be built with MSVC, regardless of what compiler the LO core project uses. 4. Going forward, this would force a well-defined protocol interaction between LO and any extensions. This has implications for unit tests and security, among other things. 5. That API definition will be a *lot* of work, but hopefully somewhat thought out already through only a mild reengineering of the current binary API. 6. Interprocess communication for certain tasks will be potentially slower. 7. ... ? The upside is that if we're talking a major version change, /now/ would be the time to do this. Thoughts? Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
+ Present: + Thorsten, Andras, Michael M, Stephan, Tor, Rainer, Mitch, Norbert, Kendy, Michael S, Bjoern, Caolan, Petr + Completed + add ABI related re-factoring plans to wiki [ on going / indeterminate ] at: http://wiki.documentfoundation.org/Development/LibreOffice4 + update openSymbol with version gap checks (done by Julien Nabet) + hide virus/trojan warnings with XOR mangling for unit tests (Caolan) + add C++ cross-compile ABI change issue to release 4 wiki page (Kendy) + download page recommends stale version (Thorsten) + Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dalies ... (Kendy) + publicise our list of ODF proposals / extensions [ in progress] (Thorsten) * Agenda items + pending action items + Andras's new MSI packaging approach (Andras/Tor) + motivation - make Windows installer simpler + existing install process has two-three steps, pre-installer, setup.exe, MSI and is not localizeable + hack week: created multi-language single MSI for installation + why not use it before ? no MSI install at all before (Tor) + should not be an issue anymore + the setup.exe level - could pass params to setup installer + old switches can be mapped to std. msiexec switches AA: + add l10n improvements to 3.5 release notes (Andras) AA: + adding l10n code is currently done by pair of VB Scripts would need to grok port these to a better tool. (Andras) AA: + default to Andras' new MSI building method when this is documented (Andras) + release mgmt bits (Petr) + nothing much new happening, 3.4.4 RC1 freeze is one week after the conference + few more most annoying bugs to be looked at + looking forward to discussing 3.5 schedule at conference + introduction (Michael Stahl) + at Sun/Oracle for four years, part of writer + framework team + experience of RDF meta-data (not in such a useful state yet sadly - no copy/paste support of that), writer undo/redo, removed old/obsolete/duplicated stuff, document properties re-implementation, redland module, lots of bug fixes, gbuild on OS/X + Solaris etc. + great to have Michael on board at RedHat, plan to poke at the area of change-tracking, and other issues in writer. + ESC composition - update it in Paris ? + QA update (Rainer) + business as usual + concern wrt. lots of bugs untouched for months 2.3k waiting for review + bug report assistant + few issues being kindly unwound by Loic + but getting more reports since it was created + missing operating-system detection, + way better overall for end users. + need better co-ordination with the ~10 active QA guys. AA: + come up with a list of QA heros for next meeting (Rainer) + gbuild multi-repo support (Bjoern) + quests through every source root for object files + avoiding symlinks etc. + obsolete and potentially already broken, remove it ? + general agreement AA: + add potential removal of two-layer LibO to plan (Bjoern) http://wiki.documentfoundation.org/Development/LibreOffice4 -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Norbert, Thorsten, Michael, Stephan, Andras, David, Rainer, Mitch, Bjoern, Caolan + Completed Action Items + spec. for beefier gerrit machine - sysadmin team (Bjoern) + Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA for dailies ... (Kendy) + publicise / aggregate our list of ODF proposals / extensions (Thorsten) + update openSymbol with version gap checks (Julien Nabet cf. Caolan) * Agenda items + pending action items + cppunittest code sharing - new TestFixture in vcl ? (Michael) + done in 'test' split to 'unotest' + virus trojan warnings in source code [CVE docs] (Caolan) AA: + plan is to add a magic XOR mangling for unit tests now the code is shared, to hide the issue (Caolan) + enabling -Werror automatically for some people (Michael) + pretty difficult in gcc world to turn on -Werror sensibly, distros back-porting patches are an issue, triplet version number is not reliable / helpful (Caolan) + have it enabled on build-bots if a known-good compiler (Caolan) + if can build with on, then should build with it on (Bjoern) + stick with status quo, -Werror is a good thing if it works, but users need to fix others' warnings + per shlib forward definition headers (Michael) + using include what you need is the best first step. + Lanedo / Win32 project (Mitch) + plan is to start after the conference + cross-compiled msi building + C++ ABI issues MS VC++ vs. gcc + plan to switch this for production code at flag-day for 4.0 AA: + add details to the release 4 wiki page (Kendy) + current status (Kendy) + mingw tinderbox cross-compiler, working mailing people + binaries run under wine - 50% of status bar ... + debugging with VStudio debugger: needs a VS extension that de-mangles dwarf + winedbg support: can linkoo the build, re-compile and run directly as on Linux + from clean build - instsetoo_native: 12 minutes for a Windows build (on big Linux H/W) + ABI / API break (Norbert) + copy Mozilla ? un-froze the whole API fixed up incrementally (Caolan) + talk at the conference about it (Michael) + concern that we capture all ABI breakage to do for 4.0 AA: + please do that incrementally in the wiki: (Everyone) http://wiki.documentfoundation.org/Development/LibreOffice4 + no release bits (Petr on vacation) + QA update (Rainer) + Bugzilla Bug Submission Assistant + beautiful scripting magic from Loic (with thanks) http://www.libreoffice.org/get-help/bug/ + Kendy already patched to re-order icons, code in website/bug/ + Solaris Unix Support + porters / hackers belong on the developers list, otherwise, 'discuss' is fine + OpenIndiana guys have done some work here + Gerrit + seems to require raw access control of the git server + concerns of merge / pushing ... + Fun updates + cudos to Tor / Fridrich / Kendy / Norbert / Bjoern etc. for cross-build goodness (Thorsten) + Bjoern + upgrading his hardware, will setup another PC tinderbox + Pandabord looking fun - might get an ARM tinderbox with a build-per-week or somesuch + Michael + re-factoring vcl to remove X dependency from headless mode, should allow cross-platform smoke-tests during build -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, Sep 23, 2011 at 5:16 AM, Jan Holesovsky ke...@suse.cz wrote: Hi Cor, Cor Nouws píše v Út 13. 09. 2011 v 00:26 +0200: + Release mgmt (Petr) + concern wrt. bugs in master - need some focus there + no more releases until after the conference A pity since 3.4.3 has at least one nasty regression. Regression against 3.4.2? Bug no.? I believe : https://bugs.freedesktop.org/show_bug.cgi?id=37579 Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Norbert, Rainer, Michael, Mitch, Andras, Cedric, Thorsten, David, Bjoern, Petr, Kohei + Completed Action Items + write substance of what is needed wrt. the extensions templates announce send to Florian (Andreas) + New extensions website: publish / tdf blog (Florian) + give website / commit rights out more diversly (Kohei) + mail details for new repo setup (for libtextcat) to Michael (Caolan) + Pending Action Items + create top-level libtextcat repo (Michael) + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA for dailies ... (Kendy) + publicise / aggregate our list of ODF proposals / extensions (Thorsten) * Agenda items + pending action items + Calc row height / font metric change (Eike) + Eike on holiday - postponed to the conference. + openSUSE conf update (Michael) AA: + get Jan's gcc cutting down script (Michael) + Lightning talk brainstorming ... (Michael) + python / debugging annotations (David Tardon) + finding code from the user-interface ? (Kendy) + removing unused code (Caolan) + low hanging UNO performance wins (Thorsten) + interacting with new developer (Michael) + howto setup a tinderbox (Norbert) + running subsequent tests (Bergmann) + how to troll on IRC (Fridrich) + how to find out what is going on (for beginners) (Bjoern) + debugging gnumake effectively (Norbert) + opening visio documents (Fridrich) + writing good commit messages (Petr Mladek) + release bits (Petr) + Cor's regression bug fdo#40590 + came from merging a CWS calc-showstopper + regression vs. 3.3, fixed in 3.5 + most people working on master + no more fixes for 3.3 committed so no new release planned + Documenting Extension guarentees (Stephan) + currently no written rules on guarentees for extension developers. Can create problems for both them and us. + cf. unoapi.dll query this morning + 2-3 things: + clear story - do we want compat across versions: major, minor, micro, etc. + getting ext'n devs involved in the process + and/or monitor / survey ext'ns closely + problems monitoring non-open-source ext'ns (Norbert) + have snippets for regression testing from ext'n devs (Thorsten) + best sol'n for compat with ext'ns on Windows: re-use stlport solution, distribute 3.4 sal, but not link to it (Fridrich) + address on an ad-hoc basis, or be explicit ? (Stephan) + writing rules not a very good approach (Michael, Norbert) + discuss whether we want C++ components in 4.0+ (Michael) + at conference - find who is using it, and why ? (Bjoern) + defer to discussion in/post Stephan's talk at LibOCon. + QA update (Rainer) + nothing exciting to report + bug reporting assistant going well https://bugassistant.libreoffice.org/libreoffice/bug/bug.html + can provide version + component from Help-File bug + Lior moving javascript to 'website' git module ... + filing bugs vs. master - is it a good idea + regression bugs should be sent as E-mail to dev list (Fridrich) + closing lingering bugs a problem otherwise (Bjoern) * Agreed - regression bugs in master vs. last-stable should be sent to list with [regression] subject. + when to run tests (Bjoern) + how to reduce unit test time taken in incremental developer builds AA: + discuss this next time -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (08-09-11 17:28) + Release mgmt (Petr) + concern wrt. bugs in master - need some focus there + no more releases until after the conference A pity since 3.4.3 has at least one nasty regression. -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Norbert, David, Stephan, Cedric, Thorsten, Andras, Bjoern, Rainer, Michael, Kohei, Caolan + Completed Action Items + get Bjoern setup with a vhost for gerrit (Thorsten / Christian) + playground already constructed / public: at https://gerrit-test.libreoffice.org + close bug-voting with wontfix + rational (Rainer) + in-progress: get bugzilla query wrt. master regressions to Michael (Rainer) + check and enable new RTF import in master by default (Cedric) + fixup qa list configuration (Thorsten) + send Loic some ideas / design / interface work for bug filing (Michael) + Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA for dailies ... (Kendy) + write substance of what is needed wrt. the extensions templates announce send to Florian (Andreas) + New extensions website: publish / tdf blog (Florian) + publicise / aggregate our list of ODF proposals / extensions (Thorsten) * Agenda items + pending action items + Munich hack-fest report / roundup (Thorsten) + hack-fest page achivements: http://wiki.documentfoundation.org/Hackfest2011#Achievements + wonderful, friendly, social atmosphere + too many people to fit in the room (30+) + several companies represented + Munich Gov't + patches from new contributors, some adding to their existing translating / documentation skills. + great infrastructure provision - icecream / server + some good UI designer - hacker interactions + hope for hosting an identical event next year + Many thanks to: The City of Munich + DBI GmbH + bus factor issues wrt. scattered projects ... + concern Fridrich + Kohei hit by a bus their external projects. AA: + mail details for new repo setup (for libtextcat) to Michael (Caolan) + benefits of controlling review (Kohei) + also of branding separation (Kohei) + problems of fixing: commit, release, up-load, etc. (Michael) + concern mostly around maintainership handover (Caolan) AA: + give mdds website / commit rights out more diversly (Kohei) + Cor's considerations on release timing + existing schedule is here: http://wiki.documentfoundation.org/ReleasePlan#3.5_release + very vague, lots of factors and no data / heuristics (Thorsten) + could try a slushy feature-freeze on master around an earlier release with new features (Norbert) + some new features have good QA coupling with their own builds eg. Jean Baptiste (Cedric) + lots of reasons already provided why next time would be better quality-wise than last time (Michael) + not too late to discuss at the conference and move freeze dates by a week or two (Norbert) + always a trade-off between quality, community fun, pace of development (Michael) + (default) internal gnumake re-hash ... (Michael) + having bootstrap make build is painful (Norbert) + not having it on the default path reduces usage (Michael) + on Linux performance gain not justified (Bjoern) + on Windows - there are big wins - fewer deps (Bjoern) + why not add it for windows-only ? (Bjoern) + have a binary that we just download (Thorsten) + dangers of having a fork of the build-tool (Thorsten) + slow in standard make - fix: get it up-stream (Stephan) + complexity added into the core breaks the idea of having a 'pure' configure / make in future (Norbert) + risk of depending on and maintaining a new custom 'make', combined with concern about continuing to require bootstrap, is more significant than -any- magnitude of developer productivity hit for new developers too unaware / lazy to download custom tools. (Bjoern, Stephan, Norbert) + unreliable vs reliable, slow vs. fast tests (Stephan) + subsequenttests - not ideal, but lots of them + problem: they require a complete LibreOffice install + problem: they connect via UNO = poor error reporting debugging + some rare / intermittent issues running tests crashes during shutdown + discovered a number of bugs regressions cleaning them up so they
Re: [Libreoffice] minutes of tech. steering call ...
On Thu, 2011-09-08 at 16:28 +0100, Michael Meeks wrote: AA: + give mdds website / commit rights out more diversly (Kohei) This is already done. Now Caolan and David should have the same rights as I do. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi Cor, On Tue, 2011-09-06 at 07:16 +0200, Cor Nouws wrote: So thanks for putting this at the agenda. (But of course note that it is not stated fully correct.) As you have seen, I posted some overview on the subject to the list two days ago I didn't see that, any chance of a re-send; if you give enough details no doubt we can discuss it ourselves, though that is less satisfying of course. I'll be glad to join a talk about this. Only problem: needs to be somewhere: .. - For the weeks towards mid October about the same schedule. By mid-October we can meet at the LibreOffice conference perhaps ? :-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (06-09-11 17:56) As you have seen, I posted some overview on the subject to the list two days ago I didn't see that, (no wonder, it was a Sunday evening ;-) ) any chance of a re-send; if you give enough details no doubt we can discuss it ourselves, though that is less satisfying of course. Obvious. I'll resend it. I'll be glad to join a talk about this. Only problem: needs to be somewhere: .. - For the weeks towards mid October about the same schedule. By mid-October we can meet at the LibreOffice conference perhaps ? :-) I'll try to. But it is too late for a fair look at the question. (As explained before more then once: if the discussion leads to the conclusion that a bit earlier start with beta release is wise, it is not fair to say that only few weeks before that time. Devs will be disturbed!) Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (01-09-11 16:55) * Agenda items + request to move 3.5.x feature-freeze forward (Cor) So thanks for putting this at the agenda. (But of course note that it is not stated fully correct.) As you have seen, I posted some overview on the subject to the list two days ago . I'll be glad to join a talk about this. Only problem: needs to be somewhere: - next Saturday or Sunday between 7 and 11 AM (UTC) or after 18 PM - or the week thereafter can try one of the evenings after 18 PM UTC - maybe there is some time on Friday during the day in one of the next weeks, but that is difficult to say earlier than one day in advance - For the weeks towards mid October about the same schedule. Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: + Norbert, Andras, Bjoern, Petr, Kendy, Caolan, Rainer, Stephan, Kohei, Michael + Finished Action Items + in-progress: setup gerrit a test repo (Bjoern) + in-progress: disable .po file editing hook: only to be used in translations (Norbert) + add Thorsten as qa list co-administator (Rainer) + come up with a new 3.4 / 3.3 schedule with dropped / less frequent monthly release (Petr) + check and enable new RTF import in master by default (Cedric) + Pending Action Items + at hackfest: get Bjoern setup with a vhost for gerrit (Thorsten / Christian) + in-progress: get bugzilla query wrt. master regressions to Michael (Rainer) + New extensions website: publish / tdf blog (Florian) + enable on-line updates for QA for dailies ... (Kendy) + non-TDF branding technical question(s) (Thorsten) + close bug-voting (no) wontfix with rational (Rainer) + fixup qa list configuration (Thorsten) + write substance of what is needed wrt. the extensions templates announce send to Florian (Andreas) * Agenda items + pending action items + request to move 3.5.x feature-freeze forward (Cor) + still not available + ODF / standards work file-format patches / flow (Michael) + review xmloff patches carefully to get sane XML in our namespaces + forward as formal proposals to the ODF TC via Thorsten + we should not block progress on this AA: + publicise / aggregate our list of proposals / extensions (Thorsten) + Release mgmt (Petr) + 3.4.3 status + released, looks good. + discuss Petr's new schedule + reducing stable release frequency as we move in updated schedule published: + have a TSC decision point for skipping 3.3.5 if there are no changes worth releaseing + QA update (Rainer) + 3.4.3 works as expected - no show stoppers + intermittent win32 only dictionary loss in 3.4.3 (#37195) + Caolan has heroically fixed it (probably) + bug filing interface (Loic working on it) AA: + need more ideas / design / interface input (Michael) + next bug hunting session - next Tuesday + http://wiki.documentfoundation.org/QA/IRCSessions#Monthly_Bug_Hunting_Sessions + Oracle / OO.o extensions repo is flaky + need to accelerate move to the new extensions repo + Stephan welcome / introduction -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Thu, 2011-08-25 at 18:05 +0100, Michael Meeks wrote: + intermittent(?) dictionary loss in 3.4.3 + https://bugs.freedesktop.org/show_bug.cgi?id=37195 + most annoying for testers: + who do a lots of upgrades etc. I read through it, I despaired. Lots of heat and noise, but ideally what's needed is a concise how to reproduce from scratch, and clarification if it actually affects Linux. I had much better luck with http://bugs.freedesktop.org/show_bug.cgi?id=36678 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
2011/8/26 Caolán McNamara caol...@redhat.com: On Thu, 2011-08-25 at 18:05 +0100, Michael Meeks wrote: + intermittent(?) dictionary loss in 3.4.3 + https://bugs.freedesktop.org/show_bug.cgi?id=37195 + most annoying for testers: + who do a lots of upgrades etc. I read through it, I despaired. Lots of heat and noise, but ideally what's needed is a concise how to reproduce from scratch, and clarification if it actually affects Linux. wope reproduced it under openSUSE 11.4, see https://bugs.freedesktop.org/show_bug.cgi?id=37195#c32 I think the key is the configmgr.ini, see https://bugs.freedesktop.org/show_bug.cgi?id=37195#c24 So the bug seems to be that 'configmgr.ini' in the user profile isn't updated. (when someone upgrades from one version to another of the 3.4 series.) Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2011-08-26 at 11:59 +0200, Andras Timar wrote: wope reproduced it under openSUSE 11.4, see https://bugs.freedesktop.org/show_bug.cgi?id=37195#c32 I don't ask why patients lie, I just assume they all do. :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2011-08-26 at 11:14 +0100, Caolán McNamara wrote: On Fri, 2011-08-26 at 11:59 +0200, Andras Timar wrote: wope reproduced it under openSUSE 11.4, see https://bugs.freedesktop.org/show_bug.cgi?id=37195#c32 I don't ask why patients lie, I just assume they all do. :-) My working theory at the moment is that while we are packaging the migrationoo2 and migrationoo3 components we are only registering the migrationoo2 component in packcomponents, which suggests that migrations might not be happening correctly. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech steering call ...
* Present: + Norbert, David, Rainer, Bjoern, Kendy, Kohei, Caolan, Petr, Cedric, Lubos, Michael, Mitch + Completed Action Items: + get SmartArt interop. feature into master (Thorsten) + easy hacks - completion / fixing (Bjoern) + looks pretty: eg. http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill + submit conference papers: + Cedric + GSOC update - double-slot + what's next in writer + enable Kendy's Windows tinderbox again (Kendy) + ~done, master builds there nicely again + gnumake fallout still causing fun + promulgate pencil down dates (Cedric) + fix bogus / obsolete download DNS record (Thorsten) + moved the source tarballs to a better place. + Pending Action Items: + mail bugzilla query wrt. regression to dev list (Michael) + in-progress: script that downloads the git sources for you (Norbert) + submit conference paper: onegit / tinderbox (Norbert) + enable on-line updates for QA for dailies ... (Kendy) + dig up the SFLC AL2/LGPLv3+ header (Michael) + New extensions website: publish / tdf blog (Thorsten) + non-TDF branding technical question(s) (Thorsten) * Agenda items + pending action items + ccache fun (Lubos) + enabled by default, unless --enable-symbols ? + can we get the cache size and adapt to that ? AA: + decided: check for size of cache at configure default, 1Gb ok unless --enable-symbols, then 5Gb (Norbert) + gerrit update / demo (Bjoern / Norbert) + impressive piece of software + basically a web front-end to setup a git branch + log-in / no account required: openID + up-load ssh key to web interface + after that everything is do-able from the command-line + with e-mail notifications + workflow: + each newbie push to the gerrit git branch is to a review queue + buildbots can run vs. that branch + submitters can push to proposal queue of gerrit. + as easy as ML if not easier + lots of things for us, are possible ... + patch submit flow - web/up-load to gerrit + cherry-pick by reviewer / close web interface. + Jenkins integration possible + builds can be triggered via git (hence gerrit) commits AA: + get Bjoern setup with a vhost for gerrit (Thorsten / Christian) AA: + setup a gerrit test repo (Bjoern) + needs a nice MPL/LGPLv3+ 'ack' as we create an account. + git commit hook over-complexity (Norbert) + removed doxygen check for now (over-complicated) + only checking for whitespace currently. + .po file commit editing on the fly AA: - dangerous /should only be in translations if at all (Timar) + bug fixes - most annoying for 3.4.x + bikesheding ... endless thread, wait for concreteness. + gutting openssl for NSS wherever it is found is ok ? + agreed ! + ideal work - easiest starter to fix is OOXML import encryption AA: + poke Marc (Michael) + update template for (C) headers ... [Thorsten] - add conflict markers and good. + GSOC update (Cedric) + coding almost done (by end of week) + ensure all students have pushed their code to master is building + evaluation to be done from 22nd - 26th. + Aug 25th + update your T-shirt size address, or look silly ! + Matus - nice gnumake / acceleration misc. pieces + Xisco - python ported from java - going nicely, merging soon + Tibby - Visio stuff looking very sweet indeed + Miklos - nice RTF import filter in master, beautiful work + will enable filter as default bin old filter when flyframes are done copy+paste tested + nightmares with importing into existing doc with styles (the paste file-insert cases) AA: + check and enable new RTF import in master by default (Cedric) + Marco - lovely SVG export for impress, nearly better than flash + Timo - useful wikihelp to windows help conversion work + Anurag - lots of nasty issues with input bar, task
[Libreoffice] minutes of tech steering call ...
Present: + Norbert, Mitch, David, Kendy, Andras, Michael, Caolan, Rainer, Bjoern, Fridrich, Petr * Completed Action Items + implementing vertical text with Cairo (Caolan) + manual / wiki page for using nightlies (Rainer) + windows snapshot builds are really old (Fridrich) + kicking it again + lots of dependency problems - switch to single CPU build + Submit the suggested papers ... (All) + Caolan + Writer internals cf. FOSDEM ? (with Cedric) + Security / testing infrastructure / work + Bjoern + gbuild - why / how / get involved + ask Matus to look into gnumake4 CWS ... (Michael) + gnumake4 CWS merge to master (Bjoern) + builds runs nicely + subsequenttests not looking so good + incremental builds should be faster + read the gettext patch again (Michael) + looks good, no explanation for flakiness, perhaps threads ? + have a look at header wrap bug: 39155 (Kendy) + behavioural change for compat, requires more thought * Pending Action Items: + review Norbert's updated C app (Kendy, Tor) + mail bugzilla query wrt. regression to dev list (Caolan) + easy hacks - completion / fixing (Bjoern) + in-progress: get SmartArt into master feature (Thorsten) + in-progress: create QA mailing list (Rainer) + conference papers: + http://conference.libreoffice.org/submit-your-paper/ + Michael + meet the ESC panel ... + status report for the last year's work ? + Mitch + feedback from a new C++ extension author + Francois + making LibreOffice easier to port + Cedric + GSOC update - double-slot + what's next in writer + Norbert: + onegit / tinderbox + enable on-line updates for QA for dailies ... (Kendy) + create / re-use wiki page how to contact other teams for more complex features proposals (Petr) + go through the not-yet-fixed Most Annoying 3.4 bugs, and see how many of them are / are not in 3.3.x already (Rainer) * misc technical / process decisions + one git migration timeline / plans (Norbert) + http://wiki.documentfoundation.org/Development/One_Git_Conversion#planning + update will happen Monday: 3 weeks from now + August 8th - a new git repo to clone ... + Python 3 support + cf. list discussion: prefered method to ship internal python3 on mac. + QA test vector / input for calc / mdds update (Kohei) + matrix formulae need heavy testing for 3.4.2(rc2) if possible + mdds migrated to git to allow branching in future + developer / build instructions: pointing at the wiki ? ... (Norbert) AA: + clarify the instructions to point more at the wiki (Norbert) AA: + get Norbert access for the developer web-page / CMS (Michael) * Releng bits (Petr) + 3.4.2 status + tag for rc2 on Tuesday, builds are being up-loaded, on pre-release http server. AA: + pre-announce for QA (Petr) + plenty more scope for fixing bugs in 3.4.3 (due in ~one month) + 3.3.4 schedule error being fixed: moving closer in. + 3.5.x schedule reminder + four months or less until feature freeze * QA update (Rainer) AA: + release notes for 3.4.2 rc1 39277 - (Petr) + more users starting to help out with bugs (much appreciated) + situation / backlog improving + encouraging growth progress in QA + don't know how many of the Most Annoying are new in 3.4 + perhaps the most interesting piece of data + http://wiki.documentfoundation.org/RBd/Workbench/Recommend_Upgrade_from_3.3.3_to_3.4.2 + difficult to get a clear view + categories sampling to detect regressions or not ? + prefer to use the most annoying as a proxy. * Questions ? -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
(I would also suggest release on Thursday so that feedback from the second week-end have a chance to be fixed before the next release) Marketing wise, release on Thursday is risky, because one day later (what happens) makes it Friday.. The important release, marketing wise, is the Final one. The final one is typically a RC that has not seen any serious problem. so, the rational to delay release to Thursday (allow time for week-end bug to be fixed) must be moot for that last cycle. The decision to promote a RC to Final can therefore still be done on Monday and the release still be on Wednesday... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
Present: Andras, Michael, Mitch, Rainer, Caolan, Rene, Petr, Francois, Cedric, Bjoern * Completed action items + review Norbert's updated C app (Kendy, Tor) * Pending Action Items: + Easy Hacks - completion / fixing (Bjoern) + in-progress: get SmartArt into master feature (Thorsten) + in-progress: manual for nightlies (Rainer) * in-progress: implementing vertical text with Cairo (Caolan) * download: split the m5 and filename (Caolan) * in-progress: add daily-builds related ideas to wiki (Rainer) * better cleanup rules on the server * on-line updates for QA for dailies AA: + windows snapshot builds are really old (Fridrich) * Review Action Items * conference paper submission brainstorming (Michael) + http://conference.libreoffice.org/submit-your-paper/ + Andras: + l10n panel / BoF + Michael + meet the ESC panel ... + status report for the last year's work ? + Mitch + feedback from a new C++ extension author + Caolan + Writer internals cf. FOSDEM ? (with Cedric) + Security / testing infrastructure / work + Francois + making LibreOffice easier to port + Cedric + GSOC update - double-slot + what's next in writer + Norbert + onegit and threading fun [ in absentia ] + Bjoern + gbuild - why / how / get involved AA: Submit the papers ... (All) * misc technical / process decisions * one git migration timeline / plans (deferred to next time) * translation code update (Andras) + dgettext code + random corruption in other strings (oddly) + no apparent pattern to them ? + fprintfs of gettext strings on the console AA: + read the patch again (Michael, Bjoern) + binary translation file translation prototype under way, strings work so far. + may be a good alternative + resource comparison + size of the .mo file ~= the .res file + seek time increase + optional gettext translation code-path is good to keep (Bjoern) + consensus: do both ... + 1/3rd of the translated strings are in XML * library merging plan / progress (Michael / Matus) + post tail_build re-merging + issues with different link routes + linking time concerns a potential issue + broadly ok with the idea * gnumake4 CWS merging + area sterilised by Bjoern's lock + work is re-based into: feature/gnumake4 + building, but not running ... + most likely component registration AA: + ask Matus to look into that ... * enable on-line updates for QA for dailies ... (Kendy) + next time. * Releng bits (Petr) + deadline for 3.4.2 RC1 * is Monday * + lots of fixes included + would be great to fix more of the most annoying issues + 3.4.1 release + delayed by 2 days + no un-expected regressions post rc2 * QA update (Rainer) + a 'dataloss' keyword for the whiteboard ? + OOX filters still a work in progress + any alien export can loose data + crashes can loose data + is there a need for a keyword ? + helpful way to capture severity. + working on better metrics for enterprise quality + un-triaged QA bugs count still high + marketing / banner to attracts QA engs planned for Aug -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Norbert, all, (sorry for the delay, but of course we all have our mail archives in order ;-) ) Norbert Thiebaud wrote (26-06-11 00:59) On Sat, Jun 25, 2011 at 4:52 PM, Cor Nouwsoo...@nouenoff.nl wrote: The more QA, people, the faster it goes, of course. But that is another matter. And of course, QA has to be a continuous state. So a possible longer time from freeze to release, would IMO not mean that we advise people to start later with testing :-) Then the question is How would 'freezing' improve that (motivate poeple to do early testing) Not earlier compared to the moment of freezing. But earlier compared to the moment of releasing. Thus more time available for that specific testing. Ok, let me try to reformulate the problem: Formal testing of a Beta/Rc require an large amount of work just to regression test things... A lot of these tests are not expected to yield bug, especially after the first Beta (that is, regression would be mostly found at that point, and hopefully very few would be introduced by subsequent fixes) So a test window of 1 week, will be use mostly doing that and not as much used to discover new bugs and test new function exhaustively. Hence the proposal become: make the release rate of Beta/RC slower. and 5 beta/RC at two week interval would yield better result than 10 Beta/RC at one week interval. Do I get that right ? Hmm, that is indeed an interesting and important extending of my comments. My comment simply is: when you have not enough people to do the QA-work in n weeks, make sure you have 2*n weeks (by releasing first beta earlier, not by releasing final later). What you write is extremely important too: if you need more than one week to do a lot of release tests, a new beta in just one week is not useful. (Even worse, it will frustrate testing.) If that is indeed the crux of the argument, then I would suggest: Expand the time between Beta/RC to two weeks (maybe 3 for the first beta?) When I look at: http://wiki.documentfoundation.org/ReleasePlan/3.5 indeed there are 5 time frames of one week (\ Xmas). So a first frame of 3 weeks, 2nd and 3rd of 2 weeks and then two of one week, looks much better. Maybe the same is valuable for the RC too: allow two weeks for the first cycle. Both for Beta and RC this larger first period is important too, since both with Beta and RC new groups of users (i.e. testers) will get involved. And setting the new environment up the first time, just takes longer. But hey, we still did not even sum up the criteria that we need to decide what we have to do to play a rather safe game this time. (I would also suggest release on Thursday so that feedback from the second week-end have a chance to be fixed before the next release) Marketing wise, release on Thursday is risky, because one day later (what happens) makes it Friday.. But then, QA still need to use Daily Build, as much as possible, during the period to confirm that bugs found in the current Beta/RC are indeed fixed to satisfaction _before_ the next Beta/RC comes out. In other words, use a continuous QA process on top of a formal Release-Based QA, to limit the number of formal Release-QA while maintaining a good pace of fixing... Fully agree. Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Norbert Thiebaud wrote (26-06-11 01:16) On Sat, Jun 25, 2011 at 4:52 PM, Cor Nouwsoo...@nouenoff.nl wrote: Therefore I argue that it would not be fair to decide on 7 weeks from the deadline, that it is shortened by 3 or 4 weeks. Sure, but delaying the Release Date by 3 or 4 weeks will not be fair to downstream either Indeed. Therefore, if we decide that we need some more QA time between Hard feature freezed branched libreoffice-3-5 (and I expect that we will come to that conclusion), then that time must be picked in front, and in time. The calendar was worked out by picking a Release date that would work for downstream - RedHat, Canonical, Suse,... - and then working our way backward to a 'freeze date'. the consequence of a major downstream not being able to pick-up a release of ours is much more important, in my opinion, than a given feature being pushed to the next release. Fully agree. Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Michael, Michael Meeks wrote (27-06-11 12:47) On Sat, 2011-06-25 at 23:52 +0200, Cor Nouws wrote: And indeed, I see no reason why that would be a natural thing happening. If there is a moment that we know: QA on this build is important, do this ... that will help focussing :-) So :-) now is this moment. It is important to have QA guys running the daily builds for their day-to-day work / use-cases :-) I think this is the basic problem, a lack of communication around what is good to be testing, and a lack of willingness to test 'master' ( because it is too buggy ;-) combined with a hope that master gets less buggy as/when we release it. How much I agree with 'important' 'good' etc. we do not have a can of QA guys that we can take from the shelves to do the work.. Many people working on QA do it besides other responsibilities, normal work, etc. Also: starting working/testing with a new version (daily build) takes time to install, set your preferences, etc etc. So that is for many people a reason not to jump on new versions every day, I guess. (Happily, I can confess that daily's / master builds are pretty OK to do your work with, so I support the ongoing effort to encourage people to pick those builds.) Anyhow - there are various psychological ways we can approach this, by having a different timetable for the QA team, that has a label marked feature freeze (ONO) - whatever it is that triggers you guys starting to do the QA, at a given date, and then the coder's feature freeze a bit later ;-) We can put the prefixes 'soft' and 'hard' on this to make it a bit clearer even if we want. Well, given the voluntary nature of much QA work, we have to take the tension-bow into account (no idea if that is English, but must be understandable somehow). I.e.: we cannot expect the average QA-enthusiastic to put a lot of energy in it for weeks and weeks continuously on a high level. Plus that there must be a large group, on a bit more distance, that has the attitude to start testing at the moment that the inner group is expected to be close to ready. For those reasons each special milestone is important as encouragement: ah, now I really 'must' jump in. Therefore Beta's and RC's will get much much more attention and testers. Hmm, I can hardly imagine that I write anything new here :-) Only to emphasize that it is not so wise to assume that QA activity will increase solely by us finding it important (and declaring that..) Anyhow - I assume you didn't submit the talk, since Drew was pointing out the lack of papers, so I've just done that ;-) As written: it is not at all sure that I'll be able to attend, so submitting a 'talk' that others would have to give... No I didn't. [snip] Title: Improving the Development / QA cycle Short Summary: A panel discussing how to better integrate the QA / Development cycle, timelines, freezes and all Abstract: Many proposals to improve quality of the product have been made, some of these revolve around scheduling and timing. Come hear a discussion about our current release process, how it works what 'time based' really means, and the impact that needs to have on our process. And hear about what can be done to improve it from various perspectives. I'd like to have: Cor Nouws, Rainer, Caolan, myself, Norbert, Petr Mladek, and a few more QA'ish types of our selection :-) [/snip] Looks important enough. So an extra argument for me to try to be there too :-) But as explained before: deciding halfway October that time before freeze is shortened from 7 to 3 or 4 weeks, is not going to make people happy. So I insist on a sound, rational weighing of factors that influence the change that we need more time to do a sound QA in order to release a good 3.5.0. - I think we all know the importance of that. Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On 20/06/2011 Michael Meeks wrote: We need people who in addition to coping with the tedium of reacting to the security issues, providing fixes and testing them on older branches - also like to write them up. This is an important factor for people considering to upgrade their current LibreOffice installation Sure - so - there is certainly a space to do this sort of thing in the security team if you want to get stuck in ? and of course, we can't use usual means for this - the bugs / patches are not tracked in bugzilla etc. so it needs some manual effort. If I can help with anything here please count me in: I would be mostly concerned with properly informing end users about security issues and communicating them to projects that share the same code base. Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Cor, On Sat, 2011-06-25 at 23:52 +0200, Cor Nouws wrote: And indeed, I see no reason why that would be a natural thing happening. If there is a moment that we know: QA on this build is important, do this ... that will help focussing :-) So :-) now is this moment. It is important to have QA guys running the daily builds for their day-to-day work / use-cases :-) I think this is the basic problem, a lack of communication around what is good to be testing, and a lack of willingness to test 'master' ( because it is too buggy ;-) combined with a hope that master gets less buggy as/when we release it. Anyhow - there are various psychological ways we can approach this, by having a different timetable for the QA team, that has a label marked feature freeze (ONO) - whatever it is that triggers you guys starting to do the QA, at a given date, and then the coder's feature freeze a bit later ;-) We can put the prefixes 'soft' and 'hard' on this to make it a bit clearer even if we want. Anyhow - I assume you didn't submit the talk, since Drew was pointing out the lack of papers, so I've just done that ;-) [snip] Title: Improving the Development / QA cycle Short Summary: A panel discussing how to better integrate the QA / Development cycle, timelines, freezes and all Abstract: Many proposals to improve quality of the product have been made, some of these revolve around scheduling and timing. Come hear a discussion about our current release process, how it works what 'time based' really means, and the impact that needs to have on our process. And hear about what can be done to improve it from various perspectives. I'd like to have: Cor Nouws, Rainer, Caolan, myself, Norbert, Petr Mladek, and a few more QA'ish types of our selection :-) [/snip] ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Cor Nouws píše v Pá 24. 06. 2011 v 08:43 +0200: plino wrote (24-06-11 02:03) BTW since only Betas can be installed in parallel with the stable build under Windows and that was not added to the 3.4.x branch (at least from my understanding) I guess Windows Beta testers will have to wait for 3.5.x, right? Well, I don't see any betas coming for the 3.4.x branch, so whether is has been added or not, does not make sense. I only can point to my favourite page: http://wiki.documentfoundation.org/Installing_in_parallel It is well recommended to use daily builds from http://dev-builds.libreoffice.org/daily/. They include the very last fixes and can be installed in parallel with the announced builds. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Petr Mladek wrote: It is well recommended to use daily builds from http://dev-builds.libreoffice.org/daily/. They include the very last fixes and can be installed in parallel with the announced builds. That may be true for other OSes but not for Windows. Once LO gets to 3.5.x that will (hopefully) be a correct statement. You can in fact install 3.4.x in such a way that it doesn't uninstall or overwrite the stable build. But it is a hack. Not a proper install. Interestingly I have mentioned in another (ignored) topic that the Windows daily builds are based on code previous to the pre-releases (pre release is on 3.4.1rc3, daily builds are based on 3.4.1rc1) After a quick check, it seems that ALL daily builds for all OSes are based on 3.4.1rc1... I must be missing the logic here... -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3113845.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi there, On Mon, 2011-06-27 at 07:19 -0700, plino wrote: That may be true for other OSes but not for Windows. Once LO gets to 3.5.x that will (hopefully) be a correct statement. Oh - well - since master is going to turn into 3.5, if that is not parallel installing, then we have a problem - is it the case that the 3.5 (master) snapshots - whatever we call them version-wise [ what do we do there ? ] do not parallel install on windows still ? It also seems, that we don't in fact have windows or linux daily / release snapshots of master either - which is not a happy place to be; any thoughts on that Fridrich ? Good feedback plino ! :-) Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael Meeks schrieb: Oh - well - since master is going to turn into 3.5, if that is not parallel installing, then we have a problem Hi, I believe most testers can live with every behavior, but behavior must be predictable. We ned some Help (Wiki: QA/DailyBuilds) with exact descriptions how to use - for every operating system and every variation of the Daily build. Currently I see 3 folders for WIN and have to guess how the contained builds will behave, how they should be used and for what they are. CU Rainer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Norbert, *, Norbert Thiebaud wrote (25-06-11 02:21) On Fri, Jun 24, 2011 at 6:00 PM, Cor Nouwsoo...@nouenoff.nl wrote: Do misunderstand the meaning of 'freezing'? I understand it as the point from where only bug fixes are allowed to the branch. So a longer time frame without large clean-up, re-factoring, other smart improvements and new features. Definitely this gives more time to find and fix bugs. Well true except that it freeze _that_ branch... but it does not _force_ people to stop working on master. So what I understand Michael saying is: 1/ you freeze and create the 3.X branch 2/ little test is done on 3.X branch for the reasons aforementioned IMO that is a crucial effect to *avoid*. And indeed, I see no reason why that would be a natural thing happening. If there is a moment that we know: QA on this build is important, do this ... that will help focussing :-) [...] ( Now I snip a whole lot of words from you with valuable aspects of QAdevelopmet etc. I expect much of it will be used either by improving the process over time, or by establishing the topics needed at a certain moment for judging/choosing what is the best time-set for 3.5.0. ) The more QA, people, the faster it goes, of course. But that is another matter. And of course, QA has to be a continuous state. So a possible longer time from freeze to release, would IMO not mean that we advise people to start later with testing :-) Then the question is How would 'freezing' improve that (motivate poeple to do early testing) Not earlier compared to the moment of freezing. But earlier compared to the moment of releasing. Thus more time available for that specific testing. Any change that the time from freeze to release can be too long, and thus a waste of developer time? I can hardly imagine: if less time is needed for fixing bugs, more time is left for major work on the master. Changing the freeze date has no impact what-so-ever on the amount of bug or the time it takes to fix them... I must be missing your point here... Hmm, it looks as if I tried to answer a non-existing question. OK, half October .. till December 5 is only 7 weeks. Deciding at that moment, holds the risk that developers suddenly have say only 3 or 4 weeks left for finishing major work, in stead of 7. IMO, that is not fair. That is the 'norm'... the point of continuous dev is that everyday could be release day... but since we release fairly often the consequence of not being ready for a given release is not that dire... 'Major work' is typically done in a feature-branch.. and that feature branch is merged when it is ready not when the schedule say so. The whole idea behind 'time-based-released' is that you release what is ready at the time you've chosen. not cram the development to squeeze it in time Yes, that is clear and sounds sane. However, as developer you look at the calendar too, and will sometimes make some estimates about what you can/would like to do, in order to get a major work done for a minor release. Therefore I argue that it would not be fair to decide on 7 weeks from the deadline, that it is shortened by 3 or 4 weeks. Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Sat, Jun 25, 2011 at 4:52 PM, Cor Nouws oo...@nouenoff.nl wrote: [...] ( Now I snip a whole lot of words from you with valuable aspects of QAdevelopmet etc. Yeah, sometime I tend to to suffer from logorrhea :-) The more QA, people, the faster it goes, of course. But that is another matter. And of course, QA has to be a continuous state. So a possible longer time from freeze to release, would IMO not mean that we advise people to start later with testing :-) Then the question is How would 'freezing' improve that (motivate poeple to do early testing) Not earlier compared to the moment of freezing. But earlier compared to the moment of releasing. Thus more time available for that specific testing. Ok, let me try to reformulate the problem: Formal testing of a Beta/Rc require an large amount of work just to regression test things... A lot of these tests are not expected to yield bug, especially after the first Beta (that is, regression would be mostly found at that point, and hopefully very few would be introduced by subsequent fixes) So a test window of 1 week, will be use mostly doing that and not as much used to discover new bugs and test new function exhaustively. Hence the proposal become: make the release rate of Beta/RC slower. and 5 beta/RC at two week interval would yield better result than 10 Beta/RC at one week interval. Do I get that right ? If that is indeed the crux of the argument, then I would suggest: Expand the time between Beta/RC to two weeks (maybe 3 for the first beta?) (I would also suggest release on Thursday so that feedback from the second week-end have a chance to be fixed before the next release) But then, QA still need to use Daily Build, as much as possible, during the period to confirm that bugs found in the current Beta/RC are indeed fixed to satisfaction _before_ the next Beta/RC comes out. In other words, use a continuous QA process on top of a formal Release-Based QA, to limit the number of formal Release-QA while maintaining a good pace of fixing... Norbert PS: with the merging of the git repos, it will become fairly trivial to identify a 'build' using the git-sha of the commit that was used to build it. So if, when we close a bug in Bugzilla, we mention the commit-sha that is associated with the fix, it should be relatively easy to determine if a given daily build is supposed to include the fix. Heck we could even make that a web-service: give the sha of your version and the sha associated with a bug in bugzilla and it tells you if that bug was meant to be fixed on that version of not (for example: if [ ($git merge-base $build_sha $bugfix_sha) = $bugfix_sha ] ; then echo $bugfix_sha Fixed in $build_sha ; fi ) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Sat, Jun 25, 2011 at 4:52 PM, Cor Nouws oo...@nouenoff.nl wrote: Therefore I argue that it would not be fair to decide on 7 weeks from the deadline, that it is shortened by 3 or 4 weeks. Sure, but delaying the Release Date by 3 or 4 weeks will not be fair to downstream either The calendar was worked out by picking a Release date that would work for downstream - RedHat, Canonical, Suse,... - and then working our way backward to a 'freeze date'. the consequence of a major downstream not being able to pick-up a release of ours is much more important, in my opinion, than a given feature being pushed to the next release. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Pedro, plino wrote (24-06-11 02:03) Cor Nouws wrote: Plus - especially with the unfortunate experience from 3.4.0, and to do something good for users, testers, marketing etc - IMO it is better that in the end we have three weeks extra, than that we lack three days. So I would really love to be on the save side .. Thank you Cor for listening to the users instead of the mighty schedule Well, thanks for the complement .. :-) But of course ... I don't think that it is the intention of the mighty schedule to hurt anyone or let alone the project :-) - we are all learning how this should work best for us. And that definitely will change over the months, years... BTW since only Betas can be installed in parallel with the stable build under Windows and that was not added to the 3.4.x branch (at least from my understanding) I guess Windows Beta testers will have to wait for 3.5.x, right? Well, I don't see any betas coming for the 3.4.x branch, so whether is has been added or not, does not make sense. I only can point to my favourite page: http://wiki.documentfoundation.org/Installing_in_parallel I hope that helps people to run more versions (early versions) on Windows too, so that it give them the opportunity to give feed back in an early stage. (Personal note: I really appreciate that I have not (or only seldom) to work with Windows any more. Public drawback: I cannot do serious testing there and already find it hard to understand, to follow the items going on Windows.) Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
plino wrote (24-06-11 09:03) Cor Nouws wrote: Well, I don't see any betas coming for the 3.4.x branch, so whether is has been added or not, does not make sense. Unless TDF is going to adopt the absurd Chrome (and now Firefox) version model, the next version should be 3.5.0 indeed. Hmm - apart from your off topic comment on Chrome/FireFox - I see no rationale for that. There is a monthly schedule for bug-fix releases that is very important for all kind of users. See http://wiki.documentfoundation.org/ReleasePlan I guess we (Windows users) will have to wait :) Wait for what? I don't understand what you are trying to say here. I only can point to my favourite page: http://wiki.documentfoundation.org/Installing_in_parallel I hope that helps people to run more versions (early versions) on Windows too, so that it give them the opportunity to give feed back in an early stage. As I mentioned before, that is useful for a very limited number of Windows users. But those that can, should use it and help others... If TDF wants a significant number of Windows beta testers that simply won't do. And as known, 3.5 betas will install without conflict with the 3.4.x installation, so where is the problem? (Personal note: I really appreciate that I have not (or only seldom) to work with Windows any more. Public drawback: I cannot do serious testing there and already find it hard to understand, to follow the items going on Windows.) I'm sure more Windows users would be available for serious testing if TDF took the Windows users more seriously and in proportion to the platform importance (given the sheer number of users) I know no evidence that Windows (users) is (are) not taken seriously. I think it will help if people try more serious to improve on where we are, also with QA/testing, rather then complain. Best, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Cor Nouws wrote (24-06-11 09:21) I know no evidence that Windows (users) is (are) not taken seriously. I think it will help if people try more serious to improve on where we are, also with QA/testing, rather then complain. Hmm, while slicing an excellent mango (hmm ;-) , my thoughts drifted to this subject again (for the last time today!). I have the feeling of fighting some acid rain, when replying to your mail Pedro. And indeed, I can imagine that this has been caused by the words used by some developers, in a much older thread. Some are so much convinced of what they think, and also bring that across in such a way, that it easily gives the impression that other opinions are moot or so. Which is a sad situation :-( That might be an explanation for the feeling that I get with your mail. But the again, probably I must have had written, expressed this before. So after acknowledging, my advise would still be the same: understand and improve ;-) Have a nice day :-) Cor -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael @ OP - awesome set of notes! Cor @ I only can point to my favourite page: http://wiki.documentfoundation.org/Installing_in_parallel Even though I have two build configs (3.4 and master), OOo3.2 and the 3.4 release installed, I have been frustrated in doing full triage/testing and other qa by no access to 3.3 - I can see why that is your favorite page and now I can see why you (and others) are able to test issues in any version. Thank you so much! LeMoyne -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3103230.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2011-06-24 at 01:11 +0200, Cor Nouws wrote: * Posting TSC minutes on the blog ... + Norbert: wording is very terse, not enough context, not suitable for mass public consumption. + Suggestion: needs to be expanded, and made more comprehensible, someone who wants that can/should do it. Short highlights + link to mail archive might be useful too.. Certainly - anyone is welcome to do the work and come up with that content - the minutes are public; if someone writes a nice summary, I'm happy to quickly sanity check it before release too. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Michael, Michael Meeks wrote (24-06-11 10:52) On Fri, 2011-06-24 at 01:09 +0200, Cor Nouws wrote: Apologies for that - but it was about what I expected. (Have to try to focus on making a living during the day-hours ;-) ) Sure, sure ... + extend the feature-freeze period for 3.5 ? + Norbert: may not help people fix things, just move their work to the next generation. .. Thanks for discussing the subject and the ideas brought forward. Hey - I'm only sorry that there was no-one there to argue the other point of view ;-) Don't worry - we're not going to forget you :-p On the other hand, we do not yet know how - the time of the year (Christmas, Western New year); - the speed of the growth of people involved in QA; - the fact that QA-time has to be devided among various versions simultaneously, - etc, will affect the reality in 6 months from now :-) Of course; predicting the future is hard. Plus - especially with the unfortunate experience from 3.4.0, and to do something good for users, testers, marketing etc - IMO it is better that in the end we have three weeks extra, than that we lack three days. So I would really love to be on the save side .. So - the problem is, there is really no safe side, it is a balance. Sure, sure. There is no guarantee that people will work more on bug-fixing if we feature freeze earlier, nor is there a guarantee that people will do QA and find the bugs until we are in the late RC phase no matter how early we release. What we do know (1+1=2), is that if there is a limited amount of people doing QA, providing them more time (weeks) will result in more testing. Much QA seems to be deferred to post release - when it seems most people really start testing ;-). It looks like. And also is true for some part. Therefore the step to make it possible to install betas alongside the stable version, is a major improvement of our work flow. So this is some sort of psychological game, which (I hope) we already play quite well by releasing and then doing lots of iterative incremental improved versions. I agree with the merits of that approach. Don't know however if that alone will make more people do QA. Serious testing and reporting are time-consuming. So starting again with a fresh version every few weeks, costs time... Indeed - by freezing earlier we could potentially make things worse ;-) Warning: you're going to loose me completely in the next paragraph. because QA will not have started at all, and thus there will apparently be no bugs to fix, and hackers will then get really stuck into working on another branch, which will diverge far more from the code we're releasing, such that they have less interest / ability to fix bugs in the stable version by the time QA arrives in earnest so ... Do misunderstand the meaning of 'freezing'? I understand it as the point from where only bug fixes are allowed to the branch. So a longer time frame without large clean-up, re-factoring, other smart improvements and new features. Definitely this gives more time to find and fix bugs. The more QA, people, the faster it goes, of course. But that is another matter. And of course, QA has to be a continuous state. So a possible longer time from freeze to release, would IMO not mean that we advise people to start later with testing :-) Any change that the time from freeze to release can be too long, and thus a waste of developer time? I can hardly imagine: if less time is needed for fixing bugs, more time is left for major work on the master. So, this all needs to be discussed explained; that is best done in person I think. However, we do not have to decide that exactly right now, do we?! Quite. So - what I think we should do is to propose a joint talk on the topic at the LibreOffice conference in Paris in October - preferably with some good assessment of the quality of master at that time; then we can decide whether to move the existing (December) freeze date forward or back at our leisure - and over beer. OK, half October .. till December 5 is only 7 weeks. Deciding at that moment, holds the risk that developers suddenly have say only 3 or 4 weeks left for finishing major work, in stead of 7. IMO, that is not fair. Though of course the venue to discuss it, is excellent (which is not yet a promise from my side that I will be there..) But still, I would very much prefer to keep an eye on all that is related the next months, and see if we can discuss this on list, during a conf. call, somewhere the next months. Then we can pick up the essentials from my previous mail too: the reasons to be on the very safe side now. How does that sound ? any chance you could recruit a suitable panel ? I'd want Caolan, Petr, myself and Bjoern on it - and yourself, Rainer, and whomever else you can choose that is actively working on QA /
Re: [Libreoffice] minutes of tech steering call ...
On Fri, Jun 24, 2011 at 6:00 PM, Cor Nouws oo...@nouenoff.nl wrote: Indeed - by freezing earlier we could potentially make things worse ;-) Warning: you're going to loose me completely in the next paragraph. because QA will not have started at all, and thus there will apparently be no bugs to fix, and hackers will then get really stuck into working on another branch, which will diverge far more from the code we're releasing, such that they have less interest / ability to fix bugs in the stable version by the time QA arrives in earnest so ... Do misunderstand the meaning of 'freezing'? I understand it as the point from where only bug fixes are allowed to the branch. So a longer time frame without large clean-up, re-factoring, other smart improvements and new features. Definitely this gives more time to find and fix bugs. Well true except that it freeze _that_ branch... but it does not _force_ people to stop working on master. So what I understand Michael saying is: 1/ you freeze and create the 3.X branch 2/ little test is done on 3.X branch for the reasons aforementioned 3/ with little bug reporting, in the mean-time most dev go back to hacking on master (without freeze) 4/ Just before or just after release there is a rush of QA activity that uncover all these latent bug... 5/ by this time the dev have been working on something else for 3-6-9 weeks (pick the number of week you want the 'freeze to be') 6/ the level or interest to go back in time (code-wise) is vanishing... iow: QA should really be a continuous process, just as dev. that is QA should (also) be done on master, with an emphasis on pre-freeze period, so that bugs are uncovered pre-freeze as much as possible. Then the freeze period is the time when: we branch the code and limit the change to it to fix-bug and QA _intensify_ right when we freeze so that bug report pour in soon after the freeze, not 3 -4 weeks after it. Freezing, in my mind means: we have something close enough of being good. we freeze and spend some time to make it release-good. but for that to work, it need a concerted effort of all, not just dev stopping to code on that branch. By moving the testing more toward master, we could minimize these epic 'rush' to RC that I have noticed so far, when all the full time dev are swamped, rushing to fix RC in time... It is not good for them, and it is not good for the rest of us nor for master as we are both essentially orphaned for a 3-4 week period, when our 'champions' have no time and little patience to help and guide... As caolan said in another post, 'master' should no be seen as 'unstable'. 'master' should be seen as the latest version about to be released... Sure there will be time when master breaks... but that should be rare and short-lived. And it is the Dev's responsibility to take master breakage seriously, it is a 'culture' that we need to develop and engrain at the core of our 'community'. We are making progress toward that goal, notably by improving the automation and tooling around master. Right now Linux and Mac build breakage are typically detected in less than 30 minutes... Windows is still a problem, but it is not hopeless... There is a lot of work to be done to automate testing, and QA can help with that. In the end, as master become more and more 'reliable' we should be able to convince QA volunteers that testing Dailies is useful, that the sooner a bug is caught the cheaper it is to fix... and if Dailies get some coverage then the 'frozen' version will be that much more stable and there won't need such a long and epic 'stabilization' period. I think that one problem may also be an approach to QA: testing dailies doe not mean 'run the formal test procedure that is needed for the _validation_ of a Release, it means download it regularly and 'play' with it... run some test, run some work-flow you like or you think can be tricky, run different test on the next dailies (unless you try to verify if a bug is fixed)... heck even randomly pick a dozen or what-many you have time for today and run these on that daily... tomorrow, or next week-end do another set on the _then_ daily... Again the point of the exercise is not to 'validate' a version, but to try to stumble upon bugs as early as possible as a bonus side effect that can also provide 'usability' feed-back on feature while they are developed... again:the sooner a problem is detected the cheaper it is to fix. We could also 'formalize' that a bit by formally producing 'weeklies' (i.e pick a dailies and 'promote' it) and setup Litmus so that people could log-in and test the 'release of the week'. Of course in that case the goal is not necessarily to cover everything every week at all cost.. The more QA, people, the faster it goes, of course. But that is another matter. And of course, QA has to be a continuous state. So a possible longer time from freeze to release, would IMO not mean that we advise people to start later with
[Libreoffice] minutes of tech steering call ...
Attendees: + Michael, Caolan, Kendy, Andreas, Rainer, Timar, Tor, Thorsten, Petr, Francois, Norbert, Cedric * Completed AA's + binned dlsym'd fontconfig non-fontconfig X font code paths (Caolan) + avoid: completely junking gnome-vfs backend startup hooks (Caolan) + glib not built internally, and system integration issues with gio + RHEL5 similar vintage don't have gio = gnome-vfs still needed + put Rainer in touch with Gerv (Michael) + kill Adabas integration dead in master (Francois) + disabled for a release, removed next release * AA still pending: + Easy Hacks - completion / fixing (Bjoern) + get SmartArt into master as an experimental feature (Thorsten) + remove old non-cairo cases (Caolan) + bin monochrome paletised display support with prejudice (Caolan) * Action Items * QA feedback (Rainer) + short report concerning results of our German QA Meeting last weekend + lots of barbeque, fun, and some results + bugzilla - leave it at freedesktop.org or not ? + collect goals required features eg. UNCONFIRMED as default some timelines + then discuss with freedesktop guys. + concerns: wrt. compromises wrt. other projects + probably: some day, one year out ? migrate away. + decision in six months time. + eg. automated access for bug reporting agent ? + bugzilla setup easy, but upgrade / migration hard. + bug hunting ... + try bug-hunting session each month: every 1st Tuesday of a month, EU afternoon - night + wiki page coming to list details + main-page / August banner ads to encourage that + goals: to confirm / triage bugs - no hacking skills necessary + help quality + getting out of step with code changes in places + a common feeling, something should be done AA: + contact / discuss with the documentation team to find owners for help bugs (Rainer) + Timar to help out with minor cleanups / removals + Extensions repo testing / status (Andreas Mantke) + site is setup / working / published to website list + http://extensions2.libreoffice.org/ + branding work improved, not opened for new accounts yet + work on anti-spam account filtering ongoing + populate with existing Free Software extensions + contact extension authors to populate the site + readying to go live. + graphical comparison tool - update regression tests ongoing * Cross-compilation update (Tor) + what works + configure script configures for cross-compilation + make compiles native build-time tooling + then cross-compilation starts + for Windows - approx. 1/2 the way before errors, due to missing pieces in MingW + Jesus getting involved too, and re-appling GSOC 2009 work to the problem from 'build' + problematic msi creation tools, WINE ? + for iOS - gets quite far, nothing is linked + Matus' work should help here. + for Android - tries to link things, much missing from VCL etc. + hopefully gtk3 / broadway work can help GUI-wise. + to PPC Mac from Intel Mac - not tried it much, in theory the easiest target. + lots more work to do, but nothing really impossible + UI for embedded platforms requires much more work * Releng bits (Petr) + 3.3.3 post-release roundup + out last week, no known regressions filed + future of 3.3 branch (Rainer) + QA meeting tested 3.3.3 + less community interest in testing 3.3.3 + eagerness to test new features etc. + concern for wasted man-power on 3.3.x + what are our goals ? + unify distro maintenance work + keep security up-to-date + key as balance for less stable point-zero versions etc. AA: + communicate more minimal QA requirements for each release (Petr) + 3.4.1 status / roundup 3.4.2 + fdo#38590 charts
Re: [Libreoffice] minutes of tech steering call ...
On Thu, Jun 23, 2011 at 07:27:36PM +0100, Michael Meeks wrote: * Completed AA's + kill Adabas integration dead in master (Francois) + disabled for a release, removed next release I have found no evidence it is still used, but there still may be people living under a rock somewhere. This way it gives them a chance to re-enable the Adabas D driver without too much work after the first 3.5 release. AA: + check out nightlies, and encourage others to use (Rainer) I'm packaging snapshots of -master in pkgsrc-wip: http://pkgsrc-wip.sourceforge.net/ http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/libreoffice/ A handful of people are downloading the distribution files; almost no feedback apart from wiz@ so far. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi *, Michael Meeks wrote (23-06-11 20:27) * Release quality / complaints ... (Cor / Italo / Olivier) + presenters not present Apologies for that - but it was about what I expected. (Have to try to focus on making a living during the day-hours ;-) ) + extend the feature-freeze period for 3.5 ? + Norbert: may not help people fix things, just move their work to the next generation. + Petr: earlier Beta / Alpha releases ? need to be useable and QA done continuously / before freeze as well. + Norbert: 3.4 impacted by merging m106, don't have this issue next time around + Caolan: nightly builds are now working, and should help get QA access to the code, and insight into progress + Caolan: more automatic regression tests are coming too + Rainer: not much penetration in QA team of nightly snapshots, most don't know where to find them. AA: + check out nightlies, and encourage others to use (Rainer) + Nobert: treat feature-freeze as a release for QA purposes ? + Caolan: master perception - should be always ok, ready to ship at any time - not actually broken modulo occasional build issues + the future should not be as bad as the 3.4.0 panic. Thanks for discussing the subject and the ideas brought forward. I am quite optimistic about what we will achieve in the future (...) and very positive about our improvements. On the other hand, we do not yet know how - the time of the year (Christmas, Western New year); - the speed of the growth of people involved in QA; - the fact that QA-time has to be devided among various versions simultaneously, - etc, will affect the reality in 6 months from now :-) Plus - especially with the unfortunate experience from 3.4.0, and to do something good for users, testers, marketing etc - IMO it is better that in the end we have three weeks extra, than that we lack three days. So I would really love to be on the save side .. However, we do not have to decide that exactly right now, do we?! So, imagine we would choose for say a three or four weeks extra between freeze and release, when should that have to be decided? Somewhere September, early October? Then we can hold on the detailed discussion and decision on this subject until then.. Sounds OK? Best, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael Meeks wrote (23-06-11 20:27) * Posting TSC minutes on the blog ... + Norbert: wording is very terse, not enough context, not suitable for mass public consumption. + Suggestion: needs to be expanded, and made more comprehensible, someone who wants that can/should do it. Short highlights + link to mail archive might be useful too.. -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Thu, Jun 23, 2011 at 6:11 PM, Cor Nouws oo...@nouenoff.nl wrote: Michael Meeks wrote (23-06-11 20:27) * Posting TSC minutes on the blog ... + Norbert: wording is very terse, not enough context, not suitable for mass public consumption. + Suggestion: needs to be expanded, and made more comprehensible, someone who wants that can/should do it. Short highlights + link to mail archive might be useful too.. I think the problem is not to make them shorter, but to make them 'longer', more digestible for people who do not follow these call and the dev-ML in general. I'm thinking about the difference between reading the linux-kernel mailing list and reading, once a week an highlight of the noticeable, interesting event by Colbert on LWN. The later is a great thing, I enjoy very much reading them... but I, for one, would be completely incapable to do what Jonathan Corbet does, even If I read every email of linux-kernel and had nothing else to do but that... Proper reporting for a wider audience is a skill in and of itself. Giving these 'minutes' as-is to a wider audience is begging for blogger and journalist to mis-understand and mis-quote them. Most of them would not use such minute for a dev ML as a 'source', but if TDF 'publish' them, then it is another ballgame... I mean, looks at what happen, even when communication expert spend time to have a long conversation with a journalist: the headline is 'TDF not production-ready until August'. So now imagine th same journalist, which is very unlikely to scour the dev-ML for info, now get that terse and lingo-prone summary in his rss-feed ? I dare not imagine what the next 'headline' will be Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Cor Nouws wrote: Plus - especially with the unfortunate experience from 3.4.0, and to do something good for users, testers, marketing etc - IMO it is better that in the end we have three weeks extra, than that we lack three days. So I would really love to be on the save side .. Thank you Cor for listening to the users instead of the mighty schedule BTW since only Betas can be installed in parallel with the stable build under Windows and that was not added to the 3.4.x branch (at least from my understanding) I guess Windows Beta testers will have to wait for 3.5.x, right? -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3102309.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Andrea, On Sat, 2011-06-18 at 14:57 +0200, Andrea Pescetti wrote: Would it be possible to have some more information about the security issues fixed in LibreOffice 3.3 ? Sure - this is what the agenda item is about; AFAIR there is only one interesting one, that is a Lotus Word Pro related issue. At least, a short description of each issue and information on whether they affect/affected the 3.4 series too ? It doesn't affect 3.4.x - we fixed it there early, and released 3.4.x silently with the fix, and CERT should have announced post 3.3.x - but sure ... We need people who in addition to coping with the tedium of reacting to the security issues, providing fixes and testing them on older branches - also like to write them up. This is an important factor for people considering to upgrade their current LibreOffice installation Sure - so - there is certainly a space to do this sort of thing in the security team if you want to get stuck in ? and of course, we can't use usual means for this - the bugs / patches are not tracked in bugzilla etc. so it needs some manual effort. Do you know anyone that would want to help out with that admin ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Olivier, On Sat, 2011-06-18 at 08:25 -0300, Olivier Hallot wrote: Can such minutes be posted in TDF blog? I think it deserves publicity: Either for its content and for visibility + vitality of the TSC and LibreOffice. Again, it'd be wonderful if someone wanted to do that. Having said that, the minutes are extremely succinct - ie. you have to be a hacker to understand them ;-) and (personally) I'd resist spending even more time making them very verbose chatty. Though, of course if someone wants to come to the TSC meetings and write a longer verbose screed on what was said to post on the blog, that is fine too. Of course, if the existing format is fine, and/or we can just expand where necessary via questions on the blog itself (perhaps) then it shouldn't be too hard to post what is there. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi TSC, Can such minutes be posted in TDF blog? I think it deserves publicity: Either for its content and for visibility + vitality of the TSC and LibreOffice. Thanks Regards Olivier Em 17-06-2011 11:13, Michael Meeks escreveu: Present: Norbert, Rainer, Michael, David, Caolan, Kendy, Andras, Bjoern, Cedric, Thorsten, Petr, Andreas Mantke, Fridrich * completed AA's + Petr to bump priority of most serious issues in 3.4.1 + looking into lighting up the update reminder service (Kendy) + conditionally used only when build-special is set + requires patching / enabling for 3.4.1 / reviews appreciated. + provide current linux environment gio / glib / gtk+ etc. versions to Caolan (Fridrich) + we include glib these days anyway for rsvg + cairo issues, so stick with last pre-cairo gtk ? + can we use RTLD_DEEPBIND to overcome it ? AA: + remove old non-cairo cases (Caolan) AA: + can now completely junk gnome-vfs backend (Caolan) + incl. startup performance issue AA: + bin dlsym'd fontconfig non-fontconfig code paths (Caolan) * AA still pending: + Easy Hacks - completion / fixing (Bjoern) + get SmartArt into master as an experimental feature (Thorsten) * Agenda + Action Items + Extensions repo progress (Andreas Mantke) + worked with kind plone developer Elisabeth Leddy to improve S/W centre for extensions, all in svn trunk + working with Florian Alex Werner to get setup on Kermit + python problem solved + due to be ready this evening + potential issues around blob storage of extn's + needs UI team input ... + just update http://extensions.libreoffice.org/ re-direction + use second plone sub-centre for templates ... + need to transfer existing extn's from current wiki page. + extended QA phase not neccesary + Releng bits (Petr) + 3.3.3 release RC1 / summary / 3.3.4 thoughts + available on download page + fixes a number of annoying inc. security bugs + 3.3.4 in the plan for ~two months from now, pending interest for merging fixes. + should we drop review for 3.3.4 (Bjoern) ? - not many changes anyway, could review pre-release ? - lack of interest may avoid pre-release review too ... - leave single review in-place for 3.3.4 + 3.4.1 status / roundup + RC1 being up-loaded currently, for announce soon + -lots- of important bug fixes, some data-loss issues, many key 'most annoying' bugs. + plenty left to work on + QA feedback (Rainer) + eager to focus work on 3.4.x + not much more man-power needed in 3.3.x + un-touched bug report count still climbing + 200 more in last six weeks. + despite good work of triagers + focus on most critical + LibreOffice QA weekend in Essen this weekend ... AA: + put Rainer in touch with Gerv (Michael) + Adabas DB - disable / removal for 4.0 (Francois) + a proprietary solution that was historically part of StarOffice + StarOffice version was crippled anyway - 100Mb size limit etc. + never shipped with OpenOffice.org + decision: + kill it completely dead (Caolan, Michael, Norbert, Bjoern, Cedric) + thanks Francois for great research / consensus building + security co-ordination ... (Thorsten) + issues fixed in 3.3.3, how to handle it ? + mention it in the release notes in future. AA: + add Thorsten to security list so he can co-ordinate (Michael) + GSOC update / deadlines reminder (Cedric) + all students on-track, good integration + ux-advise feedback / status + looks good, lots of nice successful interaction there + gnumake4 migration (Bjoern) + rebased into 1 linear line of patches, based on m106 + please do not touch the following modules, they are already gbuildized in gnumake4: basebmp basegfx canvas cppcanvas dbaccess idl
Re: [Libreoffice] minutes of tech steering call ...
On 17/06/2011 Michael Meeks wrote: + security co-ordination ... (Thorsten) + issues fixed in 3.3.3, how to handle it ? + mention it in the release notes in future. AA: + add Thorsten to security list so he can co-ordinate (Michael) Would it be possible to have some more information about the security issues fixed in LibreOffice 3.3? At least, a short description of each issue and information on whether they affect/affected the 3.4 series too? Just LibreOffice 3.3.3 improves the security is not enough: http://blog.documentfoundation.org/2011/06/16/libreoffice-3-3-3-is-ready-for-download/ This is an important factor for people considering to upgrade their current LibreOffice installation; even a simple link to the relevant commits could be helpful, even though a few lines of description would probably be helpful to a lot more people. Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech steering call ...
Present: Norbert, Rainer, Michael, David, Caolan, Kendy, Andras, Bjoern, Cedric, Thorsten, Petr, Andreas Mantke, Fridrich * completed AA's + Petr to bump priority of most serious issues in 3.4.1 + looking into lighting up the update reminder service (Kendy) + conditionally used only when build-special is set + requires patching / enabling for 3.4.1 / reviews appreciated. + provide current linux environment gio / glib / gtk+ etc. versions to Caolan (Fridrich) + we include glib these days anyway for rsvg + cairo issues, so stick with last pre-cairo gtk ? + can we use RTLD_DEEPBIND to overcome it ? AA: + remove old non-cairo cases (Caolan) AA: + can now completely junk gnome-vfs backend (Caolan) + incl. startup performance issue AA: + bin dlsym'd fontconfig non-fontconfig code paths (Caolan) * AA still pending: + Easy Hacks - completion / fixing (Bjoern) + get SmartArt into master as an experimental feature (Thorsten) * Agenda + Action Items + Extensions repo progress (Andreas Mantke) + worked with kind plone developer Elisabeth Leddy to improve S/W centre for extensions, all in svn trunk + working with Florian Alex Werner to get setup on Kermit + python problem solved + due to be ready this evening + potential issues around blob storage of extn's + needs UI team input ... + just update http://extensions.libreoffice.org/ re-direction + use second plone sub-centre for templates ... + need to transfer existing extn's from current wiki page. + extended QA phase not neccesary + Releng bits (Petr) + 3.3.3 release RC1 / summary / 3.3.4 thoughts + available on download page + fixes a number of annoying inc. security bugs + 3.3.4 in the plan for ~two months from now, pending interest for merging fixes. + should we drop review for 3.3.4 (Bjoern) ? - not many changes anyway, could review pre-release ? - lack of interest may avoid pre-release review too ... - leave single review in-place for 3.3.4 + 3.4.1 status / roundup + RC1 being up-loaded currently, for announce soon + -lots- of important bug fixes, some data-loss issues, many key 'most annoying' bugs. + plenty left to work on + QA feedback (Rainer) + eager to focus work on 3.4.x + not much more man-power needed in 3.3.x + un-touched bug report count still climbing + 200 more in last six weeks. + despite good work of triagers + focus on most critical + LibreOffice QA weekend in Essen this weekend ... AA: + put Rainer in touch with Gerv (Michael) + Adabas DB - disable / removal for 4.0 (Francois) + a proprietary solution that was historically part of StarOffice + StarOffice version was crippled anyway - 100Mb size limit etc. + never shipped with OpenOffice.org + decision: + kill it completely dead (Caolan, Michael, Norbert, Bjoern, Cedric) + thanks Francois for great research / consensus building + security co-ordination ... (Thorsten) + issues fixed in 3.3.3, how to handle it ? + mention it in the release notes in future. AA: + add Thorsten to security list so he can co-ordinate (Michael) + GSOC update / deadlines reminder (Cedric) + all students on-track, good integration + ux-advise feedback / status + looks good, lots of nice successful interaction there + gnumake4 migration (Bjoern) + rebased into 1 linear line of patches, based on m106 + please do not touch the following modules, they are already gbuildized in gnumake4: basebmp basegfx canvas cppcanvas dbaccess idl linguistic oox regexp reportdesign sax starmath ucbhelper unotools wizards writerfilter xmlreader xmlscript + no news from Lanedo + Mitch was on vacation +
