minutes of ESC call ...

classic Classic list List threaded Threaded
25 messages Options
Next » 12
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

minutes of ESC call ...

* Present:
    + Norbert, Michael M, Lionel, Christian, Jan-Marek, Eike, Andras,
      Caolan, Bjoern JanI, Kendy, Markus, Olivier, Stephan, Sophie,
      Miklos, Thorsten, Xisco, Heiko, Michael S, Rene, David
 
 * Completed Action Items:
    + dig out tooling on license verification for JanI (Michael)
        [ open action items, move gitdm-config to gerrit (jani)
          hard work, gone back in the git log and need 500 aliases ]
 
* Pending Action Items:
    + poke at MSDN licenses (Michael)
        [ a friend is looking at the topic - only needed for OS' ]
 
* Release Engineering update (Christian)
    + 5.2.4 RC1 status - Nov 29th
        + next week; JanI on it.
           +  actually Cloph, I am on RC2 (janI)
    + 5.3.0 Beta1 & branch
        + tagged and built; available on early-testing.
        + request for Beta2 - that changed the API etc.
            + probably there will be a Beta2
            + do we need a new Beta2 ? (Michael)
                + on the branch already for 5-3 etc.
        + build-dir != src_dir fix in gerrit (Cloph)
            + patched locally.
        + translations pulled from pootle Mon/Tue
        + please cherry-pick all fixes to -5-3 from master (and 5-2)
        + beta1 is full languages; LibreOfficeDev variant for parallel install
            + not string freeze yet, translations might change.
        + Late features:
            + misc. PDF signing / embedding bits (Miklos)
                + Linux/macOS part is ready, some Windows fixing ongoing.
            + ODF / XFastParser merge (Michael)
                + looking a bit late -> don't think will have time.
            + Firebird by default ? (Lionel)
                + lots of missing features & big bugs fixed recently.
                + all of the blockers that were mentioned on tracking bug fixed.
                    + still not hyper-excited about it as default.
                    + agreed, build issues on OS/X until recently (Norbert)
                => suggest to enable this on master for 5.4
AI:                 + ask Tamás Bunth (Wastack) how he feels about it (Lionel)
    + Android & iOS Remote (Cloph)
        + tinderbox breakage, fixed
        + preparing a new build based on the branch-off tag -> app-store tomorrow.
    + online (Michael)
        + have a script to run before branching
        + still debugging that; expect a branch tonight.
 
* UX bits / palette licensing (Heiko/Rene)
  + is there a back-compat problem removing palettes ? (Heiko)
      + I thought not, cf. minutes passim (Michael)
  + Color palletes have been revised, Breeze added, Tango and HTML reworked
  + Libreoffice palette with branding colors should get a better naming
    + http://nabble.documentfoundation.org/Renaming-the-LibreOffice-colors-td4200352.html
    + https://bugs.documentfoundation.org/show_bug.cgi?id=104053
    + Color names: https://en.wikipedia.org/wiki/List_of_colors_(compact)
  + Remove palettes cmyk, web, gallery, palette and scribus (tdf#104047, gerrit 31009)
  + Add artwork under CC-ND license (tdf#104052; palette CIE-HLC aka LibreColor)
      + currently realized as a hard-coded part in the programme
        + this was reverted by Tor (Rene)
      + if we don't accept a non-free CC-ND license - use an extension (Heiko)
      + if it is explicitly stated as ND (Rene)
          + has to be removed in Debian & other Linux distributions
      + significant risk to have it (Thorsten)
          + to ensure it doesn't get modified over time.
      + mixing lots of licenses is a pain (Bjoern)
      + encourage this guy to create an extension ? (Heiko)
      + for artwork CC0, or code general MPLv2 ideal (Kendy)
          + refused various times (Rene)
          + rational - prevent people changing the pallete & using the name (Norbert)
                                (but license wrong tools for the job)
      + how vital is this feature / palette ? (Michael)
          + palette used by experts for professional work (Heiko)
             + majority of users will never user it.
          + we like professional users (Norbert)
      + no way to put it into an extension at the moment (Stephan)
          + thought one of these exists already (Heiko)
      => can't include CC-ND things -> another solution needed.
          + rename, and provide as a file under a project license ?
          + provide as code instead; ok with this one ? (Heiko)
              + concern that it can't be manipulated by the user.
              + always will have some stuff not modifiable by user (Rene)
                  + ok with the patch sol'n.
          + or find another way.
  + thanks for catching the issue (Michael)
  + Add more palettes?
    + https://en.wikipedia.org/wiki/List_of_software_palettes
 
* Documentation (Olivier)
     + New Help patches by Christina Accione, Gabor Kelemen, tagezi, Olivier Hallot
     + ES-documentation team woke up, translating guides
     + TDF internal activities.
     + 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/
         + is it related to leakage of PNGs leaked into /tmp ? (Norbert)
             + not related, will look into it (Thorsten)
                + related to concerns wrt. screenshots of help.
                + moving that to the help repo.
         + why not just push it ? (Michael)
             + get it in as a 5.3 late-feature (Thorsten)
                 + discuss again when Bubli is back.
         + screenshot re-generation for all-lang takes time (Cloph)
             + would love a stamp-file to avoid re-generating them.
     + pt-BR and es communities working in docmentation websites
         + http://documentation.libreoffice.org/es/ and
         + http://documentation.libreoffice.org/pt-BR/
 
* UX Update (Heiko)
  + Bugzilla (topicUI) statistics
       257(257) (topicUI) bugs open, 490(490) (needsUXEval) needs to be evaluated by the UXteam
   + Updates:
       BZ changes   1 week   1 month     3 months    12 months    
            added      6(-1)    16(-148)    65(-737)    487(-1392)
        commented     98(90)   247(146)    989(541)    2814(1589)
          removed      0(-1)     2(-67)     26(-113)     30(-325)
         resolved      0(0)     39(0)      110(0)       122(0)    
   + top 10 contributors:
         Heiko Tietze made 58 changes in 1 month, and 523 changes in 1 year
         Yousuf Philips made 21 changes in 1 month, and 410 changes in 1 year
         jan iversen made 18 changes in 1 month, and 82 changes in 1 year
         V Stuart Foote made 12 changes in 1 month, and 199 changes in 1 year
         *UNKNOWN* made 12 changes in 1 month, and 156 changes in 1 year
         *UNKNOWN* made 10 changes in 1 month, and 10 changes in 1 year
         Rene Engelhard made 10 changes in 1 month, and 10 changes in 1 year
         Björn Michaelsen made 8 changes in 1 month, and 26 changes in 1 year
         Samuel Mehrbrodt made 7 changes in 1 month, and 45 changes in 1 year
         Sophie Gautier made 6 changes in 1 month, and 8 changes in 1 year
   + not a huge amount happened in the last week.
   + fixes on pallettes, and one from Thorsten.
   + but the stats are great thanks to JanI, Xisco etc.
 
* Crashtest update (Caolan, no update)
    + 0 import failure, 1 export failures
         + looking good again.
         + intermittent issue related to images being
           pulled across the net.
              + looking into disabling net access in the test.
    + 20 coverity.
         + downward trend from new warnings, with a few interesting bits.
 
* MintForum/MintTag Hamburg update
    + Bjoern not there; next time someone should go.
 
* 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.
        + opportunity to do workshops there
        ** Tomorrow - last day to book, poke Bjoern **
    + 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://bedfordhotelcongresscentre.com/ suggested instead.
        + CfP going out at some stage.
                        + CfP has been out for a while and ends early December. (jani)
                        + https://blog.documentfoundation.org/blog/2016/11/04/fosdem-call-for-papers-open-document-editors-devroom/
        + collect talks nearer the event.
 
* mentoring/easyhack update (janI)
   + openhub statistics based on analysis from 2016-11-19
     1596(1596) people did in total: 443559(443559) commits in 8296169(8296169) lines of code
     287(287) people did in 12 month: 15608(15608) commits
   + gerrit/git statistics:
       committer...   1 week     1 month     3 months    12 months    
               open      34(10)      56(1)       60(-1)       60(-1)  
            reviews     390(94)    1261(30)    3590(-81)   17455(49)  
             merged     155(-6)     742(-48)   2098(42)     8370(56)  
          abandoned      14(6)       40(3)      137(6)       637(0)  
            commits     291(-49)   1362(-19)   3975(-5)    15652(-104)
       contributor...   1 week    1 month    3 months    12 months  
                 open      16(1)      37(-2)     44(-1)       44(-1)
              reviews     447(94)   1581(-8)   4253(127)   17135(167)
               merged      34(11)    104(14)    356(-5)     1294(28)
            abandoned       2(0)      12(-3)     48(2)       420(-5)
              commits      64(11)    229(7)     887(-6)     4109(7)  
   + Distribution of people based on number of merged patches:
      + removed due to comments
   + easyHack statistics:
      needsDevEval 18(18)   needsUXEval 4(4)   cleanup_comments 189(189)  
      total 233(233)   assigned 14(14)   open 196(196)  
   + received patches from 3 emails the last month without licesense statement
   + top 5 contributors:
         Zdenek Crhonek made 25 patches in 1 month, and 297 patches in 1 year
         Gabor Kelemen made 22 patches in 1 month, and 122 patches in 1 year
         Bartosz Kosiorek made 12 patches in 1 month, and 23 patches in 1 year
         melike made 7 patches in 1 month, and 14 patches in 1 year
         andreas_kainz made 6 patches in 1 month, and 17 patches in 1 year
   + top 5 reviewers:
         jan iversen made 168 review comments in 1 month, and 1655 in 1 year
         Markus Mohrhard made 137 review comments in 1 month, and 1602 in 1 year
         Eike Rathke made 120 review comments in 1 month, and 1276 in 1 year
         Noel Grandin made 109 review comments in 1 month, and 1190 in 1 year
         Caolán McNamara made 96 review comments in 1 month, and 1419 in 1 year
   + big CONGRATULATIONS to contributors who have at least 1 merged patch, since last report:
         Christina Accione
         Owen Genat
 
   + Changed https://wiki.documentfoundation.org/Development/Developers
       to reflect the state of the page
   + new WELCOME mail, asking people to update the wiki.
   + gitdm-config work
 
* Deprecate osl::Condition ? (Michael)
    + https://bugs.documentfoundation.org/show_bug.cgi?id=104126
   + extraordinarily hard to write or audit correct code
       + C++11 has std::condition_variable - with a pthread style API.
    + if it works with all compilers - great for internal code (Stephan)
       + careful wrt. URE files - can't have a C++11 requirement in exposed URE headers
           + internal impl. of URE is fine.
       + always careful not to depend on details of the C++ ABI.
       + for any internal code - if it works with the whole toolchain: go for it.
    + impl. is a typedef for a void so could replace (Michael S)
       + API is part of the problem kill it (Stephan, Michael M)
 
* Pivot-Tables / UNO / API evolution (Eike)
   + current state looks good (Eike)
      + new feature will work.
   + what needs clarification in future: when & how to break stable API
      + if not absolutely necessary - don't do it.
      + adding a new constant is more work & more ugly.
   + new interface / Function2 bits is uglier for the API users (Stephan)
      + will there be further extensions of that list of functions ?
          + yes ? (Michael)
          + perhaps not (Eike)
      + if this is the only change this century - say go with incompatible change (Stephan)
          + if will be further additions likely; perhaps pay the price now.
   + dug at why addition to enums is incompatible (Kendy)
      + fail to see why we should consider it incompatible.
      + from semantic POV - fair cop.
      + but everything we do is controlled by us
          + code generated, JARs we generate from newer version.
      + can generate some odd code here - that would cause issues.
      + with normal use-cases; get a value of enum, do something, put it back.
          + reasonably transparent.
      + perhaps some scenario fails; if someone tries to cast random integers into
         enums or no real technical reason not to extend an enum.
          + problem with out-of-process Java code & older JAR file (Stephan)
             + if you bundle JAR file with ext'n or app - have an issue (Kendy)
      + mostly a moot discussion wrt. danger of extending it (Stephan)
          + using constant-groups instead.
      + Function - to a Constant Group ? (Thorsten)
          + already done etc.
      + Concern wrt. tone on each side (Thorsten, Michael)
          + revert first and then discuss seems reasonable close to branch (Norbert)
      + real problem is the UNO API used internally (Markus)
          + long-term solution - to get rid of UNO API for internal code.
          + happy to see this separated (Eike)
      + could get the XPropertySet / Any to accept different types incoming (Michael)
          + doesn't help so much for reading.
      + What is the view wrt. changing byte-code we generate ? (Kendy)
          + from 5.3 or 5.4 - so we can change the enums safely.
          + codemaker magic - that needs some modification ?
              + no-one looked into the .Net binding (Stephan)
                  + don't see a way to change the Java code.
                  + need an object representing that value
                  + don't see the value.
          + if we hit a place where an incompat way is preferred (Stephan)
              + we just do that.
          + enum situation in the past was a hard-wall (Kendy)
              + larger API changes - asking consider changes here.
              + in the future -> say - add a FUTURE_ITEMS (Michael)
                  + then people get warned; we never emit this etc.
              + not sure we get anything here, but if want to do it - why not ? (Stephan)
      => anyone welcome to look into improving this.
      + FWIW - Tamas' spare-time fun improvement (Michael)
      + concern that we consider 3rd party apps carefully as we move ahead (Thorsten)
 
* GSoC mentor summit update (Markus/Thorsten)
    + at the mentor summit a few weeks ago.
    + Google socialising a few changes.
        + should enlarge and improve the programme.
    + failing students is perfectly ok; it is expected.
        + shouldn't feel terrible about that: pwrt. failing early
 
* Moving tests to make subsequentcheck? (Markus, Michael S, David)
    + bit concerned wrt. moving most of the tests out of 'make all' (Markus)
        + see lots of less experienced people - starting, who try to avoid the tests.
        + if not forced to execute tests, won't do it at all.
        + during the weekend: less experienced people - tell people to use nocheck builds.
        + moving most of tests out of a normal make - make it worse.
    + can we punt it to next week ? (Michael S)
        + reason why we want to move them - they're not really unit tests.
        + not different from JUnit tests we already have in subsequentcheck
            + they are more stable, well maintained (Markus)
                + also much easier to debug.
                + not easier to debug (Michael S)
                    + particularly not the file import/export tests.
                + all in one process, with stack traces (Michael M)
                + still hard to localise a defect (Michael S)
    + driving force - complexity of Makefile dependencies (Stephan)
        + lots of tests have manually maintained lists of UNO components (Michael S)
            + 20-30 entries in these lists
            + some depende on resource files
            + people add new tests, which fail intermittently on jenkins
                + with missing dependencies.
            + sometimes when a component is missing (Miklos)
                + sometimes code is changed to live without it.
                + so code gets more unhelpful, since we mistake integration tests as units.
         + seen embedded object test succeed (Michael S)
             + missing the component for embedded objects.
    + some tests have the symbols needed to be really units (Michael)
         + ucalc etc.
    + as long as gerrit / jenkins all do 'make check' (Stephan)
         + fine with moving & taking out of the normal make.
         + non-experienced devs go via gerrit -> have the safety-net still.
         + what is the status ?
             + Windows + Linux, not Mac (Michael S)
    + we loose insight into newbie's build tree state (Markus)
         + one guy on Sunday with a broken OCL impl. not found if tests not run.
         + on gerrit - when it fails; a tendency - people ignore its red (Norbert)
             + concern that it gets ignored even more.
    + a plan (Markus)
        + if we can't depend on services.rdb - remove the problem with the UNO component files
        + put them into the 'make all' build.
        + create a new subsequent_half_check ? (Stephan)
    + add the tests to slowcheck - included in a plain make instead ? (Stephan)
    + concern wrt. bots - that we want to get tests run earlier (Norbert)
        + some tests take uni-processor 7 minutes, and can't interleave those with compilation
        + same problem for both proposals (Stephan)
        + if we have this issue - just need to split offending tests (Michael S)
            + tests that take 7 mins - a problem themselves (Bjoern)
                + in dbgutil builds - things get slower (Markus)
    + another detail (Eike)
        + 'make sc' - to just build one module.
            + this should have all the basic checks enabled as now.
    + perhaps best sol'n is a subsequent-half check (Michael)
    => punt 2 weeks, and/or to the list.
    + https://gerrit.libreoffice.org/#/c/31075/
 
* Commit Access

* Developer Certification (Stephan/Bjoern/Kendy/Thorsten)
    + sleeping 3 weeks.

* Jenkins / CI update (Norbert)

   from:Thu Nov 17 16:01:44 2016
    master linux rel  jobs: 198 ok: 176 ko:  22 fail ratio: 11.11 % break:   6 broken duration:15.50%
    master linux dbg  jobs: 151 ok: 124 ko:  25 fail ratio: 16.56 % break:  15 broken duration:21.16%
    master mac rel    jobs: 167 ok: 159 ko:   8 fail ratio:  4.79 % break:   5 broken duration: 7.15%
    master mac dbg    jobs: 170 ok: 162 ko:   8 fail ratio:  4.71 % break:   5 broken duration: 7.66%
    master win rel    jobs: 132 ok: 126 ko:   6 fail ratio:  4.55 % break:   5 broken duration: 8.89%
    master win dbg    jobs: 139 ok: 133 ko:   6 fail ratio:  4.32 % break:   5 broken duration: 8.67%
    master win64 dbg  jobs: 142 ok: 134 ko:   7 fail ratio:  4.93 % break:   4 broken duration: 7.20%
    lo-5.2 mac        jobs:  14 ok:  14 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:  24 ok:  23 ko:   1 fail ratio: 4.17%
    master gerrit lin jobs: 281 ok: 228 ko:  52 fail ratio:18.51%
    master gerrit plg jobs: 279 ok: 196 ko:  82 fail ratio:29.39%
    master gerrit win jobs: 278 ok: 178 ko:  99 fail ratio:35.61%
    master gerrit mac jobs: 275 ok: 229 ko:  45 fail ratio:16.36%
    master gerrit all jobs: 293 ok: 138 ko: 154 fail ratio:52.56%
   
    prob for Windows/Mac (case *preserving* filesystems rather) tinderboxes:
        14fc834aebdf4de9276a93e9f595b150a86ee16f
        file got renamed to same name, just different case
        → cannot switch branches / before ←→ after the change
        → need separate repositories
 
* Hardware issues (Michael) -> punt to next week.
    + Khaled - Windows
    + Mac -> x5 issue.
 
* l10n (Sophie) -> punt to next week.
 
* QA update (Xisco)
 
    + File format roundtrip regressions etc. (Xisco)
      => ~33 new regressions found since 4.4 in the corpus (~1000 files?)
      => that's over 2 years -- so 1 regression per month
      => should be run regularly, as quick fixing should be less painful
      => almost all those were filter:{doc,docx,rtf}, but not tagged as such (fixed now) (Bjoern)
      => so the stats for "Writer: other" below should be back down again now/next week (Bjoern)
 
          + interested in avoiding future regressions with a set of known-good files
                + so we can catch future problems,
 
          + 20-30 found in two years (Bjoern)
                + seems like a big jump this week - but just one per month
                + hopefully find and fix them faster in future.
 
         + started to test impress yesterday
                + tool not capable of doing draw or calc documents.
                + Milos implemented the tool for writer
 
    + Bug Hunting Sesion 5.3.0 beta1 - Nov 25th
        + if there's any feature you want to be tested added it to:
        + https://wiki.documentfoundation.org/QA/BugHuntingSession/5.3.0Beta1#What_to_test
 
    + UNCONFIRMED: 537 (-25)
        + enhancements: 40 (-2)
        + needsUXEval: 2 (+2)
        + haveBackTrace: 15 (-2)
        + needsDevAdvice at 34 (-3)
 
    + Most Pressing Bugs: http://tdf.io/mostressingbugs
        + 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
        + macOS: CRASH newly created Base files cause crash in mdworker ...
                + https://bugs.documentfoundation.org/show_bug.cgi?id=104083
        + EDITING - opening any previous Base file in LO5233 corrupts the file
                + https://bugs.documentfoundation.org/show_bug.cgi?id=104107
                                    + Closed as RESOLVED WORKSFORME
        + 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

* QA stats

  + https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html
    +169    -100        (+69 overall)
    many thanks to the top bug squashers:
        V Stuart Foote        19
        Khaled Hosny          10
        Alex Thurgood          8
        Xisco Faulí            6
        Buovjaga               6
        Caolán McNamara        5
        Olivier Hallot         4
        Eike Rathke            4
        Aron Budea             4
        Julien Nabet           3
        Timur                  3
        tommy27                2
        Markus Mohrhard        2
        Thorsten Behrens (CIB) 2
        Telesto                2

* Highest-Priority bugs (aka "MABs"):
        5.2: 1/20   -  5%
        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: 4/79   -  5%
        4.0: 5/82   -  6%
        old: 20/247 - 11%

        + http://bit.ly/2dp3mwC

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

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

* all bugs tagged with 'regression'
    + 703(+34) bugs open of 5420(+54) total 9(+4) high prio.

        * ~Component   count net * high severity regressions
                  Base -  2 (+1)
                  Calc -  2 (+1)
           LibreOffice -  2 (+1)
               Writer  -  1 (+0)
               Impress -  1 (+0)
                 Chart -  1 (+1)
                + http://bit.ly/1HWHb3E

               ** 50% Mac specific bugs now **

        * ~Component   count net * all regressions
          Writer: other - 142 (+21)
                   Calc - 116 (+4)
                Impress - 62 (+3)
            LibreOffice - 53 (+1)
           Writer: docx - 40 (-1)
                     UI - 38 (+3)
         graphics stack - 37 (-4)
                   Base - 32 (+2)
                   Draw - 29 (+0)
            Writer: doc - 26 (+0)
                Borders - 27 (+0)
                Crashes - 26 (+5)
       filter / storage - 18 (+0)
         Writer: filter - 17 (+6)
                  Chart - 16 (+4)
     print / PDF export - 16 (+3)
                  BASIC - 10 (+0)
           Writer: perf -  9 (+1)
              framework -  3 (+1)
             Extensions -  3 (+0)
           Installation -  1 (+0)
                    sdk -  1 (+0)
         Formula Editor -  1 (-1)
                + http://bit.ly/1BUdI8i
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Tamás Zolnai Tamás Zolnai
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

Hi,

> * Pivot-Tables / UNO / API evolution (Eike)
>    + current state looks good (Eike)
>       + new feature will work.
>    + what needs clarification in future: when & how to break stable API
>       + if not absolutely necessary - don't do it.
>       + adding a new constant is more work & more ugly.
>    + new interface / Function2 bits is uglier for the API users (Stephan)
>       + will there be further extensions of that list of functions ?
>           + yes ? (Michael)
>           + perhaps not (Eike)
>       + if this is the only change this century - say go with incompatible change (Stephan)
>           + if will be further additions likely; perhaps pay the price now.
>    + dug at why addition to enums is incompatible (Kendy)
>       + fail to see why we should consider it incompatible.
>       + from semantic POV - fair cop.
>       + but everything we do is controlled by us
>           + code generated, JARs we generate from newer version.
>       + can generate some odd code here - that would cause issues.
>       + with normal use-cases; get a value of enum, do something, put it back.
>           + reasonably transparent.
>       + perhaps some scenario fails; if someone tries to cast random integers into
>          enums or no real technical reason not to extend an enum.
>           + problem with out-of-process Java code & older JAR file (Stephan)
>              + if you bundle JAR file with ext'n or app - have an issue (Kendy)
>       + mostly a moot discussion wrt. danger of extending it (Stephan)
>           + using constant-groups instead.
>       + Function - to a Constant Group ? (Thorsten)
>           + already done etc.
>       + Concern wrt. tone on each side (Thorsten, Michael)
>           + revert first and then discuss seems reasonable close to branch (Norbert)
>       + real problem is the UNO API used internally (Markus)
>           + long-term solution - to get rid of UNO API for internal code.
>           + happy to see this separated (Eike)
>       + could get the XPropertySet / Any to accept different types incoming (Michael)
>           + doesn't help so much for reading.
>       + What is the view wrt. changing byte-code we generate ? (Kendy)
>           + from 5.3 or 5.4 - so we can change the enums safely.
>           + codemaker magic - that needs some modification ?
>               + no-one looked into the .Net binding (Stephan)
>                   + don't see a way to change the Java code.
>                   + need an object representing that value
>                   + don't see the value.
>           + if we hit a place where an incompat way is preferred (Stephan)
>               + we just do that.
>           + enum situation in the past was a hard-wall (Kendy)
>               + larger API changes - asking consider changes here.
>               + in the future -> say - add a FUTURE_ITEMS (Michael)
>                   + then people get warned; we never emit this etc.
>               + not sure we get anything here, but if want to do it - why not ? (Stephan)
>       => anyone welcome to look into improving this.
>       + FWIW - Tamas' spare-time fun improvement (Michael)
>       + concern that we consider 3rd party apps carefully as we move ahead (Thorsten)

Thanks for discussing this, even tough this discussion did not lead to change.
I have only one question for the future, if it ever comes into my mind
to implement something which is related to this DAPI.
Can I have some code pointers from the last 5 years which shows when
it is "absolutely necessary" to break compatibility? To see when it's
acceptable to do such thing.

Thanks,
Tamás
_______________________________________________
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: [Libreoffice-qa] minutes of ESC call ...

Hi Tamás,

On 24/11/16 18:34, Zolnai Tamás wrote:
> Thanks for discussing this, even tough this discussion did not lead to change.

        Ah =) wait until Kendy has considered and implemented his magic
solution here.

> I have only one question for the future, if it ever comes into my mind
> to implement something which is related to this DAPI.

        Fair question.

> Can I have some code pointers from the last 5 years which shows when
> it is "absolutely necessary" to break compatibility? To see when it's
> acceptable to do such thing.

        I think its worth discussing it with the ESC if its significant. I the
call there was support for just extending the existing enum - if we
think that gets us to 100% of cases it will ever be in one (small)
break. TBH - none of us were that sure whether that was the case; I
think if you made a good case that it was just this one item that was
missing - forever, then - we could prolly tweak just that.

        I guess wrt. API breaks - perhaps running a git log on the reference
UNO IDL gives a number of commits:

        $ git log --numstat offapi/type_reference/offapi.idl

        Of course - the functional changes to the implementations ;-) now that
is another matter, and far harder to police of course.

        Personally I think Markus' take - that we shouldn't be using UNO API
for this internal stuff is spot-on - push the API problem to the edge:
but others have different views =)

        Thanks,

                Michael.

