minutes of ESC call ...

* Present:
        + Norbert, Stephan, Rainer, Michael, Bjoern, Kohei, Caolan,
          Christian, Kendy, Petr, Cedric, Michael S, Astron

* Completed Action Items
        + quest for kind volunteer to update the website (Michael)
                + thanks to Marc !
        + another review for splash-screens (Michael)
        + 4.0 wiki page section split (Kendy)
        + check new templates are using auto-fitting functionality (PEtr)

* Pending Action Items
        + [pending] notify all committers when we have a nice simple, minimal
          statement of what is required for gerrit written (Bjoern)
                + reviews done
        + make bytemark windows box do release builds (Fridrich)
        + maildrop for Gerrit (Bjoern)
                + 3/4 done, in progress idly.
        + 4.0 issues (Everyone)
                + everyone interested in cleanups - claim your work until next ESC!
                        + http://wiki.documentfoundation.org/Development/LibreOffice4
        + crediting: can we separate templates / artwork in the credits page (Spaetz?)

* Release Engineering update (Petr)
        + 3.6.0 RC4
                + annoying bug: comments lots during .xls / .xlsx export
                        + not good, but probably not a blocker
                + autocorrection & dictionaries internal / user-installation
                  extensions not had their versions bumped => not
                  working (Stephan)
                + actively registered / lightproof uno extensions also
                  have some update issues - have a fix as well (Stephan)
                        + grammar-checker impairment
                + workaround - manually remove bundled extensions directory
                        + locating it on windows is a pain.
                + registering bundled extn's
                        + slowest bit is help registration
                        - hence version check.
                + decision: ship it now
                        + release note it carefully
        + 3.6.1 RC1 is due in 2 weeks
                + all above issues fixed
        + 3.5.6 RC1 status
                + built except for Win32, start up-loading later today
                + RC2 deadline is on Monday - tripple review for -3-5-6
        + Automatic update / suggesions policy
                + we can choose which versions update to what versions (Kendy)
                + perfectly possibly to recommend 3.5.0 -> 3.6.0 but
                  avoid 3.5.1+ -> 3.6.0
                + no user configuration for enthusiasm for updates ? (Norbert)
                        + only enable / disable
                + re-visit update to 3.6.1 from 3.5.0
        + perennial updating / first-start user-experience issues
                + re-thinking the complicated optimisations here
                  sounds like a good plan.

* GSOC update (Cedric)
        + ongoing work - pencils down / evaluations by August 20th

* 4.0 - ongoing discussion (Kendy)
        + thanks to those who assigned themselves some tasks
        + should we start now or post-re-basing ?
                + http://wiki.documentfoundation.org/Development/LibreOffice4
        + can we do the less incompatible changes first (Bjoern)
        + deadline - of next week for volunteers for tasks
        + proposal - call next version 4.0, pending wider input.
        + whole point of 4.0 - if incompatible (Michael S)
                + will keep people on last 3.x release for longer
                  so need to support it for longer
                + always true even if we do 3.7 (Norbert)
                + concerns wrt. longer term support of re-based code
                + if we retain good back-compat / bridging much
                  less of an issue (Michael)
        + start working, and testing breakage (Stephan)
                + start doing it & see if it works or breaks
        + unclear proposal / need an updated release plan (Bjoern)
        + wide-spread code changed blocked anyway on re-basing (Lubos)
                + discussion ongoing with 3.6.x fixing
        + could we have a re-based 4.0 with no ABI break (Stephan)
                + announce intention to break things (Bjoern)
        + potential to incremental numbering eg. 4 -> 5 -> 6 for
          next releases (Stephan)
        + extend deadline until next week for task selection in wiki
                + please take ownership of tasks
                + and/or consider what can be done without
                  breaking binary compatibility.

* UI / design update (Astron)
        + ongoing vacations for Mirek
        + CTL discussion still under consideration

* Call for Papers for talks @ LibreOffice conference
        + if your name includes non-ascii characters you can't register:
          Andreas in the process of fixing this.
        + http://conference.libreoffice.org/call-for-paper
                + please submit talks ASAP ...

* QA update (Rainer)
        + producing a bibsect repository for Windows (Norbert)
        + new bug report page - with search for duplicates thanks to Tollef

* 3.6 most annoying bugs ...
    + 12 (of 55) older 11/48 8/42 10/37 11/35 5/26 5/21 3/19 4/15 8/13
         22%            23%   19%  27%   31%   19%  24%  16%  27%  62%
    + https://bugs.freedesktop.org/showdependencytree.cgi?id=44446&hide_resolved=1

* 3.5 most annoying bugs ...
    + 77 open (of 253) older 73/250 72/249 67/244 70/243 73/241 72/238 68/231
         30%                   29%   29%    27%    29%    30%    30%    29%
    + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

* 3.5 bugs tagged with 'regression'
    + 180(-1) bugs open of 720(+10) total
    + Started to double-count more classes of regression, to split
      them out more easily: Crashes, Borders, Migration
        + temporarily distorts graphs
        + encourages fixing of these bugs

    * ~Component   count net *
    + Writer       - 69 (-1)
    + Spreadsheet  - 20 (+3)
    + Presentation - 20 (+0)
    + Crashes      - 19 (+3)
    + LibreOffice  - 16 (+1)
    + Database     - 10 (-2)
    + Drawing      - 11 (+0)
    + Borders      - 9  (+0)
    + Migration    - 7  (+2)
    + Writer / RTF - 7  (+0)
    + Basic        - 2  (+0)

    + https://bugs.freedesktop.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&resolution=---&query_format=advanced&product=LibreOffice&list_id=36764
    + Migration tracker: https://bugs.freedesktop.org/show_bug.cgi?id=43489

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

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

Hi all,

On Thu, Aug 02, 2012 at 05:52:16PM +0100, Michael Meeks wrote:
> ESC minutes

here is a topic for the next ESC call. Quite a few of you have already used:

 http://wiki.documentfoundation.org/Development/GitReview

so:

- what are the experiences?
- should we recommend it in general?

I think there are two scenarios we want to consider.

newcomer/casual contributor/submitter:
- should work out of the box (without install) for simple patch upload
- should be most trivial (no complex switches or parameters)
- does not need to provide review capabilities (the web UI is perfectly suited
  for a first attempt at a review, CLI is only interesting for mass review)

core dev/reviewer:
- an one time setup cost doesnt hurt too bad
- can some more complexity for addiional features
- mass review from the CLI should be possible

Ignoring the second group for now (they will create their own
Python/Perl/Haskell/Brainfuck scripting in the end anyway). If the feedback by
current users of git review is positive and deemed suitable for firsttime
users, I would suggest, if possible, to dump a copy that can work standalone
into the core repo root. Even if it might be outdated compared to openstack its
likely better in the long run than ./logerrit for submittal. But IMHO
git-review MUST work out of the box then -- without any setup.

@David: Do you think git-review allows that?

For reviewers, we keep the ./logerrit sceleton around (removing all submittal
functionality) - not so much because its an excellent client, but as template
fro whatever scripting reviewers write themselves in the end.

Best,

Bjoern

(*) plus patching to provide something like "./logerrit resubmit"
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi Bjoern,

On 02.08.2012 23:21, Bjoern Michaelsen wrote:
>   http://wiki.documentfoundation.org/Development/GitReview
>
> so:
>
> - what are the experiences?
> - should we recommend it in general?
I am really happy with git review. It has killer features that i don't
want to miss anymore,
in fact they saved my life (and some other guys too ,-)
To name the few:

1. called with git review -s (once)  it does all the setup for your.
     It even checks if you have commit-msg hook in place and download
and install one, if you don't!
2. it checks if your commit has Change-Id and ammend to recrate it, in
case you commited before installing commit-msg hook.
3. it has --dry-run option and shows you what it would do without
actually doing anything (like git push command)
4. and last but not least it really save your life by checking how much
commits your are going to upload and warn and ask for confirmation if
the count is > 1.

[...]
> I would suggest, if possible, to dump a copy that can work standalone
> into the core repo root. Even if it might be outdated compared to openstack its
> likely better in the long run than ./logerrit for submittal. But IMHO
> git-review MUST work out of the box then -- without any setup.
No! You don't dump a copy of git, bash and binutils, don't you?
Like described in link above, you have three options here:
pypi-system-wide, pypi-user-local and distro package.
No other options please.

[...]
> (*) plus patching to provide something like "./logerrit resubmit"
i just uploaded the git-review patch:
https://review.openstack.org/#/c/11046/
So the simultaneous submissions to release branch and direct push to
master should be possible now (once openstack guys apporved my change).
And hej, my patch in git-review was shorter then your in logerrit ;-)

Regards
David


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

On Wed, Aug 08, 2012 at 11:19:09PM +0200, David Ostrovsky wrote:
> > But IMHO git-review MUST work out of the box then -- without any setup.
> No! You don't dump a copy of git, bash and binutils, don't you?

Because they are install with ~all systems and are available on all system as a
nicely maintained package. Thats is not the case for git-review yet. Besides,
it is small and we should have in our repos anyway for safety when it becomes
part of our infrastructure. Besides we _have_ copies of boost, glib, expat and
openssl in our repos for valid reasons.

> Like described in link above, you have three options here:
> pypi-system-wide, pypi-user-local and distro package.
> No other options please.

Most people wont even know what pypi-system-wide is and dont want to know. And
they shouldnt need to.

We will loose possible contributors that way. Not an option. Patch submittal
has to work hasslefree and out of the box. This is really critical: there has
to be no extra step at all for patch submittal otherwise we failed.

Best,

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

Hi,

On Wed, Aug 08, 2012 at 11:52:03PM +0200, Bjoern Michaelsen wrote:
<irony>
It has worked hasslefree and out of the box while we have been using
email.
</irony>

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

Hi David,

David Tardon píše v Čt 09. 08. 2012 v 07:17 +0200:

> > We will loose possible contributors that way. Not an option. Patch submittal
> > has to work hasslefree and out of the box. This is really critical: there has
> > to be no extra step at all for patch submittal otherwise we failed.
>
> <irony>
> It has worked hasslefree and out of the box while we have been using
> email.
> </irony>

It was a precondition for the gerrit work that the email submission +
direct push must still be possible, and I for one will make sure this is
still so ;-)

Regards,
Kendy

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

On Thu, Aug 09, 2012 at 09:15:48AM +0200, Jan Holesovsky wrote:
> David Tardon píše v Čt 09. 08. 2012 v 07:17 +0200:
> > <irony>
> > It has worked hasslefree and out of the box while we have been using
> > email.
> > </irony>
>
> It was a precondition for the gerrit work that the email submission +
> direct push must still be possible, and I for one will make sure this is
> still so ;-)

Agreed. gerrit is a platform and it should integrate all kind of workflows
whether they are email-based, web-based, CLI-based, IRC-based or whatever. That
doesnt mean the 'gerrit guys' will implement every of your pet features there,
but we have to make the basic workflow available there.

Best,

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

On Wed, Aug 08, 2012 at 11:52:03PM +0200, Bjoern Michaelsen wrote:
Thinking a bit about this, another possibility would be to do with git-review
as we do with other external stuff:
Downloading and installing a local copy in "./download". That would ensure it
to be universally available and be up to date.

Best,

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

On Thu, Aug 9, 2012 at 7:04 AM, Bjoern Michaelsen
<[hidden email]> wrote:
I know that michael disagree with me on that, but I prefer dev-tools
to be in ...  dev-tools.git
one can install it as he see fit. and you get the version you
want/need regardless where you are in the source tree...

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

On Thu, Aug 09, 2012 at 07:55:45AM -0500, Norbert Thiebaud wrote:
> I know that michael disagree with me on that, but I prefer dev-tools
> to be in ...  dev-tools.git
> one can install it as he see fit. and you get the version you
> want/need regardless where you are in the source tree...

Well, putting it in ./download would be even better, as it would be living
upstream at openstack.

Best,

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

Quoting Norbert Thiebaud <[hidden email]>:

Well to put it in dev-tool is much less painfull as to put it elsewhere.
Note this tool must be in your PATH! For all branches.
And even if you switch the branches and no matter what your current  
directory is,
you must be able to say:
git review --dry-run

that it.
But who is the person who will put it in dev-tools once and update it  
all the time?
(Last time i contributed to git-review was today morning).
But even if that person (not me) or some cron jobs continuously  
synchronize it, the user must still update it.

So the user must now periodically update dev-tool to get the fresh version
of git-review? But then what is the difference to say git pull  
dev-tools/git-review or

sudo apt-get update upgrade (place here your distro command)
or (*)
sudo pip install git-review
sudo pip install --upgrade git-review
sudo pip uninstall git-review

(*) http://www.pip-installer.org/en/latest/index.html

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

On Thu, Aug 9, 2012 at 8:11 AM, Bjoern Michaelsen
<[hidden email]> wrote:
> On Thu, Aug 09, 2012 at 07:55:45AM -0500, Norbert Thiebaud wrote:
>> I know that michael disagree with me on that, but I prefer dev-tools
>> to be in ...  dev-tools.git
>> one can install it as he see fit. and you get the version you
>> want/need regardless where you are in the source tree...
>
> Well, putting it in ./download would be even better, as it would be living
> upstream at openstack.

no it would not, because if I swith to branch 3-5... what version do I
have then ?

not to mention have n-copy of it (I do have typically half-a dozen of
clone of core...)... yeah the src directory can be share... still. I
tend to do make clean a lot... so I would have to rebuild it every
time to make sure it is there when I need it ?


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

On Thu, Aug 09, 2012 at 08:57:01AM -0500, Norbert Thiebaud wrote:
> no it would not, because if I swith to branch 3-5... what version do I
> have then ?

If you switch -- the same. ./download would install it into solenv/bin, which
is not changed by git checkout. Also I would suggest to backport that to all
branches -- it wont affect the build anyway, so should be easy to review.

> not to mention have n-copy of it (I do have typically half-a dozen of
> clone of core...)... yeah the src directory can be share... still. I
> tend to do make clean a lot... so I would have to rebuild it every
> time to make sure it is there when I need it ?

Well, I doubt that small script is the right place to start to look of build
dir size. Even killing autodoc will help a lot more.

Best,

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