Minutes of ESC call

classic Classic list List threaded Threaded
7 messages Options
Jan Holesovsky-4 Jan Holesovsky-4
Reply | Threaded
Open this post in threaded view
|

Minutes of ESC call

* Present: Christian, Bjoern, David, Kendy, Miklos, Moggi, Adam, Miklos, Michael S., Lionel, Norbert, Stephan,
  Cedric, Andras, Robinson

* Completed Action Items
    + File an MAB for install issues (Kendy)
        + https://bugs.freedesktop.org/show_bug.cgi?id=74934
 
* Pending Action Items:
    + GSOC mentors - prune / remove already done ideas from each side (All)
    + need design for copying styles between templates (Cor Nouws/other UX?)
        cf. http://www.mail-archive.com/libreoffice-ux-advise@.../msg01658.html
            http://www.mail-archive.com/libreoffice-ux-advise@.../msg01663.html
        [ Astron made mockup, discussed with Cor, but not published yet ]
    + will try filing a lot of small string changes as easy hacks (Astron)
    + review HiDPI branch for 4.2 (Kendy, Michael, Caolan)
 
* Release Engineering update (Christian)
    + 4.1.5 RC3 status
        + released now, closed
    + 4.2.1 RC1 / final status
        + announced today, went public
    + 4.2.2 will be what was 4.2.1.2 rc2
        + did not change
        + deadline for the 4.2.2 did not change
    + future schedule - should we ~always do that ?
    + MAB:
        + 2 are more serious: https://bugs.freedesktop.org/50855
        + will try to bi-bisect it [Christian]
    + suggested change to the release plan: 4 weeks between .0 and .1, 5 weeks between .1 and .2
        + sounds good [Bjoern]
        + didn't we have even shorter .0 and .1? - ie. sounds good to me too :-) [Kendy]
        + 4.3 just before the conference, might be tricky [Bjoern]
AI      + agreed, Christian will update the wiki [Christian]
    + some patches in 4-2-1 branch
AI      + should be cherry-picked to 4-2-2 [Christian]
 
* UX update (Astron)
    + discussion about how to use sidebars in the future
    + new sifr theme: lots of people love that [Bjoern]
        + but some people would like to have it a bit lighter for dark themes
        + could we have some sifr-light for dark themes? [Bjoern]
        + based on gnome, possible to re-color on the fly [Astron]
        + some of them available only as png's [Astron]
          http://www.omgubuntu.co.uk/2014/01/libreoffice-4-2-new-icon-theme (see comments)
        + hi-dpi sifr version? [Astron]
        + would it make sense to exchange hicontrast with sifr-light? [Kendy]
            + concerns about accessibility [Bjoern]
            + not clear to me if the colors in the hicontrast are needed, or if the white as
              the base color is what is most needed there [Kendy]
        + no objection to sifr-light in general
 
* GSoC update (Cedric)
    + Google review starting / underway
    + please consider what you are able to mentor:
        + https://wiki.documentfoundation.org/Development/GSoC/Ideas
    + cleanup still needed - everyone should review the page
    + we will have answer from Google on Monday
    + after that, students can reach us, by Monday evening it has to be perfect
AI  + Cedric to poke people who haven't done any action there
 
* Crashtest update (Markus)
    + new crash-test / data (?)
        + http://dev-builds.libreoffice.org/crashtest/f3d93434829d0e7c004679d000c30a934083b188/
    + will produce new one over the weekend
    + 15 fixes: real impact! - you can fix hundreds of documents
        + most of that can be fixed by pointer check
        + so easy stuff, go for that! :-)

* Problems in image scaling code (Markus)
    + can we use openmp there?  anybody against?
    + nobody familiar here probably :-) [Miklos]
    + gcc and visual studio both support that [Markus]
    + easy to use [Markus]
    + go for that - I guess you know most of that anyway [Kendy]
 
* ODF TC / how we handle ODF proposals (Miklos)
    + typically developers add new features, and create an ODF extension
    + ideally leads to proposal that should be sent to the ODF TC
    + includes extending RelaxNG + description
        + follow-up was handled by Thorsten previously
        + has to be done in Jira, where only some people have access
        + some follow-up questions answering
        + ie. cannot be done by every developer
        + Thorsten cannot do that any more
    + do we have people who have access these days?
        + 2 people active now: Regina [TDF], Michael S. [RedHat]
    + Michael S. will talk to Thorsten
        + Michael S. could act as a proxy at least, hopefully
 