--
[hidden email] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
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: [Libreoffice-qa] minutes of ESC call ...

Michael Meeks wrote:
> On 24/11/16 18:34, Zolnai Tamás wrote:
> > Can I have some code pointers from the last 5 years which shows when
> > it is "absolutely necessary" to break compatibility? To see when it's
> > acceptable to do such thing.
>
> I think its worth discussing it with the ESC if its significant.
>
Seconded. And if you look at the type reference history, you notice we
were trying really quite hard not to break published API. It can be
avoided almost all the time.

I'll repeat the point I made during the ESC here: there's a price when
one breaks things (API, work flows, interop) for users - beyond a
certain limit, they consider your project not worth using
anymore. Since the livelihood for a number of people on this list
depends on LibreOffice having more users, instead of having less, I
really rather feel quite strongly about those things.

Cheers,

-- Thorsten

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

signature.asc (968 bytes) Download Attachment
Thorsten Behrens Thorsten Behrens
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:
> Personally I think Markus' take - that we shouldn't be using UNO API
> for this internal stuff is spot-on - push the API problem to the
> edge:
>
Yep. Can't think of an easy way for those silly property APIs, but for
anything involving actual references to instances, using an
rtl::Reference to the implementation object - instead of the abstract
interface - even gives you a nice, iterative migration path.

