minutes of ESC call ...

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

minutes of ESC call ...

* Present:
        + Andras, Norbert, Eike, Caolan, Joel, David, Michael M,
          Stephan, Kendy, Petr, Norbert, Michael S, Thorsten,
          Cedric, Pierre-Eric, Ahmad

* Completed Action Items
        + add a11y issue to 3.6.x release notes (Thorsten)
        + audit set of new / built-in fonts (Caolan)
                + they're fine.
        + create script / suggestions to parse Meeks minutes (Bjoern)
                + punted.
        + fdo#51023 - impress D&D crasher - (thanks Tor !)
        + post proposed set of rules for 4.x ABI handling to
          list for discussion (Kendy)
        + update wiki page wrt. 4.0 versioning details (Petr)
        + set updater to get 3.5.0..2 -> 3.6.3 (Kendy)
                + done.
        + T-shirt feedback sent to Mirek (Kendy)

* Pending Action Items
        + create a new AmbitiousHacks wiki page, based on GSOC page (Michael M)
        + poke UX advise wrt. how to improve color management UI team (Markus)
        + issues to look into if we can
                + fdo#55360 - mac specific text issue (Thorsten)
        + minimal triage for good mentors for proposed easy hacks (Bjoern)
        + update master / build versioning (Petr)
        + setup call for designs for FOSDEM T-shirts (Astron)
        + font bundling and gerrit fun with Astron (Andras)
                + waiting for Astron's feedback
        + provide a new palette based on Tango (Alex?)

* Release Engineering update (Petr)
        + on-line update / full switch-over go/no-go ?
                + there are and always will be regressions (Petr)
                + instead propose update people on versions
                  in range: 3.5.0-3.5.x and 3.6.0 to 3.6.x-1 to 3.6.x
                + that means updating up to 3.5.3 to 3.6.3 (as of now)
AA:  keep this scheme up unless foiled by a security issue
        + 3.6.4 rc1 branch deadline is Nov 12th
                + branch on Tuesday.
        + 3.7 timeline: Dec 3rd - week 47
                + feature-freeze 3 weeks out.

* Hack-fest coming up:
        + http://wiki.documentfoundation.org/Hackfest/Munich2012
                + if you're coming - please sign up: 20x guys so far.
        + do people need travel subsidy to be there ?
                + anyone interested please contact me.

* UX input (Astron)
        + should we just default disable the rulers ? (cf. gerrit patch)
                + concrete decision appreciated.

* Warning-free build issues (Lionel)
        + new-contributor interest in reducing build time warnings
                + most of the warnings are in included code not ours.
        + punted until Lionel can be here

* FOSDEM dev-room:
        + http://wiki.documentfoundation.org/Marketing/Events/Fosdem2013
        + travel subsidy available
        + talks much appreciated, sign up early.

* Certification Committee update (Kendy/Stephan/Bjoern)
        + list is published
        + [ list seen in blog ] ...
AA: + grok the list of contributors for suitable candidates (Kendy)
AA: + work on mail to encourage them to apply (Kendy/Stephan/Bjoern)

* formal ESC composition:
        + http://wiki.documentfoundation.org/Development/ESC
        + add Joel
AA: + add Mirek (?) ask Astron / Mirek / Alexander (Kendy)
        + add Tibby in Mitch's place.
        + add Ahamd for MOTAH
AA: + poke the board with new names (Michael)

* submodules retrospective (Norbert)
        + lots of people with exciting problems migrating
        + seems to be working nicely now.
        + issues with failed checkout of concern (Michael)

* Proposed easy-hacks -> Easy Hacks (Joel)
        + re-visit finding devs to build code-pointers for these:
        https://bugs.freedesktop.org/buglist.cgi?list_id=147895&status_whiteboard_type=anywordssubstr&query_format=advanced&status_whiteboard=ProposedEasyHack&bug_status=NEW&bug_status=REOPENED&product=LibreOffice