* GNU make, upstreaming stuff (Bjoern)
    + cleaned up branches, now at:  https://gerrit.libreoffice.org/gitweb?p=gnu-make-lo.git
    + dependency caching: parsing of deps down to 0.6 seconds from 6 seconds on Linux (branch feature/depcache)
    + need testing on Windows - incremental builds
AI      + Kendy to try it on his tinderbox
    + sugggested to upstream:
      http://lists.gnu.org/archive/html/bug-make/2014-02/msg00055.html
 
* Certification update (Kendy/Bjoern/Stephan)
    + we should start a new round
 
* QA (Robinson/Bjoern)
    + ciabot/libreoffice-bugzilla.pl bot got confused a bit with 4.2.1 :-)
       + if it hurts you, please check the git log & comment in the bug [Bjoern]
    + Bugzilla Migration update
       + Local VM for testing Bugzilla, Joel helping
    + NeedAdvice bug list
       + on the QA's radar
       + should QA CC people there?
           + there are few sitting there for months, want to have the list clean
           + remove those that are not serious, poke people on IRC for the serious ones? [Kendy]
       + Addressing bugs sitting in this category
 
         https://bugs.freedesktop.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&list_id=385735&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&version=4.1.1.1%20rc&version=4.1.1.2%20release&version=4.1.2.1%20rc&version=4.1.2.2%20rc&version=4.1.2.3%20release&version=4.1.3.1%20rc&version=4.1.3.2%20release&version=4.1.4.1%20rc&version=4.1.4.2%20release&version=4.1.5.1%20rc&version=4.1.5.2%20rc&version=4.1.5.3%20release&version=4.1.6.1%20rc&product=LibreOffice
 
* QA stats:
 
Querying overall / top bug stats
  + https://bugs.freedesktop.org/page.cgi?id=weekly-bug-summary.html
    +193    -170        (+23 overall)
    many thanks to the top bug squashers:
        Jorendc             18
        tommy27             16
        Kohei Yoshida       14
        Caolán McNamara     11
        mariosv             10
        Maxim Monastirsky    8
        Artur Dryomov        8
        Patrick Ohly         7
        Michael Stahl        7
        Adolfo Jayme         4
        Foss                 4
 
* Open 4.2 MAB
  + 17/99 18/97 19/95 18/85 17/70 17/65 17/59 21/58 15/45 14/38
     17%   18%   20%   21%   24%   26%   28%   36%   33%   37%
  + https://bugs.freedesktop.org/showdependencytree.cgi?id=65675&hide_resolved=1
 
* Open 4.1 MAB
  + 80/197 37/149 37/149 34/144 34/142 36/142 33/138 32/137 32/136 29/130
     40%    24%    24%    23%    23%    25%    23%    23%    23%    22%
  + https://bugs.freedesktop.org/showdependencytree.cgi?id=60270&hide_resolved=1
 
* Open 4.0 MAB
  + 4/166 49/211 52/211 54/212 52/210 52/208 52/208 55/208 56/208 55/208
     2%    23%    24%    25%    24%    25%    25%    26%    26%    26%
  + https://bugs.freedesktop.org/showdependencytree.cgi?id=54157&hide_resolved=1
 
* Bibisected bugs open: whiteboard 'bibsected'
  + 40/180 42/180 42/179 43/178 43/176 44/176 44/175 44/170 46/169 48/169 48/168
    + http://bit.ly/VQfF3Q
 
* all bugs tagged with 'regression'
    + 335(+0) bugs open of 2326(+19) total
    * ~Component   count net *
           Writer - 87 (+1)
      Spreadsheet - 59 (+4)
      Libreoffice - 28 (-1)
     Presentation - 25 (-2)
         Database - 21 (+0)
          Crashes - 20 (+0)
          Drawing - 15 (-1)
          Borders - 13 (-1)
            BASIC -  5 (+1)
        Migration -  3 (+0)
  + http://bit.ly/15mM2Yn - for devs ( no NEEDINFO / UNCONFIRMED )
  + https://bugs.freedesktop.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&resolution=---&query_format=advanced&product=LibreOffice&list_id=36764
  + Migration: https://bugs.freedesktop.org/showdependencytree.cgi?id=43489&hide_resolved=1



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