> but others have different views =)
>
I don't think so.

Cheers,

-- Thorsten

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

signature.asc (968 bytes) Download Attachment
Tamás Zolnai Tamás Zolnai
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Thorsten Behrens-6
2016-11-24 21:30 GMT+01:00 Thorsten Behrens <[hidden email]>:

> Michael Meeks wrote:
>> On 24/11/16 18:34, Zolnai Tamás wrote:
>> > Can I have some code pointers from the last 5 years which shows when
>> > it is "absolutely necessary" to break compatibility? To see when it's
>> > acceptable to do such thing.
>>
>>       I think its worth discussing it with the ESC if its significant.
>>
> Seconded. And if you look at the type reference history, you notice we
> were trying really quite hard not to break published API. It can be
> avoided almost all the time.
>
> I'll repeat the point I made during the ESC here: there's a price when
> one breaks things (API, work flows, interop) for users - beyond a
> certain limit, they consider your project not worth using
> anymore. Since the livelihood for a number of people on this list
> depends on LibreOffice having more users, instead of having less, I
> really rather feel quite strongly about those things.

Hi Thorsten,

I agree with you about that there's a price of breaking things, but I
also see that LibreOffice struggles with regressions and solving
something in ~500 lines of code change instead of ~15 lines means some
new potential regressions.
However it's true that regressions in our core code can be fixed by
ourselves, but regressions coming from API incompatibility can be
fixed only by 3rd party code maintainers (by updating their code or
updating jar files). On the other hand regression in core code affects
all LO users, while API incompatibility affects only those who uses
the specific part of the API.
But, it's OK if this API is working like that (or at least I can't do
anything with that). It just a bit surprising for me. I used other
APIs/SDKs as a user and there it was not a problem if an enum was
extended. I never expected as an SDK user that a published enum will
never change, but those APIs were written in C/C++, so maybe it's
something about Java code.

Best Regards,
Tamás
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

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

On 11/24/2016 11:48 PM, Zolnai Tamás wrote:
> 2016-11-24 21:30 GMT+01:00 Thorsten Behrens <[hidden email]>:
>> Michael Meeks wrote:
>>> On 24/11/16 18:34, Zolnai Tamás wrote:
>>>> Can I have some code pointers from the last 5 years which shows when
>>>> it is "absolutely necessary" to break compatibility? To see when it's
>>>> acceptable to do such thing.
>>>
>>>       I think its worth discussing it with the ESC if its significant.

There is no hard and fast rules which incompatible changes are OK and
what are not---and that is rather by design.  Every case is different,
and every case needs weighing of pros and cons.  So if you run into a
situation where you think you might need an incompatible change, raise
your voice early: on this mailing list, on IRC, in the ESC, or by adding
reviewers to your Gerrit change.

> But, it's OK if this API is working like that (or at least I can't do
> anything with that). It just a bit surprising for me. I used other
> APIs/SDKs as a user and there it was not a problem if an enum was
> extended. I never expected as an SDK user that a published enum will
> never change, but those APIs were written in C/C++, so maybe it's
> something about Java code.

What makes speculation about the consequences of changes in the UNO API
so difficult is that UNO involves more than a single language.  All the
language bindings (C++, Java, Python, .Net, ...) plus the binary UNO
"hub" that interconnects those bindings need to be taken into account.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Lionel Elie Mamane Lionel Elie Mamane
Reply | Threaded
Open this post in threaded view
|

Firebird 3 by default [was: minutes of ESC call ...]

In reply to this post by Michael Meeks-5
On Thu, Nov 24, 2016 at 04:46:29PM +0000, Michael Meeks wrote:

> * Release Engineering update (Christian)
>         + Late features:
>             + Firebird by default ?
>                 + lots of missing features & big bugs fixed recently. (Lionel)
>                 + all of the blockers that were mentioned on tracking bug fixed.(Lionel)

I went over
https://bugs.documentfoundation.org/buglist.cgi?quicksearch=firebird
and added a few open bugs to the blocker bug
https://bugs.documentfoundation.org/51780
based on their description (and NEW instead of UNCONFIRMED status)
only, without reading the bug log in great detail.

>                     + still not hyper-excited about it as default. (Lionel)
>                     + agreed, build issues on OS/X until recently (Norbert)
>                 => suggest to enable this on master for 5.4
> AI:                 + ask Tamás Bunth (Wastack) how he feels about it (Lionel)

Tamás, how do you feel about this? Do you agree with me/us that we
shouldn't but Firebird 3 as the default embedded database for
LibreOffice 5.3 yet? Shall we make the "big jump" right now in the
current 5.4 alpha (master branch), which would be a plan that it will
be ready (including enough time for beta-testers and fixing the bugs
they find and report) in 6 months? Feel up to it?

If you have any bugfix that is not in 5.3 and you think should be, I
encourage you to put the backport on gerrit. It can be as easy as
clicking "cherry-pick" on the gerrit change for master and indicating
there libreoffice-5-3. As usual, put me as reviewer. You can also
checkout a libreoffice-5-3 git tree on you machine, do the cherry-pick
there and then push it to refs/for/libreoffice-5-3 on gerrit.

--
Lionel
_______________________________________________
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 ...

In reply to this post by Michael Meeks-5
Hi,

On Thu, Nov 24, 2016 at 07:02:17PM +0000, Michael Meeks wrote:
> Personally I think Markus' take - that we shouldn't be using UNO API
> for this internal stuff is spot-on - push the API problem to the edge:
> but others have different views =)

FWIW, up to this point we made no distiction between how we handle published
and unpublished interfaces. Maybe now that we have had some cleaning up
published interfaces, it might be the time to reconsider making the barrier to
API break between those two more explicit[1].

Just a thought -- while I know that we (well, OpenOffice) initially
overpublished APIs, I dont know if we handled it more sensible since then, if
there is any value at all in the "published" tag again at this point.

@Stephan: Thoughts?

Best,

Bjoern

[1] And I dont mean "you shall never break published, but you can break the
    world in unpublished" -- but in more nuanced shades.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

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

On 25.11.2016 11:26, Bjoern Michaelsen wrote:

> Hi,
>
> On Thu, Nov 24, 2016 at 07:02:17PM +0000, Michael Meeks wrote:
>> Personally I think Markus' take - that we shouldn't be using UNO API
>> for this internal stuff is spot-on - push the API problem to the edge:
>> but others have different views =)
>
> FWIW, up to this point we made no distiction between how we handle published
> and unpublished interfaces. Maybe now that we have had some cleaning up
> published interfaces, it might be the time to reconsider making the barrier to
> API break between those two more explicit[1].
>
> Just a thought -- while I know that we (well, OpenOffice) initially
> overpublished APIs, I dont know if we handled it more sensible since then, if
> there is any value at all in the "published" tag again at this point.

well there are 2 problems with this:

1) as you mention the "published" tag was introduced > 10 years ago by
   just tagging every single IDL file that existed at the time, so we
   have "overpublished" interfaces - some of these are either
   completely obsolete or of no interest at all to 3rd parties, being
   used only internally

2) on the other hand the current attitude is to never add the
   "published" tag to anything new if it can be at all avoided
   (see for example commit 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2)
   - this likely includes useful interfaces that are sometimes the only
   available way to do something 3rd parties actually want, which means
   they *are* going to be used in practice, published or not

since the goal of the policy is  "we can make incompatible changes
whenever it doesn't affect any 3rd party extension or macro", the
"published" tag is much less useful as guidance than it may appear at
first glance.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Bjoern Michaelsen
On 11/25/2016 11:26 AM, Bjoern Michaelsen wrote:
> FWIW, up to this point we made no distiction between how we handle published
> and unpublished interfaces.

We don't?  At least my impression is that we do take 'published' into
consideration when making informed changes to the API.  (Notwithstanding
all the issues with using 'published' in practice that Michael already
mentioned.)

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

Re: Firebird 3 by default [was: minutes of ESC call ...]

In reply to this post by Lionel Elie Mamane
>>                     + still not hyper-excited about it as default. (Lionel)
>>                     + agreed, build issues on OS/X until recently (Norbert)
>>                 => suggest to enable this on master for 5.4
>> AI:                 + ask Tamás Bunth (Wastack) how he feels about it (Lionel)
>
> Tamás, how do you feel about this? Do you agree with me/us that we
> shouldn't but Firebird 3 as the default embedded database for
> LibreOffice 5.3 yet? Shall we make the "big jump" right now in the
> current 5.4 alpha (master branch), which would be a plan that it will
> be ready (including enough time for beta-testers and fixing the bugs
> they find and report) in 6 months? Feel up to it?

I agree, it would be reasonable to wait a half year. Until that we can
fix the already found and the upcoming bugs, solve the backward
incompatibility. Even if those can be solved quickly we can upgrade to
the c++ API.
That won't be boring, and we can come up with a much clearer driver
which works like a charm.
Though I have no experiences in when should "big jumps" like that happen.

Tamás
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Firebird 3 by default [was: minutes of ESC call ...]

In reply to this post by Lionel Elie Mamane
On Fri, 2016-11-25 at 11:13 +0100, Lionel Elie Mamane wrote:

> On Thu, Nov 24, 2016 at 04:46:29PM +0000, Michael Meeks wrote:
>
> >
> > * Release Engineering update (Christian)
> >         + Late features:
> >             + Firebird by default ?
> >                 + lots of missing features & big bugs fixed
> > recently. (Lionel)
> >                 + all of the blockers that were mentioned on
> > tracking bug fixed.(Lionel)

Is it technically plausible to import migrate existing hsqldb databases
into firebird (without the use of hsqldb/java) ? For example the
flatpak scenario is a LibreOffice without java available and firebird
by default is nice for that, but even nicer would be the ability to
open preexisting hsqlsb databases.

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

Re: Firebird 3 by default [was: minutes of ESC call ...]

On Tue, Nov 29, 2016 at 11:35:56AM +0000, Caolán McNamara wrote:
> On Fri, 2016-11-25 at 11:13 +0100, Lionel Elie Mamane wrote:
>> On Thu, Nov 24, 2016 at 04:46:29PM +0000, Michael Meeks wrote:

>>> * Release Engineering update (Christian)
>>>         + Late features:
>>>             + Firebird by default ?
>>>                 + lots of missing features & big bugs fixed
>>> recently. (Lionel)
>>>                 + all of the blockers that were mentioned on
>>> tracking bug fixed.(Lionel)

> Is it technically plausible to import migrate existing hsqldb
> databases into firebird (without the use of hsqldb/java) ?

It requires making a read-only parser for the HSQLDB "cached" table
data format in another language than Java. Most definitely possible,
the format may even be better documented than "read the source code".

While you are not the first one expressing that wish, I'm not aware of
anybody planning to actually implement that.

The data definition (the name and structure of the tables) is just an
SQL script in the ZIP structure of the .odb, so in principle you just
replay that against Firebird with the firebird engine... The devil is
in the details: If we run into places where the HSQLDB SQL dialect is
not a subset of the Firebird SQL dialect, we'll have to deal with
those places in some way. And suddenly we have to parse, and
"understand", at least to some point, the saved HSQLDB SQL script to
convert it to Firebird SQL. <shrug>

Embedded HSQLDB databases by very old OpenOffice versions don't use
the HSQLDB "cached" table data format, but the data itself was also in
the SQL script. This was changed for performance reasons.

--
Lionel
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky-4 Jan Holesovsky-4
Reply | Threaded
Open this post in threaded view
|

Re: Firebird 3 by default [was: minutes of ESC call ...]

Hi Lionel,

Lionel Elie Mamane píše v St 30. 11. 2016 v 14:55 +0100:

> The data definition (the name and structure of the tables) is just an
> SQL script in the ZIP structure of the .odb, so in principle you just
> replay that against Firebird with the firebird engine... The devil is
> in the details: If we run into places where the HSQLDB SQL dialect is
> not a subset of the Firebird SQL dialect, we'll have to deal with
> those places in some way. And suddenly we have to parse, and
> "understand", at least to some point, the saved HSQLDB SQL script to
> convert it to Firebird SQL. <shrug>

But that sounds that some kind of "best effort" conversion could be
achieved reasonably simply?  Ie. when there is no HSQLDB installed, try
to replay it as you suggested, and only report "You don't have HSQLDB"
in case the replaying failed :-)

All the best,
Kendy

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

Re: Firebird 3 by default [was: minutes of ESC call ...]

On Fri, Dec 02, 2016 at 11:40:27AM +0100, Jan Holesovsky wrote:

> Lionel Elie Mamane píše v St 30. 11. 2016 v 14:55 +0100:

>> The data definition (the name and structure of the tables) is just an
>> SQL script in the ZIP structure of the .odb, so in principle you just
>> replay that against Firebird with the firebird engine... The devil is
>> in the details: If we run into places where the HSQLDB SQL dialect is
>> not a subset of the Firebird SQL dialect, we'll have to deal with
>> those places in some way. And suddenly we have to parse, and
>> "understand", at least to some point, the saved HSQLDB SQL script to
>> convert it to Firebird SQL. <shrug>

> But that sounds that some kind of "best effort" conversion could be
> achieved reasonably simply?  Ie. when there is no HSQLDB installed, try
> to replay it as you suggested, and only report "You don't have HSQLDB"
> in case the replaying failed :-)

For the data structure part, yes. One still needs to read the "cached
format" data without HSQLDB to have the actual data :)

--
Lionel
_______________________________________________
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 ...

In reply to this post by Michael Stahl-2
On Fri, Nov 25, 2016 at 12:02:03PM +0100, Michael Stahl wrote:
> since the goal of the policy is  "we can make incompatible changes
> whenever it doesn't affect any 3rd party extension or macro", the
> "published" tag is much less useful as guidance than it may appear at
> first glance.

So, uhmm, if the current/old use of "published" doesnt service core developers
and doesnt serve UNO users, maybe we should consider making it useful? A
radical step would be to remove the "published" tag everywhere (as we allow
ourselves API changes anywhere already) and then carefully readd them in areas
where we are reasonably sure we dont have to break the API again soon.

Best,

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

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

On 12/16/2016 10:28 AM, Bjoern Michaelsen wrote:

> On Fri, Nov 25, 2016 at 12:02:03PM +0100, Michael Stahl wrote:
>> since the goal of the policy is  "we can make incompatible changes
>> whenever it doesn't affect any 3rd party extension or macro", the
>> "published" tag is much less useful as guidance than it may appear at
>> first glance.
>
> So, uhmm, if the current/old use of "published" doesnt service core developers
> and doesnt serve UNO users, maybe we should consider making it useful? A
> radical step would be to remove the "published" tag everywhere (as we allow
> ourselves API changes anywhere already) and then carefully readd them in areas
> where we are reasonably sure we dont have to break the API again soon.

Which wouldn't change anything, except for some back-and-forth on the
published-ness status.  Published entities /will/ be changed, for
carefully weighed reasons.  And still, IMO, the published-ness of an
entity is a useful rough estimate of the entity's likeliness of change
(for clients) resp. of the acceptability of doing a change (for us as
producer).
_______________________________________________
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: [Libreoffice-qa] minutes of ESC call ...

In reply to this post by Bjoern Michaelsen

On 16/12/16 09:28, Bjoern Michaelsen wrote:

> On Fri, Nov 25, 2016 at 12:02:03PM +0100, Michael Stahl wrote:
>> since the goal of the policy is  "we can make incompatible changes
>> whenever it doesn't affect any 3rd party extension or macro", the
>> "published" tag is much less useful as guidance than it may appear at
>> first glance.
>
> So, uhmm, if the current/old use of "published" doesn't service core developers
> and doesnt serve UNO users, maybe we should consider making it useful ? A
> radical step would be to remove the "published" tag everywhere (as we allow
> ourselves API changes anywhere already) and then carefully readd them in areas
> where we are reasonably sure we dont have to break the API again soon.

        Hmm ! ;-) My concern would be that removing the 'published' tag
everywhere would end up making it much harder to change all UNO APIs.
There is a spectrum of views on how conservative (or otherwise) we
should be around changing published APIs ATM, and how to do that but

        so far - I've not heard anyone articulate the view that an un-published
API cannot be easily changed =) so - there is at least -some- hope for
improvement of -some- of the UNO APIs without sterilization of the whole
space[1]. Personally I'd never create a new API that is published ;-)
but ...

        Are we truly sure that removing the 'published' keyword in averaging
this out would help everyone adopt a more flexible, comprehensible and
positive approach ? I fear that we'd go entirely the other way and have
problems everywhere ;-)

        Given what UNO promises, I would imagine that the best place to invest
work here is with some focus on future-proofing things. As far as I can
see, there are a ton of exciting possibilities when you can capture so
much type information on both sides. It should be possible eg. to add
parameters to methods, and append methods to existing interfaces if the
right work is done in the bridging - and if we engineer around default
values for those parameters. Similarly, as Kendy pointed out there is no
fundamental reason why we can't extend enumerations etc. if we get the
bindings right. Which reminds me - this is prolly a great item for the
budget / funding discussion =) I'll try to file an item with a better
spec. there

        ATB,

                Michael.

[1] - sure we can have a policy, sure it can be written down somewhere -
the theory is all good - but the 'smell' of badness, relational pain,
extra work, etc. that surrounds UNO is already bad enough IMHO without
making the situation less clear.
--
[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: [Libreoffice-qa] minutes of ESC call ...

Hi,

On Fri, Dec 16, 2016 at 10:42:43AM +0000, Michael Meeks wrote:
> Hmm ! ;-) My concern would be that removing the 'published' tag
> everywhere would end up making it much harder to change all UNO APIs.
> There is a spectrum of views on how conservative (or otherwise) we
> should be around changing published APIs ATM, and how to do that but

Maybe we should change the meaning of "published" then? Currently, "published"
means a onesided promise to each and eevery person on this planet -- people that we have
no relation with at all -- that we will never ever change this API and we dont
ever get anything in return. This is painful, as a feedback channel with
"everyone on this planet" is kinda hard to come by, much less so driving
conclusive negotiations on it.

So how about this instead:

1/ We unpublish all API
2/ We give UNO user an opportunity to ask for republishing specific parts of
   the API, when they provide a reasonable use case and promise to be the
   "client steward" for these.
3/ We continue to change unpublished API as core developers see reasonable. We
   promise to release changes to these newly republished APIs only after
   checking back with the "client steward" for that part of the UNO API for
   advisory _non-blocking_ input[1].

I see multiple advantages to this:

- we (core devs) still retain the perogatibve to do the ultimate decisions on
  UNO API changes
- UNO clients have an incentive to get closer to upstream (us)
  (we might even get some to become interested in core development)
- UNO clients learn about the rationale for UNO changes early on -- this might
  help reduce flaming and butthurt
- we learn what parts of the API are actually externally used
- UNO clients are able to get early prerelease heads-up on API changes and have
  adapted by the time the change is released to the world => Less stuff broken
  on release day.

There might be some hope that UNO API users like WollMux, Mendeley, Zotero
might be interested in this -- and by talking to them instead of with
$ANONYMOUS_GUY_ON_THE_INTERTUBES we might get a sensible feedback channel and
bring out ecosystem closer together -- as they have incentives to join this
discussion.

Best,

Bjoern

[1] Note this doesnt mean you cant change published APIs on master before
    getting feedback as releases are at least 2-3 months off from release to
    public.

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