* 4.0 pending tasks
        + binfilter - what to do about it (Norbert)
                + remove it completely (Michael S)
                + do we have a concrete criteria for this stuff (Caolan)
                        + remote Lotus Word Pro for consistency ?
                + binfilter particularly bad: duplicated code.
                + happy to remove it.
        + bundling libre logo ? (Andras)
                + cf. motivational mail to dev list
                + around 200k with icons license etc.
                + is it useful for office suite users (Stephan)
                + useful for school children & fun in draw
                + not eager for bundled extensions
                        + built it into the core (Stephan)
        + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
                + could be turned into an extension
                + was in the past was turned off (Stephan)
AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
                + for future deprecation / removal.
        + upgrade bundled python to 3.0
        + user migration path thought / testing
AA: + bump versions sooner than later, to find hard-coded '3's (Petr)

* LibreOffice conference bits
        + please send links to your photos to
          [hidden email]

* cool feature contributions from latest Ubuntu (Bjoern)
        + shipping in latest Ubuntu
        + PackageKit - just one patch, whack it in - an UNO component that
          checks if pkgs are installed / install them etc.
                + some distro-specific package name wrapping needed
                + push buttons for additional templates
                + lots of expansion potential: filters, lang-packs etc.
        + Unity Menus
                + re-base the branch vs. master
AA: + review the branch as/when it's re-based (Michael)

* UDS Update (Bjoern)
  - three LibreOffice sessions, some highlights:
    - we will do three daily LibreOffice builds in Canonical QA Labs:
      - master without system libs
        - can we tinbuild that for integration in upstream infra ?
      - release with system libs
        - best without tinbuild integration: breakages are more likely
          Ubuntus faults
      - possibly: QEMU ARM build in QA mode.
    - greenlighted investigating cleaning up scp2, my goals would be:
      - make it driven by deps only, so that you can do "make
        /usr/lib/ure/lib/lib_unosal.so.3" without doing a full re-build.
           + v. useful for quick hackery
      - kill solver -- copy directly from $WORKDIR
    - various packaging titbits
    - http://errors.ubuntu.com/ is truely awesome
        + enter libreoffice-core and 'last month'
        + for Fedora (Caolan)
                + https://retrace.fedoraproject.org/faf/problems/hot/*/*/libreoffice/
    - Ubuntu will introduce staged updates, maybe an idea for the
      Windows updater discussion?
        + staged -> goes to a few people first, then a wider group.
    - quickly showed off bibisect, might be an idea for upstream GNOME too.

* QA update (Joel / Bjoern)
        + business as usual
        + trying to get back into routine - wrt. time-change

* Hard Hacks:
        + http://wiki.documentfoundation.org/HardHacks
                + page updated
                + developers like the selection of hard hacks
        + fdo#49610 - EDITING: Terminating 'Find' when reached (Michael)
        + fdo#40594 - FILEOPEN .docx (MSO2010) does not show CHART object
                + volunteer needed
        + fdo#52433 - MEMORY LEAK: particular .odt leading to crash after ...
                + well known image management is utterly shambolic disaster area.

* Closed 3.7 MAB (with thanks)
        + fdo#56460 - CRASH closing specific .odg files ? (Caolan)

* Open 3.7 MAB / regressions [ there should be none ]:
        + 4 (of 18) older 3/16 3/14 2/13
        + fdo#53525 - 2 columns Table of contents exceeds page width ?
        + fdo#55563 - PPTX image background rendered incorrectly
        + fdo#55570 - significant autocorrect slow-down (Stephan)
        + https://bugs.freedesktop.org/showdependencytree.cgi?id=54157&hide_resolved=1

* 3.6 most annoying bugs ...
        + 34 (of 148) older 35/145 33/139 30/132 27/127 44/139 46/137 45/132 44/127
              23%            24%    24%    23%    21%    32%    34%    34%    35%
        + https://bugs.freedesktop.org/showdependencytree.cgi?id=44446&hide_resolved=1