Jan Holesovsky wrote:
> * Problems in image scaling code (Markus)
>     + can we use openmp there?  anybody against?
>     + gcc and visual studio both support that [Markus]
>     + easy to use [Markus]
>
Another piece to look at are intel's TBB, which in my mind are _much_
more idiomatic for c++ code. I'm always reminded of fortran when I see
openmp code. ;)

For vcl/source/gdi/* - that is clearly rife of inefficiencies & funny
algorithms. A plan back in the day was to replace code there with
calls to basebmp stuff one by one, though somehow I never got to
it. But it would be nice to have _one_ place for filtering & image
scaling, instead of three in vcl, one in each application, and one in
basebmp.

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (985 bytes) Download Attachment
Noel Grandin Noel Grandin
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

On 2014-02-21 16:21, Thorsten Behrens wrote:

> Jan Holesovsky wrote:
>> * Problems in image scaling code (Markus)
>>      + can we use openmp there?  anybody against?
>>      + gcc and visual studio both support that [Markus]
>>      + easy to use [Markus]
>>
> Another piece to look at are intel's TBB, which in my mind are _much_
> more idiomatic for c++ code. I'm always reminded of fortran when I see
> openmp code. ;)
>
> For vcl/source/gdi/* - that is clearly rife of inefficiencies & funny
> algorithms. A plan back in the day was to replace code there with
> calls to basebmp stuff one by one, though somehow I never got to
> it. But it would be nice to have _one_ place for filtering & image
> scaling, instead of three in vcl, one in each application, and one in
> basebmp.
>


Wasn't there a plan at one point to make use of Cairo and/or Pixman for such things?

I would have thought they'd have pretty efficient versions of stuff like that by now.

Disclaimer: http://www.peralex.com/disclaimer.html


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Tomaž Vajngerl Tomaž Vajngerl
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

In reply to this post by Thorsten Behrens
Hi,

On Fri, Feb 21, 2014 at 3:21 PM, Thorsten Behrens
<[hidden email]> wrote:

> Another piece to look at are intel's TBB, which in my mind are _much_
> more idiomatic for c++ code. I'm always reminded of fortran when I see
> openmp code. ;)
>
> For vcl/source/gdi/* - that is clearly rife of inefficiencies & funny
> algorithms. A plan back in the day was to replace code there with
> calls to basebmp stuff one by one, though somehow I never got to
> it. But it would be nice to have _one_ place for filtering & image
> scaling, instead of three in vcl, one in each application, and one in
> basebmp.
>
> Cheers,
>
> -- Thorsten

Actually, I think we need SIMD implementations of image scalers if we
really want speed. We already have pixman (needed by cairo) which has
SIMD optimized image scalers available (and with latest versions also
high quality SIMD image scalers) - somebody just needs to integrate
it.

Regards, Tomaž
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

Noel Grandin wrote:
> Wasn't there a plan at one point to make use of Cairo and/or Pixman
> for such things?
>

Tomaž Vajngerl wrote:
> Actually, I think we need SIMD implementations of image scalers if we
> really want speed. We already have pixman (needed by cairo) which has
> SIMD optimized image scalers available (and with latest versions also
> high quality SIMD image scalers) - somebody just needs to integrate
> it.
>
Yeah. Though legacy vcl has some weird formats to support still. But
at least a number of critical paths could be re-routed to pixman (I
would do that in basebmp though - simply because the semantics are
much clearer defined in that code).

Something else to keep an eye on:

 https://github.com/MetaScale/nt2/tree/master/modules/boost/simd

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (985 bytes) Download Attachment
Tor Lillqvist-2 Tor Lillqvist-2
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

>> We already have pixman (needed by cairo)

Except that cairo is used only on one of our supported platforms.

--tml
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of ESC call

On 21/02/14 21:27, Tor Lillqvist wrote:
>>> We already have pixman (needed by cairo)
>
> Except that cairo is used only on one of our supported platforms.

... which actually makes this more problematic: on Mac and Windows we
can just build internal pixman but on Linux either we have to restrict
usage to RHEL5-era pixman or statically link an internal one to prevent
conflicts with system cairo due to ELF's stupid global namespace.



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice