minutes of ESC call ...

classic Classic list List threaded Threaded
17 messages Options
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

minutes of ESC call ...

* Present:
        + Stephan, Sophie, Caolan, Heiko, Kendy, JanI, Thorsten
           Markus, Miklos, Olivier, Michael M, Eike, Christian,
           Michael S, Bjoern, Bubli, Norbert
 
* Completed Action Items:
    + add GDI object use count to crash reporter (Michael)
    + turn gcc -Og on for a bit and see how it goes (Michael S)
        [ turned on; a few complaints – but no show-stopping concerns yet.
          It can happen that variables are not displayed; and optimized out,
          mostly it happens for non-live variables.
          Can see in frame 17 – some var optimized out, frame 18 can be seen there.
             + very hard to see boolean variables optimized out (Markus)
                 + don't care wrt. a enable-debug build, but a dbgutil build should be the best.
          Not debugged calc code - perhaps it it is worse there (Michael S)
              + configure tinderboxes to use this - gives nice stack traces. ? (Michael M)
                 + concern wrt. full traces currently printing variables - mangling that (Miklos)
                 + would need a reproducible scenario.
                     + can try to find it again in an hour-long debugging session (Markus)
              => disable when we have a concrete bug report.
    + ask Tamás Bunth how he feels about Firebird default (Lionel)
        [ lots of firebird bugs appear to be being fixed - great (Michael) ]
 
* Pending Action Items:
    + provide information for cloph on what the large Help change is (Olivier)
        + need a diff of the kind of string change, so Cloph can write a script.
    + poke at MSDN licenses (Michael)
        [ internal conversation ongoing ]
    + move gitdm-config to gerrit (Norbert)
        [ not happened yet, missing Norbert ]
    + investigate https://beta.opendocumentformat.org/testsets/all/en (Xisco)
    + improve QA Stats in the ESC minutes (Xisco)
 
* Release Engineering update (Christian)
    + 5.2.4.2 - next week, done by Jan
            + Venetian language: request to add.
                + made a gerrit change request; do we want to have it ?
                + already enabled on master & 5.3 - unlikely to break things.
                   https://gerrit.libreoffice.org/#/c/31727/
                => just merge it.
    + 5.3.0 Beta2 & branch today, libreoffice-5-3-0 branch with rc2
        + waiting for pootle to do template updates
           + must be something wrong with VM / KVM
           + can't get that going.
        + need to have a B2 for bug-hunting at the weekend.
        + Late features:
            + separating images and icons for help modules (Olivier, Bubli)
                + still waiting for Olivier's sample string change to write the script.
                    + we need to see the impact on translators.
            + misc. PDF signing / embedding bits (Miklos)
                + now completed - and all fixes back-ported
    + Android & iOS Remote (Cloph)
        + master is green now.
        + will prepare a new build based on the branch-off tag
    + online (Michael)
        + branched for -5-3 – will create source tarballs.
 
* Documentation (Olivier)
     + important patch from Bubli that need to go in 5.3
         + separating images and icons for help modules
              + https://gerrit.libreoffice.org/#/c/30958/
              + https://gerrit.libreoffice.org/#/c/30959/
                => defer and script properly for master; re-visit next week.
                        + Cloph has script templates
                                + but needs examples of the changes to the UI files.
      + Next: Will test screenshots make enabled by bubli
           ( https://wiki.documentfoundation.org/Documentation/Screenshots )
      + 12/8 the Getting Started Guide for 5.0 is released by the Brazilians
                + http://documentation.libreoffice.org/pt-br/portugues/guia-do-iniciante/
                + Blog post in local blogs, PR, new documentation website ready.
                      + https://pt-br.blog.documentfoundation.org/
                + Community seeking more work
      + writing a spec. for BOD.
 
* UX Update (Heiko)
 + Bugzilla (topicUI) statistics
       256(256) (topicUI) bugs open, 494(494) (needsUXEval) needs to be evaluated by the UXteam
   + Updates:
       BZ changes   1 week    1 month    3 months   12 months  
            added      2(-5)     16(-5)     61(-4)     489(-3)
        commented     14(-40)   187(-48)   926(-61)   2793(-32)
          removed      0(0)       1(0)      24(-2)      30(0)  
         resolved      6(-1)     17(1)     115(3)      133(5)  
   + top 10 contributors:
         Heiko Tietze made 40 changes in 1 month, and 515 changes in 1 year
         *UNKNOWN* made 13 changes in 1 month, and 13 changes in 1 year
         Samuel Mehrbrodt made 13 changes in 1 month, and 50 changes in 1 year
         *UNKNOWN* made 12 changes in 1 month, and 101 changes in 1 year
         Yousuf Philips made 11 changes in 1 month, and 408 changes in 1 year
         *UNKNOWN* made 11 changes in 1 month, and 22 changes in 1 year
         Rene Engelhard made 10 changes in 1 month, and 10 changes in 1 year
         Tor Lillqvist made 8 changes in 1 month, and 9 changes in 1 year
         V Stuart Foote made 5 changes in 1 month, and 193 changes in 1 year
         *UNKNOWN* made 5 changes in 1 month, and 5 changes in 1 year
  + quiet days, working on color palette blog post

* Crashtest update (Caolan)
    + 2 import failure, 6 export failures
        - only 1 svg import failure fixed
    + 16 coverity.
         + engaging with Google on ossfuzz
             + accepted our project.
             + need to merge in work from Caolan to make it run.
             + start with one file format to see how it goes.

* TDF / Budgeting / Brainstorming (Thorsten)
    + Idea generation:
    + Community Building feature / fix / tooling
    + Quality improvement tooling
    + Hard / dull but necessary stuff not getting done
    + Large missing features / function
         + Thoughts:
                + IDE / simpler building (JanI)
                + More CI hardware to get quicker build-times (Noel)
                     + consider cloud hardware cost; scale on-demand ? (Bjoern)
                + Image handling re-work (Michael)
                + have some ideas (Thorsten)
                + patch update code (Markus)
                     + allow pushing patches, lots of details to sort out
                     + have a FOSDEM talk for this in the dev-room
                     + talk to releng & devs there @ the hack-fest.
                     => not sure it will work out as a tender; already 70% done.
                     + Windows & Linux ~done; no Mac so not tested
                + post Macs to people (Michael)
                + Accessibility improvements (Bubli / Michael)
                + User Metrics - would like real user data (Heiko)
                + 32bit icon creation (Heiko)
                + HSQLDB binary format migration (Michael)
                + finishing online help -> make it actually online (Kendy)
                     + finishing the XHP generating JS, sort out translations,
                        ensure it works off-line with searching; and finally killing help viewer.
                     + ideally also online editor (that would upload patches to gerrit)
                        + tender submitted for BoD (Olivier)
                + split signing from the build process (Norbert)
                     + so post-build sign it.
                + 5.5 idea - re-thinking how we install language-packs (Markus)
                     + if we have an auto-updater with signed MAR files.
                     + could provide translated installer, and download rest during install.
                     + signing is done on the whole archive with this approach.
                + Improved scripting debugging (Michael)
                     + awesome like browser ... built-in XRay
                     + finish the API discovery/self-documentation by Bjoern
                + SmartArt - missing feature (Michael)
                + Better integration of extensions (Heiko)
                     + Design-team page of topics for GSOC (Heiko)
                + unwind EMF+/WMF disaster area (Thorsten)
                + Improve the look of the SDK (Bjoern)
                     + undo hugely painful gnumake-ness etc.
                     + make it much more usable, and ideally from IDEs.
         + Ideally prefer to have stuff tried in GSOC first (Thorsten)
               + only fund it if it is really not going to get done.
AI:     + create & publish a wiki page for this (JanI)
                   https://wiki.documentfoundation.org/Development/Budget2017 
         + could we have a 'tips' scheme (Heiko)
               + KDE side, use pay-pal only https://www.kde.org/fundraisers/yearend2016/
               + sounds like re-inventing freedom sponsors (Bubli)
               + if this happens - do it outside the foundation to avoid issues (Norbert)
               + like barnstars but with a financial 'tip' - is the idea.
 
* Hackfests (Bjoern)
    + next venues / suggestions
    + 33c3 CfP open (Bjoern):
              + https://events.ccc.de/2016/09/01/call-for-participation-33rd-chaos-communication-congress-en/
        + FSFE will be there, we can meet up with them.
    + FOSDEM - confirmed dev-room (Michael)
        +     3rd Feb 2017 - board (+MC) meetings.
        + 4th/5th Feb 2017 - core FOSDEM dates
        + 6th/7th Feb 2017 - Hackfest at Beta Coworking.
                  + http://www.bedfordhotelcongresscentre.com/ suggested instead of Astrid.
        + Lightning Talks on the day:
                       => tell Thorsten if you have a plan.
 
* mentoring/easyhack update (janI)
   + openhub statistics based on analysis from 2016-11-29
     1598(1598) people did in total: 443675(443675) commits in 8301307(8301307) lines of code
     284(284) people did in 12 month: 15495(15495) commits
   + gerrit/git statistics:
       committer...   1 week     1 month     3 months    12 months  
               open      35(4)       56(3)       63(3)        63(3)  
            reviews     503(149)   1384(146)   3626(143)   17630(170)
             merged     236(-12)    850(35)    2312(125)    8678(150)
          abandoned      12(0)       48(2)      142(5)       650(1)  
            commits     307(21)    1315(-3)    4007(144)   15568(52)
       contributor...   1 week    1 month     3 months    12 months  
                 open      20(-2)     44(2)       49(4)        49(4)  
              reviews     606(1)    1917(156)   4713(287)   17750(316)
               merged      31(2)     122(10)     367(14)     1311(24)
            abandoned       5(-3)     18(2)       51(0)       401(-15)
              commits      71(15)    256(15)     881(20)     4125(27)  
   + easyHack statistics:
      needsDevEval 18(18)   needsUXEval 4(4)   cleanup_comments 192(192)  
      total 235(235)   assigned 14(14)   open 197(197)
   + received patches from 5 emails the last month without license statement
   + top 5 contributors:
         Gabor Kelemen made 41 patches in 1 month, and 145 patches in 1 year
         Zdenek Crhonek made 22 patches in 1 month, and 307 patches in 1 year
         Bartosz Kosiorek made 16 patches in 1 month, and 27 patches in 1 year
         Mark Page made 11 patches in 1 month, and 31 patches in 1 year
         Lera Goncharuk made 6 patches in 1 month, and 6 patches in 1 year
   + top 5 reviewers:
         jan iversen made 172 review comments in 1 month, and 1688 in 1 year
         Markus Mohrhard made 134 review comments in 1 month, and 1638 in 1 year
         Noel Grandin made 132 review comments in 1 month, and 1242 in 1 year
         Eike Rathke made 106 review comments in 1 month, and 1292 in 1 year
         Caolán McNamara made 82 review comments in 1 month, and 1407 in 1 year
   + big CONGRATULATIONS to contributors who have at least 1 merged patch, since last report:
       ** Removed this week, due to rework **

   + worked on gitdm licenses, we all need to be more careful when
           merging and check that the author has submitted a license.
   + We need to start a discussion on the objective for mentoring
           + growing disconnect between:
                  + what I see/read from contributors and
                  + what experienced developers tell is missing.
           + Maybe we should have a “headhunter” instead of a “mentor”.
           + eg. a big discussion this morning: is an IDE useful for new developers.
                  + is the objective - to get new people in from Universities ?
                       + train to be core developers or ...
                  + or do we want experinced developers from day #1
           + do we need an IDE when people can start day#1 ?
                  + what JanI sees from universities.
                  + surely IDE integration helps everyone (Michael)
                       + experienced devs use IDE, but can also run 'make'.
            + Complete IDE integration is really hard (Norbert)
                  + phenomenal problems for a complete build here (Michael)
                  + core issue: can we move canonical builds away from 'make' ? (Bjoern)
                       + if we get to some point like this - kill the old one ASAP.
                       + a different build system needs to completely replace the old one,
                       + have enough advantage to replace the old one.
                  + a new person: (JanI)
                       + git clone LODE - half day & full-day before you can code.
                       + has nothing to do with make - but requiring cygwin & config (Bjoern)
                           + and not supplying an IDE solution in our repo. (JanI)
                           + want to have a solution for XYZ IDE - needs manual maintenance (Bjoern)
                               + by definition not cross-platform; generated from 'make' or ... diverging duplication.
                  + someone creating e.g. a Visual Studio extension that does all the cygwin/git clone/gerrit bootstrapping would be much appreciated though (Bjoern)
                  + make when it runs on windows - takes 300Mb of memory (Norbert)
                       + have an IDE - with sol'n with everything in it -> takes a long time to load.
                           + most likely an IDE killer.
+ (also, reproducing all custom dependencies around UNO registries, l10ntools etc. will be a pain -- and a maintanance horror) (Bjoern)
            + eg. a pre-canned bundle with pre-built 'externals' and pre-canned VS file made from make (Michael)
            => come up with a good compromise proposal for next time (JanI)
 
* Re-organising which rules tests run under (Markus, Michael S, David)
         + unfortunately - spent last week debugging a11y (Michael S)
              + been running with the patch himself
         + https://gerrit.libreoffice.org/#/c/31075/
         + https://gerrit.libreoffice.org/#/c/31075/
             + an annoying problem - we have a serialization point to stop big libraries linking in parallel
                   + to help small laptops.
                   + with all tests depending on services.rdb
                   + while large libraries are linekd one after another; v. little runs in parallel with that.
                   + build takes a minute or two longer
                   + prolly not an improvement - espcially for CI.
            + is there a better way ? (Michael M)
                   + eg. service dependencies.
                   + the 30 component files in the makefiles is the issue (Michael S)
            + make - wants to first build all objects before linking the 1st library (Michael S)
            + still have external deps hard-coded 'make -j1' eg. NSS (Norbert)
            + what's a plan ?
                    + move half the tests to subsequentcheck ?
                    + create macros for subsets of tests ? (Michael)
                          + have for the whole module the same set of component files ? (Markus)
                              + automatically take them from the module definition ?
                          + in calc/impress/writer (Michael S)
                             + testing embedded objects - needing other components.
                             + could special-case these tests (Markus)
            + would like to parallelise linking for CI (Norbert)
            + screenshot / dependency bits failing on windows (Norbert)
                 + make clean ; make screenshot - systematically fails on lpsolver.
AI:                 + file a bug report ? (Norbert)
            => abandon until there is something people want to merge.
 
* Commit Access

* Developer Certification (Stephan/Bjoern/Kendy/Thorsten)
    + sleeping 1 week.

* Jenkins / CI update (Norbert)

   from:Thu Dec  1 16:22:54 2016
   master linux rel  jobs: 199 ok: 189 ko:   9 fail ratio:  4.52 % break:   6 broken duration: 1.95%
   master linux dbg  jobs: 151 ok: 130 ko:  21 fail ratio: 13.91 % break:  10 broken duration:10.07%
   master mac rel    jobs: 171 ok: 162 ko:   9 fail ratio:  5.26 % break:   8 broken duration: 3.19%
   master mac dbg    jobs: 178 ok: 161 ko:  17 fail ratio:  9.55 % break:   7 broken duration: 6.48%
   master win rel    jobs: 129 ok: 121 ko:   8 fail ratio:  6.20 % break:   6 broken duration: 2.65%
   master win dbg    jobs: 128 ok: 112 ko:  16 fail ratio: 12.50 % break:   6 broken duration: 9.18%
   master win64 dbg  jobs: 136 ok: 123 ko:  13 fail ratio:  9.56 % break:   5 broken duration: 6.75%
   lo-5.2 mac        jobs:  18 ok:  18 ko:   0 fail ratio:  0.00 % break:   0 broken duration: 0.00%
   lo-5.1 mac        jobs:   0 ok:   0 ko:   0 fail ratio:  0.00 % break:   0 broken duration: 0.00%
   branch gerrit all jobs:  30 ok:  28 ko:   2 fail ratio: 6.67%
   master gerrit lin jobs: 350 ok: 321 ko:  29 fail ratio: 8.29%
   master gerrit plg jobs: 347 ok: 253 ko:  94 fail ratio:27.09%
   master gerrit win jobs: 355 ok: 198 ko: 156 fail ratio:43.94%
   master gerrit mac jobs: 353 ok: 280 ko:  71 fail ratio:20.11%
   master gerrit all jobs: 352 ok: 155 ko: 192 fail ratio:54.55%
         + Fairly normaly; spike in Linux debug - needs investigation.
 
* Hardware issues (Michael)
         + Mac
                  + can live without the swiss macs (Norbert)
                  + how can we get them posted to people ? (Cloph)
                       + taxes determined by weight, etc.
                       + who has access to the data-center ?
AI:              + poke Florian to encourage posting of Macs (Cloph)
                  + would be useful to have a Mac - have some pending theming issues (Kendy)
                  + who else needs a Mac ? ... answers on a post-card.
 
* l10n (Sophie)
    + LibreOffice Online pot files hasn’t been uploaded for 7 weeks
         + huge performance issues, will have an upgrade next week on Thursday.
               + hope this will solve the perf. problem.
         + translate.za - are working on this (Cloph)
               + doing some test migrations on their systems, if issues - will fix it.
               + plan is for Thur. if they can solve the performance issues, so down-time expected to be hours.
         + database needs to be migrated to the new schema (Cloph)
               + the transition to it is the thing that is slow.

* Testlink (Sophie)
     + testing this to replace MozTrap
         + it does localized test descriptions.

* QA update (Björn)

  + bragged a bit about QA response time/quota:
    https://twitter.com/Sweet5hark/status/806552914307190784

    + Third Bug Hunting Session – LibreOffice 5.3.0 Beta2
        * December 9 and 10, 2016 ( 2 days this time )
        * https://wiki.documentfoundation.org/QA/BugHuntingSession/5.3.0Beta2

    + UNCONFIRMED: 518 (-14)
        + enhancements: 44 (-3)
        + needsUXEval: 5 (+1)
        + haveBackTrace: 15 (-1)
        + needsDevAdvice: 37 (0)
 
    + Most Pressing Bugs: http://tdf.io/mostressingbugs
            + macOS: newly created Base files cause crash in mdworker
                + https://bugs.documentfoundation.org/show_bug.cgi?id=104083
            + macOS: libreoffice crash on startup, VCL thread mutex condition
                + https://bugs.documentfoundation.org/show_bug.cgi?id=103690
            + FILEOPEN: DOCX: Chart bars not imported
                + https://bugs.documentfoundation.org/show_bug.cgi?id=103963
                    + fixed: thanks to Markus.
                    + 2 problems reported in the bug. Most critical one already fixed.
                    + Severity and Priority lowered. Can be deleted from this list now.
            + no app-icon regression:
                + https://bugs.documentfoundation.org/show_bug.cgi?id=103626
            + macOS: LO closed then opening any document by double-click never...
                + https://bugs.documentfoundation.org/show_bug.cgi?id=77444

    + Mail merge regressions: http://tdf.io/mmregressions
        + 4 open; 4 open last meeting (2 OSX, 1 Linux, 1 generic but hard repro)
                  => drop from the QA section from now - always four.

* QA stats

  + https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html
   +178    -120        (+58 overall)
    many thanks to the top bug squashers:
        Buovjaga              20
        Telesto               13
        Aron Budea             9
        Xisco Faulí            8
        m.a.riosv              7
        Alex Thurgood          7
        V Stuart Foote         5
        Caolán McNamara        5
        Justin L               4
        Cor Nouws              4
        tommy27                3
        Miklos Vajna           3
        Eike Rathke            3
        Heiko Tietze           3
        Mark Hung              3

* Highest-Priority bugs (aka "MABs"):
        5.2: 2/22   -  9%
        5.1: 2/32   -  6%
        5.0: 3/57   -  5%
        4.4: 5/74   -  6%
        4.3: 4/69   -  5%
        4.2: 6/132  -  4%
        4.1: 3/79   -  3%
        4.0: 5/82   -  6%
        old: 29/247 - 11%

        + http://bit.ly/2dp3mwC

* Bisected bugs open: keyword 'bisected'
    + more accurate - down to a single commit.
    + 305/1101 303/1087 292/1061 261/1015 261/1003 261/996 259/988 245/891
       + http://bit.ly/2dyIfDy

* Bibisected bugs open: keyword 'bibisected'
    + 381/1633 378/1618 366/1593 348/1557 350/1545 352/1538 351/1530 345/1516
        + http://bit.ly/2cSCXlS

* all bugs tagged with 'regression'
    + 732(+10) bugs open of 5494(+32) total 11(-3) high prio.

        * ~Component   count net * high severity regressions
           LibreOffice - 3 (+0)
                  Base - 3 (-1)
      filter / storage - 1 (+0)
               Impress - 1 (+0)
                 Chart - 1 (+0)
               Writer  - 1 (-1)
                  Calc - 1 (-1)

                + http://bit.ly/1HWHb3E

                by OS:
                        + Mac     - 5
                        + All     - 4
                        + Windows - 1
                        + Linux   - 1

        * ~Component   count net * all regressions
          Writer: other - 130 (+5)
                   Calc - 113 (-4)
                Impress - 68 (+2)
           Writer: docx - 59 (+0)
            LibreOffice - 54 (+0)
                     UI - 41 (+3)
            Writer: doc - 35 (+3)
         graphics stack - 35 (-1)
                   Base - 33 (-2)
                   Draw - 30 (+1)
                Borders - 27 (-1)
                Crashes - 30 (+0)
       filter / storage - 22 (+3)
         Writer: filter - 20 (+0)
                  Chart - 16 (+0)
     print / PDF export - 14 (-2)
           Writer: perf - 11 (+0)
                  BASIC - 10 (+0)
              framework -  3 (+0)
             Extensions -  2 (+0)
           Installation -  1 (+0)
                    sdk -  1 (+0)
         Formula Editor -  1 (+0)
                + http://bit.ly/1BUdI8i

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

Re: minutes of ESC call ...

Hi,

On Thu, Dec 08, 2016 at 04:56:07PM +0000, Michael Meeks wrote:
>                   + someone creating e.g. a Visual Studio extension that does all the cygwin/git clone/gerrit bootstrapping would be much appreciated though (Bjoern)
> [...]
>             + eg. a pre-canned bundle with pre-built 'externals' and pre-canned VS file made from make (Michael)

... and the core issue with that is the number of different configs we support
even on Windows. While that makes some sense on Linux, where each distro is a
unique snowflake in some way, it makes very little sense on Windows, where most
things should be the same on all systems. Or at least _could_ be the same on
all systems.

I mean, we could have a tinderbox run "./autogen.sh && make
vs2013-ide-integration" once a week and make it commit the result Visual Studio
solutions to the core repo. Note this does _not_ need a full build anymore, so
should be a matter of minutes. But for those to work universally, it requires
tooling that reproduces pretty much exactly as on the canonical tinderbox that
created the solutions, including:

- SRCDIR
- BUILDDIR
- cygwin install

LODE did some great steps in that direction, but I fear is not quite there yet.
If you get Windows builds to kill all those degrees of freedom, then this
should work just fine (including pre-build 'external').

So again: This is less of an build issue, than one of configuration management.

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

Hi Bjoern,

On 08/12/16 17:13, Bjoern Michaelsen wrote:
> I mean, we could have a tinderbox run "./autogen.sh && make
> vs2013-ide-integration" once a week and make it commit the result Visual Studio
> solutions to the core repo.

        Sure - although my ideal flow for a (Windows) newbie here would be:

        * download 'something'
        * load file in Visual Studio
        * ctrl-shift-b to build ... <wait>
        * click the green triangle to debug ;-)

        Where of course that 'something' would need to be constructed by some
tinderbox / slave, and (ideally) contain everything not easily buildable
with the IDE already pre-built =)

        Personally I'd see this as an entry mode: once people have the