* 3.5 most annoying bugs ...
        + 69 open (of 278) older 69/279 75/278 77/279 78/278 81/279 82/279 83/279 80/270
              25%                 25%    27%    28%     28%    29%    29%    30%    30%
        + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

* 3.5 bugs tagged with 'regression'
        + 178(+1) bugs open of 891(+9) total

        * ~Component   count net *
        + Writer       - 74 (+0)
        + Crashes      - 17 (+1)
        + Presentation - 17 (-1)
        + Database     - 16 (+1)
        + Spreadsheet  - 15 (+2)
        + LibreOffice  - 12 (+0)
        + Drawing      - 13 (+1)
        + Borders      - 9  (-2)
        + Migration    - 5  (+0)
        + Basic        - 3  (+0)
        + Writer / RTF - 1  (-2)

        + 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

bug-metrics.ods (59K) Download Attachment
Lionel Elie Mamane Lionel Elie Mamane
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

On Thu, Nov 08, 2012 at 04:39:22PM +0000, Michael Meeks wrote:

> * 4.0 pending tasks
> + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
> + could be turned into an extension
> + was in the past was turned off (Stephan)
> AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
> + for future deprecation / removal.

*Why*? Is there some problem with these scripting languages, are they
hard to maintain, ...?

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

Re: minutes of ESC call ...

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

Michael Meeks píše v Čt 08. 11. 2012 v 16:39 +0000:

> + bundling libre logo ? (Andras)
> + cf. motivational mail to dev list
> + around 200k with icons license etc.
> + is it useful for office suite users (Stephan)
> + useful for school children & fun in draw
> + not eager for bundled extensions
> + built it into the core (Stephan)

It is a bit unclear here; I think the "not eager for bundled extensions,
built it into the core" was more a general statement than resolution of
the LibreLogo bundling - like, I understood it so that if we decide to
bundle an extension, it should be on the basis that the long term goal
is to integrate that functionality into the core.

I myself would prefer not to bundle LibreLogo, but instead improve our
extension download / installation experience in general - like some
'featured selection' of extensions that we would be able to show in the
Start Centre, or something.  Of course, until it happens, why to block a
nice feature :-) - but I don't think we should make its toolbar visible
by default, which consequently means that very few people will know
about that anyway; something that is more easily fixable (blogging,
etc.) if it is an (unbundled) extension.

All the best,
Kendy

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

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
Le 08/11/2012 17:39, Michael Meeks a écrit :


> + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
> + could be turned into an extension
> + was in the past was turned off (Stephan)
> AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
> + for future deprecation / removal.
> + upgrade bundled python to 3.0

Surely, shouldn't we be promoting access to UNO via a variety of
scripting languages rather than removing the bits that others have
managed to successfully integrate in the past ?

Is there some issue with maintenance or known future compatibility
headaches ? AFAIR some effort went into converting these from optional
extensions into pre-compiled features, so why remove them (or make them
hard to find) in 4.0 ?

Just my 2cents FWIW


Alex

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

Re: minutes of ESC call ...

In reply to this post by Jan Holesovsky
On 11/09/2012 09:16 AM, Jan Holesovsky wrote:

> Michael Meeks píše v Čt 08. 11. 2012 v 16:39 +0000:
>> + bundling libre logo ? (Andras)
>> + cf. motivational mail to dev list
>> + around 200k with icons license etc.
>> + is it useful for office suite users (Stephan)
>> + useful for school children & fun in draw
>> + not eager for bundled extensions
>> + built it into the core (Stephan)
>
> It is a bit unclear here; I think the "not eager for bundled extensions,
> built it into the core" was more a general statement than resolution of
> the LibreLogo bundling - like, I understood it so that if we decide to
> bundle an extension, it should be on the basis that the long term goal
> is to integrate that functionality into the core.

Yes, that was my intent.  /If/ we include some functionality in the
product, it typically does not make sense to include it as a bundled
extension.  (As it complicates things, e.g., the extension code not
being able to link against non-URE code; trouble with first-start
bundled extensions checks.  The only benefit of bundled extensions is
that users can override them with later versions without installing a
complete new LO -- that was the original motivation to have
dictionaries, with release schedules varying from OOo's release
schdules, as bundled extensions.)

> I myself would prefer not to bundle LibreLogo, but instead improve our
> extension download / installation experience in general - like some
> 'featured selection' of extensions that we would be able to show in the
> Start Centre, or something.  Of course, until it happens, why to block a
> nice feature :-) - but I don't think we should make its toolbar visible
> by default, which consequently means that very few people will know
> about that anyway; something that is more easily fixable (blogging,
> etc.) if it is an (unbundled) extension.

My main concern is whether to include this in the LO repo at all.  (That
is, even if it is a non-bundled extension, I would prefer not to include
it in the repo.)  We generally suffer from too much code, not too
little, so I'm skeptical about additions.

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

Re: minutes of ESC call ...

In reply to this post by Alex Thurgood
On 11/09/2012 09:29 AM, Alex Thurgood wrote:

> Le 08/11/2012 17:39, Michael Meeks a écrit :
>> + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
>> + could be turned into an extension
>> + was in the past was turned off (Stephan)
>> AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
>> + for future deprecation / removal.
>
> Surely, shouldn't we be promoting access to UNO via a variety of
> scripting languages rather than removing the bits that others have
> managed to successfully integrate in the past ?
>
> Is there some issue with maintenance or known future compatibility
> headaches ? AFAIR some effort went into converting these from optional
> extensions into pre-compiled features, so why remove them (or make them
> hard to find) in 4.0 ?

The change from bundled extensions to truly integrated parts of the code
was for technical reasons (the extensions directly accessed non-URE
functionality, which does not work).

The idea to make them experimental-mode--only was to find out whether
people actually use them (i.e., see whether there will be complaints
that the functionality is gone, and then tell the complainers how to get
the functionality after all).

 From a maintenance perspective, there /is/ occasional trouble with
those scripting providers, and also their integration is somewhat
second-class, cf. their editor windows with a distinct Java l&f.  So I
personally wouldn't mind if we drop them, if their user base is
vanishingly small enough (which is always hard to tell).

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

Re: minutes of ESC call ...

In reply to this post by Alex Thurgood
Hi,

On Fri, Nov 09, 2012 at 09:29:34AM +0100, Alex Thurgood wrote:

> > AA:         + disable Rhino / Beanshell unless in experimental mode (Michael)
> >             + for future deprecation / removal.
> >     + upgrade bundled python to 3.0
>
> Surely, shouldn't we be promoting access to UNO via a variety of
> scripting languages rather than removing the bits that others have
> managed to successfully integrate in the past ?
>
> Is there some issue with maintenance or known future compatibility
> headaches ? AFAIR some effort went into converting these from optional

You mean except that the rhino/js thing can't use the "normal" rhino but
needs a heaviliy patched version? :)

Which alone is a headache.

Regards,

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

Re: minutes of ESC call ...

In reply to this post by Lionel Elie Mamane

On Fri, 2012-11-09 at 06:19 +0100, Lionel Elie Mamane wrote:

> On Thu, Nov 08, 2012 at 04:39:22PM +0000, Michael Meeks wrote:
> > * 4.0 pending tasks
> > + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
> > + could be turned into an extension
> > + was in the past was turned off (Stephan)
> > AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
> > + for future deprecation / removal.
>
> *Why*? Is there some problem with these scripting languages, are they
> hard to maintain, ...?

        When I last looked at Rhino (an impl. of Javascript in Java) it was
rather under-maintained itself, and as one of those big-lumps-of-java
not the loveliest thing to build, maintain use etc.

        IMHO gathering stats on whether anyone uses it is a sensible thing to
do with a view to deprecation; clearly we don't want to pile up
relatively pointless features, and encourage millions of people to
download, install and not-use them for no good reason :-)

        At least, this was the thinking around not shipping the Logo stuff
