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] 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2011-06-17 at 15:13 +0100, Michael Meeks wrote: + Adabas DB - disable / removal for 4.0 (Francois) .. + decision: + kill it completely dead (Caolan, Michael, Norbert, Bjoern, Cedric) My heading was, in retrospect not helpful; the decision was to kill it now in master :-) 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 ...
On Fri, 17 Jun 2011 15:13:45 +0100 Michael Meeks michael.me...@novell.com wrote: + 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 ... and vcl, which I forgot in the original list. 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 Fri, 2011-06-17 at 19:05 +0200, Bjoern Michaelsen wrote: ... and vcl, which I forgot in the original list. vcl is already converted in master :-) 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 ...
On Fri, 2011-05-27 at 11:47 +0100, Michael Meeks wrote: AA: + provide current versions to Caolan (Fridrch) glib2 2.16.0 was the first release to integrated the gio stuff http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00022.html as a data point RHEL-5 is glib2-2.12.3 while RHEL-6 is glib-2.2.22) RHEL-5 cairo is: 1.2.4 RHEL-6 cairo is: 1.8.8 RHEL-5 fontconfig is: 2.4.1 RHEL-6 fontconfig is: 2.8.0 RHEL-5 gtk2 is: 2.10.4 RHEL-6 gtk2 is 2.18.9 I'd like to get the current versions that we build our (apparently acceptable) universal linux builds against at the moment to see what our base-lines are. We have three similar things here btw, a) the oldest version of stuff on the end-user dest box that the universal Linux needs pre-installed in order to work. b) the oldest version of stuff required to be installed when *building* the universal Linux build, which gives wriggle room to e.g. build against new gtk/glib headers etc, so long as avoiding linking to symbols not in the baselines of a e.g. we can dlsym hackery to install on a baseline but use nifty new features when available on dest box, e.g. the auto-detect which monitor is the external projecter to stick the presentation on and which to stick the presentation notes on. c) the oldest version of stuff that its *possible* to build against, e.g. --disable-too-new-features, ifdefs, etc, for the roll-your-own crew So, it may be the case that for the universal build the gio stuff is too new to be required on the *dest* box, but maybe its not too new to be required on the universal *build* box at hack up a run-time toggle between gnome-vfs2 and gio. I know gnome-vfs2 has a rash of horror bugs wrt some mangled (neon or curl, I can't remember) lib built into it whose symbols are unchanged from the original but do different things, so depending on whether gnome-vfs2 or the built-in remote protocol handlers of LibreOffice itself are loaded first the other one breaks horribly. Uncontentious I think is making some minimum version of fontconfig a required lib to be installed and drop much of the miserable dlopen +wrapper pain we have in vcl. Even AIX has fontconfig ;-) AA: + 3.5 schedule check (Caolan) http://wiki.documentfoundation.org/ReleasePlan looks fine to me C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ... (Offensive Word Found In Message)
On 20/05/11 12:53, Norbert Thiebaud wrote: I do agree. but then it should be possible to use a nice review-tools and still have the generated review comment posted in the the ML I mean, when someone add a patch to be review in the tool that can generate a post to the ML with the patch (either inline if small or as a link back to the reviewboard thing doesn't that mean though that someone new who wants to actually participate and maybe is already intimidated by the code, the personalities ( dubious in some cases ;-) ) etc has only a readonly view in otherwords to make those first tentative steps to interact with a review has to go through the hoops and has to get into the reviewboard system/signon etc. To me currently it is just so much easier and use friendly ( and yes I know unfortunately without the nice tools :-( ) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi all, Sorry, I couldn't join yesterday. I'm just wondering where the reviewboard action item went? is that a dropped idea or does it still deserves some action? On Thu, 2011-05-19 at 18:13 +0100, Michael Meeks wrote: Attending: Thorsten, Andras, Kendy, Norbert, Christian, Petr, Rainer, David, Bjoern, Kohei * AA's done + announce new 4.0 wiki page (blog going live today) (Bjoern) + write list of things that suck for newcomers with taste (Mitch / Christian) + write up a time-based release rational (Italo mostly did it for Michael) + move all 'feature' bugs to new most annoying for 3.5 bug (Petr) + list mailed with the number etc. + Petr to decide and come up with a static link of key bugs (Petr) http://wiki.documentfoundation.org/Release_Criteria + come up with a concrete single-git-repo plan (Norbert, Kendy) + do the surgery at 3.4.2 time when merging is over (ish) + generate a preferred date for a point-two release (Petr, Bjoern, David) * AA still pending: + research when gio came into widespread being (Caolan) cf. http://www.gtk.org/download-linux.html + the rdb setup stuff is still too cumbersome (Bjoern) + get SmartArt into master as an experimental feature (Thorsten) + investigate reviewboard and come up with a more concrete proposal (Bjoern) + post single-git-repo plan to the dev list (Norbert) * Agenda: + Action items + 3.4 release status (Petr) + RC1 going out ~now + large number of annoying bugs fixed + basic functionality is working well for users + RC2 / final next week + chasing tripple reviews for patches for 3.4.0 + be great to broaden our reviewer base + TSC call time ... AA: + 14:00 UTC - the new consensus time (get it right next time) + QA update / most annoying bug skim (Rainer) + where should bugs live ? links to other tracking systems + bugs should be in freedesktop bugzilla where possible + sometimes good to have triage via up-streams ? + lots of co-workers doing great work, testing happening + responsiveness improving + investing in gnumake / Lanedo + no objections at all. + 3.5 / schedule alignment with desktop cadence + should sync with majority of distros D/T S/W + and release 2-3 months before them + so distributions pick up x.y.2 or x.y.3 + 2-3 months before + Freeze Dec / June + release mid Feb / mid Aug + June is too soon to freeze for 3.5 + so skip to Dec instead + schedule allows for QA over holidays AA: + fill out the wiki with the proposed post-3.4 schedule (Petr) AA: + look into a plan for notifing of package updates (Thorsten, Kendy) + Mitch / Christian's list of things that suck (Christian) + multiple git repositories pain (being fixed) + make crashing (make bug ~fixed) + used to developing on a branch testing first + problems with waiting for a full clean build before commit + delay, and waste of time often outweighs benefits + understandable some cross-platform problems + incremental building problems: cause much build grief + update, and build fails: can be just dependency breakage + gnumake again can help fix this. + module filenames (cryptic, windows names) + split modules with numeric prefixes - to help compilers + should have human-readable source file names + classes always used together - can make sense together + autogen is triggering when new downloads needed + even so old-style make dependency problems around + namespaces painful: com::sun:star:: ... cluttering header files + planned to fix for 4.0 * Next time: + continue most-annoying things discussion (Mitch) + own extensions repository (Rainer) + discussion concerning discussion concerning future of our bug tracking System (Rainer) -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
On Fri, 20 May 2011 09:27:21 +0200 Cedric Bosdonnat cedric.bosdonnat@free.fr wrote: Hi all, Sorry, I couldn't join yesterday. I'm just wondering where the reviewboard action item went? is that a dropped idea or does it still deserves some action? Still to be done, but wont be done next week. 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 ... (Offensive Word Found In Message)
On 20/05/11 08:27, Cedric Bosdonnat wrote: Hi all, Sorry, I couldn't join yesterday. I'm just wondering where the reviewboard action item went? is that a dropped idea or does it still deserves some action? I meant to say something when this was originally floated but got distracted. I think the idea of those kinda tools are good, I have even used similar ( maybe even it was the the one ) tools previously for reviewing and found them really good. However I would say that I think these work best in a closed environment, by closed I mean a tight group that are the reviewers that control the whole thing. The disadvantages for us I see is the need for a new list to subscribe to ( who needs yet another list ) or having to have an account in some webserver that hosts the tool(s) Posting to the dev list to me remains in my view the most inclusive way of doing reviews, it's process light, everyone gets to see what happening, and most importantly ( imo ) all can learn from the reviews ( it's real easy to dip-in/out of any review thread as you wish ) I really wish to stress the 'learn' aspect because I think reviews are a key way for people to learn about the code ( no joke I think I learn something new every day on this list from the reviews that I read ) imho we should make it as easy for people to be exposed to the reviews as possible just my 2 whatever Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ... (Offensive Word Found In Message)
On Fri, May 20, 2011 at 6:05 AM, Noel Power nopo...@novell.com wrote: I really wish to stress the 'learn' aspect because I think reviews are a key way for people to learn about the code ( no joke I think I learn something new every day on this list from the reviews that I read ) imho we should make it as easy for people to be exposed to the reviews as possible I do agree. but then it should be possible to use a nice review-tools and still have the generated review comment posted in the the ML I mean, when someone add a patch to be review in the tool that can generate a post to the ML with the patch (either inline if small or as a link back to the reviewboard thing When reviewer comment, these reviews can be cross-posted to the list too, with again a link back to the reviewboard tool for context... That was you still have to follow only one list... but we can use nicer tooling... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Hi *, On Thu, May 19, 2011 at 7:13 PM, Michael Meeks michael.me...@novell.com wrote: Attending: Thorsten, Andras, Kendy, Norbert, Christian, Petr, Rainer, David, Bjoern, Kohei /me was also listening, but apparently my microphone didn't work... But as I didn't have anything to contribute to the discussion... * AA's done [...] + Petr to decide and come up with a static link of key bugs (Petr) http://wiki.documentfoundation.org/Release_Criteria I must have misunderstood Petr/the whole item here - I though he would come up with a naming-scheme for bug-aliases, but looking at the page it is just a regular query I though of something like this: https://bugs.freedesktop.org/show_bug.cgi?id=LO-dev-builds so aliases for the blockers could be just LO-version or LO-version-most-annoying or somethng like that. And after having looked at the wiki, I got reminded of the extension I hooked up - you could use the feed-keyword to add the list of issues to the wiki-page itself, as it's done on the EasyHacks page now (i.e. simple list with only link Summary see http://wiki.documentfoundation.org/Development/Easy_Hacks or http://wiki.documentfoundation.org/Talk:Development/Easy_Hacks for usage info) 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, 2011-05-05 at 23:02 +0200, Christian Lohmaier wrote: Oh - and please write this in big letters :-) Yes :-) And also make sure when you remove it completely: Don't remove the filter-detection part of it. I.e. when a user then opens a binfilter-covered format, don't present the user with the file-format selection box, but use a sorry, support for this format was removed - open it in 3.4 or similar dialog. That is a really good idea :-) Add to that - just realized that bugzilla of FDO has a review-extension (splinter - http://fishsoup.net/software/splinter/ ) for patches. When an issue has a patch attached, it's possible to use a review link and comment on the whole patch and also on individual lines (double-click on the line you want to comment on in review mode) Yes - the problem (to me) with bugzilla is that (traditionally) patches rot there - and that it builds a very atomised set of hackers - where no-one knows what anyone else is contributing. This will also greatly ease creation of local clones, something that is so easy with mercurial, but so hard with git... Yep - go Norbert ! :-) 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, * announcing binfilter as deprecated in 3.4 + want to warn people in plenty of time + officially deprecate it, we drop save support in 3.4 The code cleaning is not yet finished, I still have commits (and done commits) that missed the 3.4 freeze (argh, missing free time) and some that needs to be done. + be warned - it will die in a new major release soon. Will be this 3.5 ? Or do you want to wait for the next version? If post 3.5, then I will continue the cleaning. If no, I may change my work and try to perform cleaning (ergh, deletion) as proposed here below. And also make sure when you remove it completely: Don't remove the filter-detection part of it. I.e. when a user then opens a binfilter-covered format, don't present the user with the file-format selection box, but use a sorry, support for this format was removed - open it in 3.4 or similar dialog. Regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi *, 2011/5/6 Pierre-André Jacquod pjacq...@alumni.ethz.ch: [...] + be warned - it will die in a new major release soon. Will be this 3.5 ? Or do you want to wait for the next version? If post 3.5, then I will continue the cleaning. If no, I may change my work and try to perform cleaning (ergh, deletion) as proposed here below. Please at least have one release for people to be warned by lack of write support. But of course we can/should start communicating the removal of binfilter now. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Pierre, On Fri, 2011-05-06 at 18:15 +0200, Pierre-André Jacquod wrote: + be warned - it will die in a new major release soon. Will be this 3.5 ? Or do you want to wait for the next version ? Probably post 3.5 :-) and of course, Caolan is on FTO and would want some input into this too (as one of the last corporate supporters of that I guess). If post 3.5, then I will continue the cleaning. If no, I may change my work and try to perform cleaning (ergh, deletion) as proposed here below. My thought was at the magic 4.0 release (still on the drawing board), it might be a good idea to do this (along with a lot of other key fixes). Anyhow - we're appreciating all your good work cleaning that beastie up :-) 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 ...
Hi *, On Thu, May 5, 2011 at 6:32 PM, Michael Meeks michael.me...@novell.com wrote: * announcing binfilter as deprecated in 3.4 + want to warn people in plenty of time + officially deprecate it, we drop save support in 3.4 + be warned - it will die in a new major release soon. Oh - and please write this in big letters :-) And also make sure when you remove it completely: Don't remove the filter-detection part of it. I.e. when a user then opens a binfilter-covered format, don't present the user with the file-format selection box, but use a sorry, support for this format was removed - open it in 3.4 or similar dialog. * reviewboard / etc. (Bjoern) + would using it make things easier for new developers ? + another authentication account required + help tracking the patch pipeline, and its status if it's only to track the pipeline, then patchwork http://ozlabs.org/~jk/projects/patchwork/ might be an alternative. + reviewing patches in bugs can be good (Mitch) + but many patches get lost ~forever without poking (Michael) Add to that - just realized that bugzilla of FDO has a review-extension (splinter - http://fishsoup.net/software/splinter/ ) for patches. When an issue has a patch attached, it's possible to use a review link and comment on the whole patch and also on individual lines (double-click on the line you want to comment on in review mode) * single git repo test (Norbert) Ah, I would really love to see this :-) This will also greatly ease creation of local clones, something that is so easy with mercurial, but so hard with git... ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi *, On Fri, Apr 22, 2011 at 3:29 PM, Michael Meeks michael.me...@novell.com wrote: [...] * Patches from new contributors + master regularly not building [urk! needs more reliable tinderboxes] Well, the existing tinderboxes do spot the errors, the problem is that it takes rather long until the breakers are fixed... I just had a look in my gmail spam folder, and no wonder: Quite a bit of the tinderbox-error mails have been flagged as spam, so people probably don't notice they broke a build. If you're using mail, please go to your spam folder and flag the tinderbox mails as not spam, to teach gmail that those are valid ones... But yes, indeed the Fedora one has a serious problem, lately there have been many segfaults during the build: http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1303479018.7409#68605 (and tinderboxes should IMHO use --enable-werror) ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Caolan, On 2010-12-15 at 20:20 +, Caolán McNamara wrote: Actually, I still might have the cvs - git import I did 2-3 years back The source cvs repos are still around and online, right ?, i.e. :pserver:anon...@anoncvs.services.openoffice.org:2401/cvs Yes, but for the import I need a complete cvsup mirror; it would take ages without raw access to the ,v files. And unfortunately I don't have any working cvsup binary any more to get something more recent - my cvsup mirror seems to be from 2009-01-26. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Thorsten, On 2010-12-15 at 20:51 +0100, Thorsten Behrens wrote: Actually, I still might have the cvs - git import I did 2-3 years back that tracked all the branches, and also marked the integration commits as merges; if there'd be more demand for that, I could try to resurrect that for the history digging purposes ;-) If you have it around, that would be cool. At times, some archeology helps understanding the more obscure areas... I'll try to find a place for that, it's pretty big; would be worth stripping the .sdf's and also I am not 100% sure if I added the tarballs of various things, or if I did not ;-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Caolan, On 2010-12-09 at 20:08 +, Caolán McNamara wrote: AA: + write tooling to retain history across repo moves (Kendy) I suppose its silly to look into rewriting our existing history by tracking back through the various old svn and cvs workspace branch systems to determine who committed the various changes that ended up getting bundled into the old-style releng mega commits. Wishful thinking I guess. Actually, I still might have the cvs - git import I did 2-3 years back that tracked all the branches, and also marked the integration commits as merges; if there'd be more demand for that, I could try to resurrect that for the history digging purposes ;-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Jan Holesovsky wrote: Actually, I still might have the cvs - git import I did 2-3 years back that tracked all the branches, and also marked the integration commits as merges; if there'd be more demand for that, I could try to resurrect that for the history digging purposes ;-) If you have it around, that would be cool. At times, some archeology helps understanding the more obscure areas... Cheers, -- Thorsten pgpWbTnzAL72I.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 ...
On Wed, 2010-12-15 at 18:27 +0100, Jan Holesovsky wrote: Actually, I still might have the cvs - git import I did 2-3 years back The source cvs repos are still around and online, right ?, i.e. :pserver:anon...@anoncvs.services.openoffice.org:2401/cvs C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Thu, 2010-12-09 at 18:18 +, Michael Meeks wrote: AA: + write tooling to retain history across repo moves (Kendy) I suppose its silly to look into rewriting our existing history by tracking back through the various old svn and cvs workspace branch systems to determine who committed the various changes that ended up getting bundled into the old-style releng mega commits. Wishful thinking I guess. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2010-11-26 at 14:07 +, Caolán McNamara wrote: On Fri, 2010-11-26 at 11:14 +, Michael Meeks wrote: + crashes on exit + vile threading issue in destructors + a choice of memory corruption / crashes either way AA: + correct fixes coming [ Caolan working on it ] Done. Fixed this up and at least for me now exit on windows is crash-free, backported from master to 3-3 as well. Beautiful :-) I cherry picked the quickstarter patch, and multi-migration fixes too to libreoffice-3-3 - since no-one complained about them on master yet. I guess it's just up to Kendy for RC1, and I need to prod at NSIS (somehow). Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