satisfaction of seeing their work 'working' they can graduate to
installing cygwin, and <insert other pain points>. Clearly there would
be nothing authoritative about it etc.

        Since the instdir/ is standalone and distributable & runnable as-is
there should be no need for make_installer-ness of any kind;

        AFAICS - there -should- also be no need for cygwin, LODE, or anything
else in this world ;-) just a single download.

        Anyhow - just a thought ;-) not volunteering to do the testing,
packaging work for that deliverable ...

        ATB,

                Michael.

--
[hidden email] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

Hi,

On Thu, Dec 08, 2016 at 05:59:53PM +0000, Michael Meeks wrote:
> Sure - although my ideal flow for a (Windows) newbie here would be:
>
> * download 'something'
    (actually, Visual Studio can directly clone git repos, so manual downloads shouldnt be needed)

> * load file in Visual Studio
> * ctrl-shift-b to build ... <wait>

    E.g. in Kdevelop and QtCreator have global build targets. It should be
    trivial to add to MSVS if someone wants to take ownership of that.

> * click the green triangle to debug ;-)

    Certainly works for kdevelop and used to work for MSVS.

So for C++ targets this already works with essentially just (native) GNU make.
Its all the other plumbing that is causing the pain.

> Where of course that 'something' would need to be constructed by some
> tinderbox / slave, and (ideally) contain everything not easily buildable
> with the IDE already pre-built =)

Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
registry generation plumbing etc. for good? (With kill=port to plain C++ tooling).

 
> Personally I'd see this as an entry mode: once people have the
> satisfaction of seeing their work 'working' they can graduate to
> installing cygwin, and <insert other pain points>. Clearly there would
> be nothing authoritative about it etc.

That would assume to use a pregenerated autoconf output then (as autoconf need
essentially all of POSIX and then some). Possibly -- but not without its own
pain points (ask any Sun engineer, this is was how StarOffice builds were like).

> AFAICS - there -should- also be no need for cygwin, LODE, or anything
> else in this world ;-) just a single download.

Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... in
various corners of the build. Killing those and replacing them with GNU make
and plain C++ would be good, but is quite a thankless effort. I agree though it
would be appreciated to make the build easier to bootstrap.

tl;dr: First kill the POSIX deps sprinkled all over the repo[1], building a bit of
C++ libs isnt the issue.  All the plumbing around it is.

Best,

Bjoern

[1] FWIW, this is why I used a C++ executable for "make gbuildtojson" stuff
    instead of some Python foo.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Samuel Mehrbrodt-3 Samuel Mehrbrodt-3
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-5
Am 08.12.2016 um 17:58 schrieb Michael Meeks:
>     + online (Michael)
>         + branched for -5-3 – will create source tarballs.
Can we start having release notes for Online in the wiki also, as we do
for the desktop ( https://wiki.documentfoundation.org/ReleaseNotes/5.3 )?
Not sure it's better on the same page, or an extra page.

Samuel
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Bjoern Michaelsen
Hi,

some additional thoughts below:

On Thu, Dec 08, 2016 at 07:40:40PM +0100, Bjoern Michaelsen wrote:

> > AFAICS - there -should- also be no need for cygwin, LODE, or anything
> > else in this world ;-) just a single download.
> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
> registry generation plumbing etc. for good? (With kill=port to plain C++ tooling).
> [...]
> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... in
> various corners of the build. Killing those and replacing them with GNU make
> and plain C++ would be good, but is quite a thankless effort. I agree though it
> would be appreciated to make the build easier to bootstrap.
>
> tl;dr: First kill the POSIX deps sprinkled all over the repo[1], building a bit of
> C++ libs isnt the issue.  All the plumbing around it is.

On a more positive and actionable note: With C++11 having regex[1] that
certainly is possible and e.g. Perl-to-C++11 might even be some EasyHacks.
Limiting the tools used in the build system to C++11, GNU make and basic
cross-plattform busybox[2] might be a starting point and allow all of:

- migrating to e.g. using ninja as backend
- migrating away from GNU make (via gbuildtojson and manually recreating the
  bazillion configure-based conditional we have in Makefiles)
- simple bootstrapping on Windows without the need for cygwin or LODE

So while I am reluctant to replace gbuild as the canonical build _right now_,
Im all for killing the custom tooling based on all of coreutils and Perl in
gbuild (and replace it with plain C++11 ... and maybe busybox for a start).
Once that happened, we can consider all the options on where to carry the build
system from there. But locking in one of those options now, with all the
tooling crap still around would be jumping the gun.

So: Who is going to champion the "kill all Perl in the Build" (for a start) EasyHack?

Best,

Bjoern

[1] http://en.cppreference.com/w/cpp/regex
[2] There are at least two native ports:
    https://github.com/rmyorston/busybox-w32
    https://github.com/pclouds/busybox-w32
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...


> On 9 Dec 2016, at 11:35, Bjoern Michaelsen <[hidden email]> wrote:
>
> Hi,
>
> some additional thoughts below:
>
> On Thu, Dec 08, 2016 at 07:40:40PM +0100, Bjoern Michaelsen wrote:
>>> AFAICS - there -should- also be no need for cygwin, LODE, or anything
>>> else in this world ;-) just a single download.
>> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
>> registry generation plumbing etc. for good? (With kill=port to plain C++ tooling).
>> [...]
>> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... in
>> various corners of the build. Killing those and replacing them with GNU make
>> and plain C++ would be good, but is quite a thankless effort. I agree though it
>> would be appreciated to make the build easier to bootstrap.
>>
>> tl;dr: First kill the POSIX deps sprinkled all over the repo[1], building a bit of
>> C++ libs isnt the issue.  All the plumbing around it is.
>
> On a more positive and actionable note: With C++11 having regex[1] that
> certainly is possible and e.g. Perl-to-C++11 might even be some EasyHacks.
> Limiting the tools used in the build system to C++11, GNU make and basic
> cross-plattform busybox[2] might be a starting point and allow all of:
>
> - migrating to e.g. using ninja as backend
> - migrating away from GNU make (via gbuildtojson and manually recreating the
>  bazillion configure-based conditional we have in Makefiles)
> - simple bootstrapping on Windows without the need for cygwin or LODE
Now we are getting very close to my x-mas wishlist.

the current json files made by gbuildjson misses 2 things:
- objective C++ (and some other language) files are not accounted for
- there are no dependency structure (as provided by running “make -d”)

I have been experimenting with a variant of gbuildtojson:
- the gb_macros do not make the C++ program, but makes a simple echo with an identifier
- make is called with “make -d gbuildtojson | gbuildjson.exe
- the C++ program is changed to understand the “make -d” dependency structure, and of course the echo statements.

With that change the json files contains enough information to e.g. generate a new set of makefiles without macros.
 
>
> So while I am reluctant to replace gbuild as the canonical build _right now_,
> Im all for killing the custom tooling based on all of coreutils and Perl in
> gbuild (and replace it with plain C++11 ... and maybe busybox for a start).
> Once that happened, we can consider all the options on where to carry the build
> system from there. But locking in one of those options now, with all the
> tooling crap still around would be jumping the gun.
>
> So: Who is going to champion the "kill all Perl in the Build" (for a start) EasyHack?
It is not fair I just complain without also volunteering :-)

That would be something I would like to do, with a little help from the experts, and provided Norbert has nothing against it.

have a nice weekend
jan I.

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

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-5
On Thu, Dec 08, 2016 at 04:56:07PM +0000, Michael Meeks wrote:
>                   + who else needs a Mac ? ... answers on a post-card.

I think I can make use of one, if it can get here easily. I currently
use the same Mac laptop for both Linux and Mac development, not the most
productive setup.

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

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-5
Hello world

>         + Late features:
>             + separating images and icons for help modules (Olivier, Bubli)
>                 + still waiting for Olivier's sample string change to write
> the script. + we need to see the impact on translators.

I'm slightly reluctant to make this 5.3 late feature, not because of the
impact on translations (which I clarified in another e-mail to Cloph & Olivier)
but because of the impact on how help is packaged on all 3 platforms for TDF
builds and Linux distributions.

For complete separation, every offline help package will now need to come with
extra zip archive with images. This is a non-trivial change and I don't think
it's fair to expect distro packagers to do that kind of work this late in the
game.

For partial separation, a zip archive with help images can be shipped along
with icon themes. The only difference is that the images (misc illustrations
and new screenshots) will have moved from core to help git repository. This is
presumably less work for the packagers, but it adds some load still ...

--

Katarina Behrens

Softwareentwicklerin LibreOffice
–––
CIB software GmbH
Geschäftsstelle Hamburg
Flachsland 10
22083 Hamburg
–––
T +49 (40) / 28 48 42 -235
F +49 (40) / 28 48 42 -100

[hidden email]
www.cib.de
–––
Sitz: München
Registergericht München, HRB 123286
Geschäftsführer: Dipl.-Ing. Ulrich Brandner
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Bjoern Michaelsen
Hi Bjoern,

On 08/12/16 18:40, Bjoern Michaelsen wrote:
>> * download 'something'
>     (actually, Visual Studio can directly clone git repos, so
>      manual downloads shouldnt be needed)

        Sure - question is if we want to check all the un-buildable binaries
into a git repository; but we can do of course if it saves having a
shell to download things.

>> * click the green triangle to debug ;-)
>
>     Certainly works for kdevelop and used to work for MSVS.

        Great - so we're nearly there.

>> Where of course that 'something' would need to be constructed by some
>> tinderbox / slave, and (ideally) contain everything not easily buildable
>> with the IDE already pre-built =)
>
> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
> registry generation plumbing etc. for good? (With kill=port to plain C++ tooling).

        For me at least, none of that is relevant. We can pre-generate all of
that and include it pre-built inside the 'something' that is downloaded.

>> Personally I'd see this as an entry mode: once people have the
>> satisfaction of seeing their work 'working' they can graduate to
>> installing cygwin, and <insert other pain points>. Clearly there would
>> be nothing authoritative about it etc.
>
> That would assume to use a pregenerated autoconf output then (as autoconf need
> essentially all of POSIX and then some). Possibly -- but not without its own
> pain points (ask any Sun engineer, this is was how StarOffice builds were like).

        Sure there are pain-points; and it is a rather artificial setup that is
proposed - a newbie / starting developer setup. Having said that - you
can get a -very- long way with just editing C++ files in a tree with
pre-build python, ICU, etc. etc.

>> AFAICS - there -should- also be no need for cygwin, LODE, or anything
>> else in this world ;-) just a single download.
>
> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... in
> various corners of the build.

        Sure - and this then becomes an incremental task ;-) -iff- doing this
generates interest from lots of new developers, which it might, then I
suspect we get a set of manpower with motivation to make more and more
of the code easily accessible on Windows ;-)

        ATB,

                Michael.

--
[hidden email] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

Hi,

On Fri, Dec 09, 2016 at 08:57:03PM +0000, Michael Meeks wrote:
> Sure - question is if we want to check all the un-buildable binaries
> into a git repository; but we can do of course if it saves having a
> shell to download things.

Well, we could have the binaries in a submodule, so as not to pollute sane
environemnts. Maybe?

OTOH, since we are abondoning good taste anyway: We could also have all the
cygwin install as an image download, instead of bothering with installers
and setups -- AFAICR cygwin can be dumped pretty easily anywhere without much
need for "installers". Just mirroring a fixed cygwin install without bothering
for installer etc. might already kill a lot of the hurtful degrees of freedom.
 
> For me at least, none of that is relevant. We can pre-generate all of
> that and include it pre-built inside the 'something' that is downloaded.

You will spend more time discussing why e.g. (naive, not fully intentional) UNO
changes break the world in this setup than you will gain, I guess. I dont
think the target audience is aware at all about UNO or what "you cant do
incompatible changes" would mean. Note UNO is just one example here.
 
> Sure there are pain-points; and it is a rather artificial setup that is
> proposed - a newbie / starting developer setup. Having said that - you
> can get a -very- long way with just editing C++ files in a tree with
> pre-build python, ICU, etc. etc.

You can get a long way with just editing C++ files in the gerrit UI. Or with
Clophs pre-build remote Hackfest VM (which should probably include an IDE and
solutions e.g. kdevelop now). The question is what we achieve with that. There
seem to be two goals here:

1/ getting a newcomer to create their first patch ASAP
2/ becoming a somewhat selfsufficient contributor to LibreOffice

For 2/ getting a local Visual Studio setup might help a bit, while for 1/ both
Hackfest VMs and gerrit webediting are a lot better suited. Then again, we dont
see a lot of failure between 1/ and 2/, but we are hearing stories of untapped
possibilities that dont even get to 1/.

> Sure - and this then becomes an incremental task ;-) -iff- doing this
> generates interest from lots of new developers, which it might, then I
> suspect we get a set of manpower with motivation to make more and more
> of the code easily accessible on Windows ;-)

Fighting the dependency explosion is valuable in itself: Mostly because
"migrate tooling to be more native" is quite EasyHack-suitable and there might
be talent able to do it that wouldnt be able to contribute to core development
anyway ...

Best,

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

Re: minutes of ESC call ...