built-in IIRC - good to be consistent.

        Sorry the minutes were not terribly clear, nor (IMHO) did we reach a
terribly clear conclusion on the logo topic - which is perhaps all to
the best; it hadn't appeared on the list yet.

        ATB,

                Michael.

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://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 Lionel Elie Mamane
On Fri, Nov 09, 2012 at 06:19:22AM +0100, Lionel Elie Mamane wrote:

> On Thu, Nov 08, 2012 at 04:39:22PM +0000, Michael Meeks wrote:
>
> > * 4.0 pending tasks
> > + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
> > + could be turned into an extension
> > + was in the past was turned off (Stephan)
> > AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
> > + for future deprecation / removal.
>
> *Why*? Is there some problem with these scripting languages, are they
> hard to maintain, ...?

Well, if there are bugs there, we likely wont care about them, creating useless
clutter on bugzilla f.e.. Also there is some packaging work for them (dep-wise)
that is hardly justified by the benefit.

Best,

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

Re: minutes of ESC call ...

In reply to this post by Alex Thurgood
On 11/09/2012 09:29 AM, Alex Thurgood wrote:
Rene, Stephan,

I see your points and concerns. Couldn't we have, as a potential
alternative, a hack (easy or not, I wouldn't know) to replace the
current implementations with something more manageable (if indeed that
is possible, and however that might be defined) ?


Alex

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

Re: minutes of ESC call ...

Hi Alex,

On Sat, 2012-11-10 at 10:51 +0100, Alex Thurgood wrote:
> I see your points and concerns. Couldn't we have, as a potential
> alternative, a hack (easy or not, I wouldn't know) to replace the
> current implementations with something more manageable (if indeed that
> is possible, and however that might be defined) ?

        I'd love to see those pieces split out to be extensions that you can
download & use if you want to (personally). That's presumably quite some
chunk of work though.

        ATB,

                Michael.

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

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

Re: minutes of ESC call ...

On 10/11/12 17:46, Michael Meeks wrote:

> Hi Alex,
>
> On Sat, 2012-11-10 at 10:51 +0100, Alex Thurgood wrote:
>> I see your points and concerns. Couldn't we have, as a potential
>> alternative, a hack (easy or not, I wouldn't know) to replace the
>> current implementations with something more manageable (if indeed that
>> is possible, and however that might be defined) ?
>
> I'd love to see those pieces split out to be extensions that you can
> download & use if you want to (personally). That's presumably quite some
> chunk of work though.

that would be possible, but there are some open questions as to how to
best accomplish it:  the problem is that non-URE jars are used, which is
not allowed for extensions.  but that seems fixable: the used jars seem
to be the external "bsh" / "rhino" and internal "ScriptingFramework",
the latter containing common code for BeanShell/JavaScript/Java script
providers.

the ScriptProviderForPython is already an extension so there is some
prior art on how to do it.  also, until commit
a72a7dc500ffd57662e8b9be61e4676266861c33 the java ones were extensions too.

the following options come to mind:

1) add ScriptFramework.jar to the URE
   this would require maintaining binary compatibility; i have no idea
   if that is appropriate here

2) have 3 extensions and duplicate the ScriptFramework jar in each of
   them; would that actually work if you install more than one of them?

3) have 1 extension that contains ScriptFramework plus all 3 script
   providers

option 3 appears most appealing to me.

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

Re: minutes of ESC call ...

In reply to this post by Jan Holesovsky
Hi,

Le 2012-11-09 03:16, Jan Holesovsky a écrit :

> Hi,
>
> Michael Meeks píše v Čt 08. 11. 2012 v 16:39 +0000:
>
>> + bundling libre logo ? (Andras)
>> + cf. motivational mail to dev list
>> + around 200k with icons license etc.
>> + is it useful for office suite users (Stephan)
>> + useful for school children&  fun in draw
>> + not eager for bundled extensions
>> + built it into the core (Stephan)
>
> It is a bit unclear here; I think the "not eager for bundled extensions,
> built it into the core" was more a general statement than resolution of
> the LibreLogo bundling - like, I understood it so that if we decide to
> bundle an extension, it should be on the basis that the long term goal
> is to integrate that functionality into the core.
>
> I myself would prefer not to bundle LibreLogo, but instead improve our
> extension download / installation experience in general - like some
> 'featured selection' of extensions that we would be able to show in the
> Start Centre, or something.  Of course, until it happens, why to block a
> nice feature :-) - but I don't think we should make its toolbar visible
> by default, which consequently means that very few people will know
> about that anyway; something that is more easily fixable (blogging,
> etc.) if it is an (unbundled) extension.
>
> All the best,
> Kendy
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

As an elementary school teacher who ran a FR logo clubs and EN logo
clubs with Canadian gr. 6-7-8 students, I can tell you already, there is
no need to add this as a bundled extension. Logo is no longer taught in
our Math programs (I am extremely sad about this). But, my point is that
LibreLogo is just too much of a specialized bundle that most teachers
would expect to find as an extension and not as a bundled extension.
Lego Robotics are more popular at the elementary/secondary panel and
there is usually funding available for hardware/software purchases from
local sponsors for it.

As a teacher, I would rather see more clipart available in Gallery. I
can't tell you how many times the students asked me if there was more
clipart available. At least the additional clipart would be available to
100% of the users whereas LibreLogo only for a very select few.

Cheers,

Marc

--
Marc Paré
[hidden email]
http://www.parEntreprise.com
parEntreprise.com Supports OpenDocument Formats (ODF)
parEntreprise.com Supports http://www.LibreOffice.org

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

Re: minutes of ESC call ...

Hi,

On Sun, Nov 11, 2012 at 10:33 AM, Marc Paré <[hidden email]> wrote:
> As an elementary school teacher who ran a FR logo clubs and EN logo clubs
> with Canadian gr. 6-7-8 students, I can tell you already, there is no need
> to add this as a bundled extension.

Fair enough, you don't need it. Everyone can list dozens of
LibreOffice features that he/she does not need.

We are talking about a small (1400 lines in Python) extension, so size
does not matter. Of course it is not a core feature, and not a most
wanted feature, but how many features are there, that has fewer users?
E.g. localizations in minority languages, dictionaries in minority
languages, non-linear solver, export/import filters of rare file
formats etc. Nobody wants to remove them or not to add them, including
me.

I think the main problem with LibreLogo that it is an extension. Some
people consider bundled extensions as bloat, that should be
removed/integrated into core, whatever. While from the users' point of
view it does not matter. We have a checkbox to hide bundled extensions
in Extension Manager, we can make the default to hide those. What's
the difference then between an extension and a normal feature?

On the other hand, as Kendy pointed out, too, currently we don't have
good processes to distribute and to advertise non-bundled extensions.
They simply do not exist for majority of our users. Only a few hundred
or thousand power users find them. Not to mention that they get
community resources harder, e.g. localization and testing.

Cheers,
Andras
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
David Tardon David Tardon
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Michael Stahl-2
Hi,

On Sat, Nov 10, 2012 at 09:05:02PM +0100, Michael Stahl wrote:

> On 10/11/12 17:46, Michael Meeks wrote:
> > Hi Alex,
> >
> > On Sat, 2012-11-10 at 10:51 +0100, Alex Thurgood wrote:
> >> I see your points and concerns. Couldn't we have, as a potential
> >> alternative, a hack (easy or not, I wouldn't know) to replace the
> >> current implementations with something more manageable (if indeed that
> >> is possible, and however that might be defined) ?
> >
> > I'd love to see those pieces split out to be extensions that you can
> > download & use if you want to (personally). That's presumably quite some
> > chunk of work though.
>
> that would be possible, but there are some open questions as to how to
> best accomplish it:  the problem is that non-URE jars are used, which is
> not allowed for extensions.  but that seems fixable: the used jars seem
> to be the external "bsh" / "rhino" and internal "ScriptingFramework",
> the latter containing common code for BeanShell/JavaScript/Java script
> providers.
>
> the ScriptProviderForPython is already an extension so there is some
> prior art on how to do it.  also, until commit
> a72a7dc500ffd57662e8b9be61e4676266861c33 the java ones were extensions too.
>
> the following options come to mind:
>
> 1) add ScriptFramework.jar to the URE
>    this would require maintaining binary compatibility; i have no idea
>    if that is appropriate here

I think ScriptFramework is pretty stable. The only change I remember
during the whole LibreOffice lifetime is update to java 1.5: use of
generics etc.

>
> 2) have 3 extensions and duplicate the ScriptFramework jar in each of
>    them; would that actually work if you install more than one of them?
>
> 3) have 1 extension that contains ScriptFramework plus all 3 script
>    providers

4) create UNO API for ScriptFramework which can be used by the providers
   (no idea how much work this would mean. I just wanted to add it here
   for the sake of completeness.)

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

Re: minutes of ESC call ...

In reply to this post by Andras Timar
On 11/11/2012 02:29 PM, Andras Timar wrote:
> Some people consider bundled extensions as bloat, that should be
> removed/integrated into core, whatever. While from the users' point
> of view it does not matter. We have a checkbox to hide bundled
> extensions in Extension Manager, we can make the default to hide
> those. What's the difference then between an extension and a normal
> feature?

Bundled extensions being extensions, they have to coexist sensibly with
non-bundled (shared; per-user) ones.  For example, it can happen that an
extension was already installed per-user and now is also included
bundled after a LO upgrade.  There needs to be code that handles all
that, and that code needs to be run rather early during bootstrap, and
if it fails for some reason, it prominently fails during first start
after upgrade.  Been there, done that.

In short, potential for trouble, and amount of first-start activity, is
reduced by decreasing the number of bundled extensions.

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

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
On 11/08/2012 05:39 PM, Michael Meeks wrote:
> * FOSDEM dev-room:
> + http://wiki.documentfoundation.org/Marketing/Events/Fosdem2013
> + travel subsidy available
> + talks much appreciated, sign up early.

BTW, is this a joint devroom with AOO?  IIRC, the idea to do so floated
around at least.

Stephan

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

Re: minutes of ESC call ...

Stephan Bergmann wrote:
> BTW, is this a joint devroom with AOO?
>
Nope. There'll be separate devrooms for both projects.

Cheers,

-- Thorsten

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

attachment0 (205 bytes) Download Attachment
Italo Vignoli-4 Italo Vignoli-4
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by sberg
On 11/13/12 8:38 AM, Stephan Bergmann wrote:

> BTW, is this a joint devroom with AOO?  IIRC, the idea to do so floated
> around at least.

No, Apache OO will have a devroom on Saturday, although their CfP is not
yet out.

--
Italo Vignoli - [hidden email]
mob +39.348.5653829 - VoIP [hidden email]
skype italovignoli - gtalk [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Christian Lohmaier-2 Christian Lohmaier-2
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
Hi *,

On Thu, Nov 8, 2012 at 5:39 PM, Michael Meeks <[hidden email]> wrote:
>
> * UDS Update (Bjoern)
>   - three LibreOffice sessions, some highlights:
>     - we will do three daily LibreOffice builds in Canonical QA Labs:
>       - master without system libs
>         - can we tinbuild that for integration in upstream infra ?

Nothing that would prevent that from tinderbox side :-)

>       - release with system libs
>         - best without tinbuild integration: breakages are more likely
>           Ubuntus faults

and that could be added as well, just disable the mails there.

>       - possibly: QEMU ARM build in QA mode.

And this as well...
It's also possible to have those not in the MASTER overview page, but
in another category "experimental" or whatever other name, if the
concern is "adding noise" to the buildresults page..

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