In reply to this post by Katarina Behrens
Katarína Behrens wrote:
> I'm slightly reluctant to make this 5.3 late feature, not because of
> the impact on translations (which I clarified in another e-mail to
> Cloph & Olivier) but because of the impact on how help is packaged
> on all 3 platforms for TDF builds and Linux distributions.
>
Right - and the question is, what does it buy us anyway for 5.3, given
that new helpcontent / extra images will only happen on master after
string freeze?

Cheers,

-- Thorsten

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

signature.asc (968 bytes) Download Attachment
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] minutes of ESC call ...

In reply to this post by Michael Meeks-5
Michael Meeks wrote:
> * TDF / Budgeting / Brainstorming (Thorsten)
>     + Idea generation:
>     + Community Building feature / fix / tooling
>     + Quality improvement tooling
>     + Hard / dull but necessary stuff not getting done
>     + Large missing features / function
>                 + have some ideas (Thorsten)
>
Added to https://wiki.documentfoundation.org/Development/Budget2017

Cheers,

-- Thorsten

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

signature.asc (968 bytes) Download Attachment
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by jan iversen
Hi,

On Fri, Dec 09, 2016 at 11:45:56AM +0100, Jan Iversen wrote:
> Now we are getting very close to my x-mas wishlist.
>
> the current json files made by gbuildjson misses 2 things:
> - objective C++ (and some other language) files are not accounted for

Thats trivial to add and left as an excerise to the reader.

> - there are no dependency structure (as provided by running “make -d”)

There is: linked libs and linked static libs provide that for a 10000 feet
view. Of course its a simplification, because that is the whole point of the
gbuildtojson execise: Leaving out all the cornercases and shortcuts to have
something simplified that can be translated.

> - the gb_macros do not make the C++ program, but makes a simple echo with an identifier

That will likely explose on some platforms sooner rather than later due to
shell length limits. There is a reason we use var2file, the reasons for which
can be painfully exermined in the git log.

> - make is called with “make -d gbuildtojson | gbuildjson.exe

That will produce huge amounts of output and thus be very slow. Also it
reintroduces parsing GNU make output directly, which we are by now more than
aware to be fragile and prone to breaking. Better to cause the output of "make
gbuildtojson" to provide the needed info properly. The whole point of
gbuildtojson is to have some stable output and NOT be broken by (make-)version
specific behaviour.

> With that change the json files contains enough information to e.g. generate
> a new set of makefiles without macros.

So, generate makefiles from makefiles, because ... well, why? We have so far
successfully avoided the common autotools-style madness of creating generated
intermediate makefiles. Debugging those usually is a huge PITA.

Doing that is a kludge that was historically needed in the early 1990 as there
where a bazillion incompatible makes that where broken in many different ways.
Anyone having to deal with it hated it and will until the end of their life.
Those days are over and we can depend on GNU make being available (or portable)
everywhere. Thus generated makefiles should really really be avoided.

As of now, the only valid reason left for generated build files is the performance
of some backend tools (e.g. ninja) by having better caching/intermediate formats for
the (huge) dependency graph we produce. Ninja alone wont replace GNU make, so
we would still be using both, and we would need good reasons to justify the
inevitable "my ninja build does weird stuff, let me try to debug 200KLOC of
generated build instructions we threw at it"-fun it will yield.

Hint: Thus if we consider ninja as a backend for the build system with
performance as argument to use it, we would need some good hard cold number on
how much better ninja is at that.

However, this is shifting goalposts -- the original argument was about how hard
it is for a newcomer to get an initial build setup on Windows (still) and none
of this is helping with any of that (Steamlining LODE and documentation would,
however).

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] minutes of ESC call ...

In reply to this post by Michael Meeks-5
Michael Meeks wrote on 08-12-16 17:56:
>     + Mail merge regressions: http://tdf.io/mmregressions
>         + 4 open; 4 open last meeting (2 OSX, 1 Linux, 1 generic but hard repro)
>                   => drop from the QA section from now - always four.

Counting 5 at the moment.


--
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger http://nl.libreoffice.org
- volunteer http://www.libreoffice.org
- The Document Foundation Membership Committee Member
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] minutes of ESC call ...

Hi,
On Thu, Dec 15, 2016 at 12:19:54PM +0100, Cor Nouws wrote:
> Michael Meeks wrote on 08-12-16 17:56:
> >     + Mail merge regressions: http://tdf.io/mmregressions
> >         + 4 open; 4 open last meeting (2 OSX, 1 Linux, 1 generic but hard repro)
> >                   => drop from the QA section from now - always four.
>
> Counting 5 at the moment.

Yes, but the rationale was the extraordinary number of MM regressions we had
during the cleanup of the old (really horrible) code. That major cleanup is
finishe for the most part now, activity in the area is back to normal, so no
justification anymore to highlight MM regressions over regressions elsewhere.

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: [Libreoffice-qa] minutes of ESC call ...

Hi Bjoern,

Bjoern Michaelsen wrote on 15-12-16 19:10:

> Yes, but the rationale was the extraordinary number of MM regressions we had
> during the cleanup of the old (really horrible) code. That major cleanup is
> finishe for the most part now, activity in the area is back to normal, so no
> justification anymore to highlight MM regressions over regressions elsewhere.

Ah, sure makes sense.
Thanks for explaining,

Ciao - Cor


--
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger http://nl.libreoffice.org
- volunteer http://www.libreoffice.org
- The Document Foundation Membership Committee Member
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice