minutes of ESC call ...

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

minutes of ESC call ...

* Present
        + Kohei, Rainer, Cedric, Lionel, Eike, Astron, Andras,
          Stephan, Caolan, Michael, Thorsten, Norbert, Kendy,
          Michael S, Petr

* Completed Action Items
        + task selection for LibreOffice 4 wiki:
                + http://wiki.documentfoundation.org/Development/LibreOffice4
                + [ punted for now ]

* 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 tempates in the credits page (Spaetz)
                + [ in progress ]

* Release Engineering update (Petr)
        + 3.6.0 update & post-mortem
                + all was quiet until the last two release candidates
                + only panicing at the last minute
                + was timing related / summertime ?
                + first-start / updating bug issue
                        + underestimated
                        + Stephan: bad timing, reported on Linux etc. used
                          non-released builds between.
                        + by chance, Michael fixed the windows build
                        + prereg feature only used on Windows, fix for issues
                          didn't make it into 3.6 from master.
                        + systemic problem where people are encouraged to
                          remove their user-installation vs. moveaside & make
                          available.
AI: + update QA FAQs / challenge answers to encourage moving
                          profiles away instead of deleting (Rainer)
                                + user installs can have sensitive data though,
                                  care needed - but keep that around.
                        + non-upgrades for profiles from dev / intermediate versions
                                + removing user-profile inconsistent data hid issues
                                  and hurt testing too
                                + Always create code to upgrade / never advise removal
                                  of inconsistent data.
                                + Rainer happy to help with profiles.
                + suggest zero tolerance policy for upgrade issues during development
                        + could have upgrade tinderbox (Bjoern)
                        + be nice to have some unit tests too (Michael)
                        + most important thing to get to better tests (Stephan)
                + standard test for how profile updates work (Rainer)
                        + it ~never works, but put more focus on this
                        + the problem was so frequent people got used to it.
                + adopt a near zero tolerance policy for upgrade issues during development
                        + bibisect can cause problems (Bjoern)
                        + agree - lots of ignoring of profile problems
                          with WORKSFORME when profiles are removed (Rainer)
                                + should not tolerate this.
                + collecting user-configuration - have a script / app to
                  dump it as a .zip ?
AI: + file an easy-hack to ship a binary to dump it (Petr)
                + 2x days of performance issues on the main website
                        + can cause issues
                + missing MSI signatures
                        + Andras forgot; normally some RC tester checks/reports that
                        + Thorsten added validation to upload scripts.
                + few native-lang projects deferred announce due to dictionaries bug
        + 3.6.1 RC1
                + pull the timeline in - do RC1 in 1 week instead
                + freeze / checkin deadline on Monday
                + RC2 in one extra week.
                + fixes the upgrade bug earlier.
        + 3.5.6 RC2
                + tagged this week / final version
                + builds being up-loaded / announce soon - on track.

* GSOC update (Cedric)
        + bit more than a week to go, make students aware it's almost over
        + pencils down / evaluations by August 20th

* UI / design update (Astron)
        + discussion about updated icons for gallery
        + ongoing options discussion
        + official git repo for artwork ?
                + should we re-use the old repository ? (no)
        + ongoing discussion around artwork licensing
        + new 'templates' repository created
                + can we push templates there ?
                + 70 new templates up-loaded to the wiki page
                  http://wiki.documentfoundation.org/Design/Call_for_Templates
                + need CC0 / authenticity statements & push those to git.
        + intends to package Astron & Alexander's templates first (Bjoern)
                + and do a package release
                + packagers who want sexy new templates take note ...
                + need some macro sanity checking
        + Astron / Alexander to provide editorial feedback & improvement
          encouragement
        + Toolbar fixing status - on Kendy's todo.
        + Bjoern created some Design easy-hacks
                + http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill#Easy_Hacks_requiring_Design_Skills

* Adobe Sans Pro bundling (Caolan)
        + http://arstechnica.com/information-technology/2012/08/adobe-releases-source-sans-pro-a-new-open-source-font/
                + lots of positive noise about it, no problem adding it (Caolan)
        + no Cyrillic or Greek, perhaps bundle other fonts instead (Astron)
        + we have an only-ascii font currently (Caolan)
AI: + re-think our bundled font list (Astron / design-team)

* Call for Papers - talks @ LibreOffice con
        * ESC agenda - 16th day before for an in-person meeting / hack-fest
                + please book flights for a day earlier
        + http://conference.libreoffice.org/call-for-paper
                + co-hosting talks is fine
                + find a parterner for your short talk
                + potentially add a "15mins" to the subject if you
                  want a short talk
                + please submit lightning talks too

* liblangtag issues (Eike)
        + controversial new required LGPLv3 dependency
                + implements BCP47 language codes
                + lots of nice code cleanup possible
        + very simple replacement for iOS / Android
        + not an ideal situation
        + invest outside the wrapper & lets see

* AOOi git import
        + with full OO.o history back to day one on top of OOO340_m1
                http://download.go-oo.org/AOOi/
        + like to push it to our git repo
                + adds another 40Mb of download +5% ...
AI => just do it (Kendy)

* bugzilla / gerrit integration (Bjoern)
        + concern about getting spammed a lot from calc guys.x
        + postpone discussion for next week.

--- out of time ~everything postponed below ---

* 4.0 - ongoing discussion (All)
        + best ideas heard so far: to do an ABI thaw for 4.0,
          and keep in place until after 4.1 - 1 year for ABI
          fixing.

* QA update (Rainer)
        + producing a bibsect repository for Windows (Norbert)
        + new bug report page - with search for duplicates [!] ...

* GUADEC update (Michael)

* git-review thoughts (Bjoern)

* gerrit update (Bjoern)
        + bugzilla / auto-commenting integration
                + filter-able changes ? ...
        + --new-changeid discussion

* 3.6 most annoying bugs ...
    + 11 (of 58) older 12/55 11/48 8/42 10/37 11/35 5/26 5/21 3/19 4/15 8/13
         19%            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 ...
    + 75 open (of 253) older 77/253 73/250 72/249 67/244 70/243 73/241 72/238
         30%                   30%    29%   29%    27%    29%    30%    30%
    + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

* 3.5 bugs tagged with 'regression'
    + 177(-3) bugs open of 723(+3) total

    * ~Component   count net *
    + Writer       - 67 (-2)
    + Presentation - 21 (+1)
    + Crashes      - 20 (+1)
    + LibreOffice  - 17 (+1)
    + Spreadsheet  - 16 (-4)
    + Database     - 11 (+1)
    + Drawing      - 11 (+0)
    + Borders      - 9  (+0)
    + Migration    - 7  (+0)
    + 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
Kohei Yoshida Kohei Yoshida
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

On 08/09/2012 11:13 AM, Michael Meeks wrote:
> * bugzilla / gerrit integration (Bjoern)
> + concern about getting spammed a lot from calc guys.x
> + postpone discussion for next week.

Just to voice my opinion, I too would be reluctant to see this
integration.  We core devs already receive tons of mails from bugzilla
many of which are pretty much noise.  And I'm personally not very fond
of this type of automatic messages cluttering bugzilla comments.

I'm also equally concerned about fragmenting our discussion platforms.
Even without gerrit, splitting the discussion between the mailing list
and bugzilla was (to me) hard enough.  Adding gerrit to the mix will
make matters worse.  I would rather we encourage everyone to keep the
discussions on the mailing list, instead of splitting it in now three
different platforms, and adding lots of noisy automatic linking between
them.

Just my opinion.

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc
_______________________________________________
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 ...


On Thu, 2012-08-09 at 11:37 -0400, Kohei Yoshida wrote:
> Just to voice my opinion, I too would be reluctant to see this
> integration.  We core devs already receive tons of mails from bugzilla
> many of which are pretty much noise.

        :-) I guess, there is no shortage of bugs to be CC'd on.

>  And I'm personally not very fond of this type of automatic messages
> cluttering bugzilla comments.

        I love the "fixed in 3.6.1" type automated comments - they're -really-
useful for QA to see which versions a bug is fixed in and to set
expectations right I guess.

        I suppose we could ask/pay Tollef to work on extending:

        https://bugs.freedesktop.org/userprefs.cgi?tab=email

        To add some flag magic for a new option for some the "ignore fixedin
XYZ" version stuff - but that's a bit of a PITA to maintain going
forward I suspect; I wonder if a mail filter could do the same.

> I'm also equally concerned about fragmenting our discussion platforms.
> Even without gerrit, splitting the discussion between the mailing list
> and bugzilla was (to me) hard enough.

        Yep - I guess auto-spamming can go too far; OTOH, it is rather relevant
that a fix for a bug has shown up and useful for a reporter to know that
there is a build of it to try out. Also we fix on average ~6 bugs per
day though we want to raise that - so, even if they're all in calc - if
we get it right with a single new bugzilla comment that says:

        "a gerrit branch, with a patch that fixes this bug was built
         for the specified platform >here<"

        And then no further comments afterwards seems like it might be on the
acceptable side ?

        Anyhow - thanks for raising the issue ! :-)

        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: minutes of ESC call ...

In reply to this post by Kohei Yoshida
On Thu, Aug 09, 2012 at 11:37:10AM -0400, Kohei Yoshida wrote:

> On 08/09/2012 11:13 AM, Michael Meeks wrote:
> >* bugzilla / gerrit integration (Bjoern)
> > + concern about getting spammed a lot from calc guys.x
> > + postpone discussion for next week.
>
> Just to voice my opinion, I too would be reluctant to see this
> integration.  We core devs already receive tons of mails from
> bugzilla many of which are pretty much noise.  And I'm personally
> not very fond of this type of automatic messages cluttering bugzilla
> comments.

The proposal is to send a comment to bugzilla for the _first_ upload of a patch
to gerrit. That is _one_ comment per bug maximum. So not much clutter there. In fact,
if we do not automate this, people might do it manually in 90% of the time,
leaving you with both some extra noise _and_ uncertainty if there is a patch
lurking on gerrit. Worst scenario of all.


> I'm also equally concerned about fragmenting our discussion
> platforms. Even without gerrit, splitting the discussion between the
> mailing list and bugzilla was (to me) hard enough.  Adding gerrit to
> the mix will make matters worse.  I would rather we encourage
> everyone to keep the discussions on the mailing list, instead of
> splitting it in now three different platforms, and adding lots of
> noisy automatic linking between them.

If there is anything that is cluttered its the mailing lists. The review
traffic there is largely discouraging non-core developers who just cant follow
it as is and arent invested enough to do sophisticated mail-filtering. Just
sending out the gerrit account notification, I noted that there are a lot of
volunteers using [hidden email] addresses. That is _not_ a good
sign about the current state of our communication.

If the target is to declutter communication, moving patch reviewal to gerrit is
the best option as it allows more targeted communication (e.g. notification on
of the interested reviewers).

Best,

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

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
On 08/09/2012 12:08 PM, Michael Meeks wrote:

>
> On Thu, 2012-08-09 at 11:37 -0400, Kohei Yoshida wrote:
>> Just to voice my opinion, I too would be reluctant to see this
>> integration.  We core devs already receive tons of mails from bugzilla
>> many of which are pretty much noise.
>
> :-) I guess, there is no shortage of bugs to be CC'd on.
>
>>   And I'm personally not very fond of this type of automatic messages
>> cluttering bugzilla comments.
>
> I love the "fixed in 3.6.1" type automated comments - they're -really-
> useful for QA to see which versions a bug is fixed in and to set
> expectations right I guess.

Yes.  That's the *only* automated messages that I like.  The rest I despise.

>
> I suppose we could ask/pay Tollef to work on extending:
>
> https://bugs.freedesktop.org/userprefs.cgi?tab=email
>
> To add some flag magic for a new option for some the "ignore fixedin
> XYZ" version stuff - but that's a bit of a PITA to maintain going
> forward I suspect; I wonder if a mail filter could do the same.
>
>> I'm also equally concerned about fragmenting our discussion platforms.
>> Even without gerrit, splitting the discussion between the mailing list
>> and bugzilla was (to me) hard enough.
>
> Yep - I guess auto-spamming can go too far; OTOH, it is rather relevant
> that a fix for a bug has shown up and useful for a reporter to know that
> there is a build of it to try out.

So, I'm still slightly confused about this.  What sort of automated
messages will gerrit start sending out?  I was under the impression that
gerrit will start notifying bugzilla about some relevant patches posted
to gerrit & review discussions that go on there and so on.

  Also we fix on average ~6 bugs per
> day though we want to raise that - so, even if they're all in calc - if
> we get it right with a single new bugzilla comment that says:
>
> "a gerrit branch, with a patch that fixes this bug was built
> for the specified platform >here<"
>
> And then no further comments afterwards seems like it might be on the
> acceptable side ?

Yes.  If we can limit the automated messages to just fixes that went
into the repo, and available test builds, then I can personally see some
value.  Anything else would be noise.

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc
_______________________________________________
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: minutes of ESC call ...

In reply to this post by Michael Meeks-2
On Thu, Aug 09, 2012 at 04:13:48PM +0100, Michael Meeks wrote:
> + [pending] notify all committers when we have a nice simple, minimal
>  statement of what is required for gerrit written (Bjoern)
> + reviews done

as you might have noted: done (finally).

Best,

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

Re: minutes of ESC call ...

In reply to this post by Bjoern Michaelsen
On 08/09/2012 12:17 PM, Bjoern Michaelsen wrote:

> On Thu, Aug 09, 2012 at 11:37:10AM -0400, Kohei Yoshida wrote:
>> On 08/09/2012 11:13 AM, Michael Meeks wrote:
>>> * bugzilla / gerrit integration (Bjoern)
>>> + concern about getting spammed a lot from calc guys.x
>>> + postpone discussion for next week.
>>
>> Just to voice my opinion, I too would be reluctant to see this
>> integration.  We core devs already receive tons of mails from
>> bugzilla many of which are pretty much noise.  And I'm personally
>> not very fond of this type of automatic messages cluttering bugzilla
>> comments.
>
> The proposal is to send a comment to bugzilla for the _first_ upload of a patch
> to gerrit. That is _one_ comment per bug maximum. So not much clutter there. In fact,
> if we do not automate this, people might do it manually in 90% of the time,
> leaving you with both some extra noise _and_ uncertainty if there is a patch
> lurking on gerrit. Worst scenario of all.

Sure, but gerrit already spams the mailing list.  I don't see the need
to duplicate that in bugzilla.

>
>
>> I'm also equally concerned about fragmenting our discussion
>> platforms. Even without gerrit, splitting the discussion between the
>> mailing list and bugzilla was (to me) hard enough.  Adding gerrit to
>> the mix will make matters worse.  I would rather we encourage
>> everyone to keep the discussions on the mailing list, instead of
>> splitting it in now three different platforms, and adding lots of
>> noisy automatic linking between them.
>
> If there is anything that is cluttered its the mailing lists.

Yes, and I want to keep the cluttering just to the mailing list.  Why do
we have to also clutter bugzilla in addition?

The review
> traffic there is largely discouraging non-core developers who just cant follow
> it as is and arent invested enough to do sophisticated mail-filtering. Just
> sending out the gerrit account notification, I noted that there are a lot of
> volunteers using [hidden email] addresses. That is _not_ a good
> sign about the current state of our communication.

Yes, but this will also increase stress on core developers too.  I know
we are in for encouraging more developers, but not at the expense of
stressing the existing developers.  We need to balance that somehow.

> If the target is to declutter communication, moving patch reviewal to gerrit is
> the best option as it allows more targeted communication (e.g. notification on
> of the interested reviewers).

So, I have to be honest.  I'm still not entirely sold on gerrit, and my
passion for gerrit is not as great as some of the others who are totally
sold.  I just try to remain neutral and want to see how this plays out
first before making more drastic changes.  But I can't help feeling that
we are starting to push this a little too fast too quick.

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc
_______________________________________________
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: minutes of ESC call ...

Hi,

On Thu, Aug 09, 2012 at 12:43:13PM -0400, Kohei Yoshida wrote:
> Sure, but gerrit already spams the mailing list.

I would be more open to turn that down (e.g. by reducing it to one daily mail).

> I don't see the need to duplicate that in bugzilla.

Bugzilla is way more targeted though: It does not spam the world but a smaller
audience (which is CC'ed). Im open to make these easily mail-filterable for
those core devs who dont want the additional traffic. But as Michael pointed
out its ~5 mails per day for the whole project, so even someone who is
subscribed to a lot of those would maybe get 1 or 2 a day.

> >>I'm also equally concerned about fragmenting our discussion
> >>platforms. Even without gerrit, splitting the discussion between the
> >>mailing list and bugzilla was (to me) hard enough.  Adding gerrit to
> >>the mix will make matters worse.  I would rather we encourage
> >>everyone to keep the discussions on the mailing list, instead of
> >>splitting it in now three different platforms, and adding lots of
> >>noisy automatic linking between them.
> >
> >If there is anything that is cluttered its the mailing lists.
>
> Yes, and I want to keep the cluttering just to the mailing list.
> Why do we have to also clutter bugzilla in addition?

Because non-core devs dont read the high traffic -dev list. But they might be
rather highly motivated to work towards their pet issue (on which they are
subscribed).

> Yes, but this will also increase stress on core developers too.  I
> know we are in for encouraging more developers, but not at the
> expense of stressing the existing developers.  We need to balance
> that somehow.

See above. Even if you are subscribed to a lot of bugs this will give you give
1 daily extra mail which you can easily filter. But it will give others who
deeply care about this issue a hint that there is an opportunity to get
involved here in a way that they care about.

To put it differently: If you dont even want a mail about a patch being
proposed to fix a bug, I would seriously reinvestigate the policy that gets you
CC'ed on these bugs. Essentially there is no other notfication that can be that
important.
 
> So, I have to be honest.  I'm still not entirely sold on gerrit, and
> my passion for gerrit is not as great as some of the others who are
> totally sold.  I just try to remain neutral and want to see how this
> plays out first before making more drastic changes.

I suggest the thesis that that will only make us stay in the workflow
equivalent of the uncanny valley(*) longer than needed for the pain of
everyone.

Best,

Bjoern

(*) http://en.wikipedia.org/wiki/Uncanny_valley
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
bfoman bfoman
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
Michael Meeks-2 wrote
                + adopt a near zero tolerance policy for upgrade issues during development
Hi.
If I may propose anything, please add:
- zero tolerance policy for regression issues during development
- zero tolerance policy for crash issues during development
I was seriously amazed after reading Most annoying bugs section of Release notes for 3.6. Maybe it is time to think about emergency chemspill releases...
Anyway - at http://tinyurl.com/ffupdatetest you can see Mozilla dashboard for automatic testing of Firefox updates.
Really interesting resource and designing such tooling for LO would be a gain. In addition some popular extensions could be tested.
Best regards.
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Bjoern Michaelsen
On Thu, Aug 09, 2012 at 06:34:18PM +0200, Bjoern Michaelsen wrote:
> On Thu, Aug 09, 2012 at 04:13:48PM +0100, Michael Meeks wrote:
> > + [pending] notify all committers when we have a nice simple, minimal
> >  statement of what is required for gerrit written (Bjoern)
> > + reviews done
>
> as you might have noted: done (finally).

meh -- never leave a spam script with u+x in your ~ and have it in your bash history.

If you got this twice, just ignore the second mail.

Best,

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

Re: minutes of ESC call ...

In reply to this post by bfoman

On 2012-08-09 21:53, bfo wrote:
> If I may propose anything, please add:
> - zero tolerance policy for regression issues during development
> - zero tolerance policy for crash issues during development
>
People who advocate zero tolerance for such things are welcome to
provide the time and financial resources necessary to achieve this.

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


_______________________________________________
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 bfoman

On Thu, 2012-08-09 at 12:53 -0700, bfo wrote:
> If I may propose anything, please add:
> - zero tolerance policy for regression issues during development
> - zero tolerance policy for crash issues during development

        So - incidentally; we already have something like this in place. If you
can find a regression or crasher running a master build **that is not in
the last stable release** - you are encouraged to mail the developers
list with it. ie. we want to find out about regressions ASAP while the
work in a given area is going on. Of course - that makes it necessary to
run a master build - please do :-)

> I was seriously amazed after reading Most annoying bugs section
> of Release notes for 3.6.

        Right; the near-zero-tolerance change here is intended to encourage
developers / QA / bug-reporters to rebel against the all-too-common
"just delete your profile" -> "it works" -> WORKSFORME resolution cycle
that we see.

        And yes - time based releases means that (while we slipped a week to
try to fix it), 3.6.0 is really not as good as we wanted; that is
certainly true. On the other hand giving all developers the idea that
testing / bug fixing can be endlessly deferred since we'll never release
- is a really poor plan too; one aspect of that is that it's not fair on
the people that work diligently to test and fix things so we can release
at a given time.

        ATB,

                Michael.

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

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

Re: minutes of ESC call ...

In reply to this post by Noel Grandin
Noel Grandin wrote
> - zero tolerance policy for regression issues during development
> - zero tolerance policy for crash issues during development
People who advocate zero tolerance for such things are welcome to
provide the time and financial resources necessary to achieve this.
Hi.
Or maybe change in the base code workflow is needed?
1. design the change
2. find out which modules are affected
3. plan testing
4. code
5. prepare unit tests
6. careful code review (not just OKeying)
7. commit in the unstable branch
8. QA confirm
9. commit in the stable branch
I think many bugs introduced are an effect of omitting one (or more) steps from that list by the developer.
Using best coding practices always would help a lot.
Maybe gerrit will help to achieve this in some way...
Best regards.
bfoman bfoman
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by Michael Meeks-2
Michael Meeks-2 wrote
On the other hand giving all developers the idea that
testing / bug fixing can be endlessly deferred since we'll never release
- is a really poor plan too; one aspect of that is that it's not fair on
the people that work diligently to test and fix things so we can release
at a given time.
Hi.
Sure, nobody want to repeat 10 OpenOffice 3.3.0 RCs nonsense...
Best regards.
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: minutes of ESC call ...

In reply to this post by bfoman
On Mon, Aug 13, 2012 at 10:26:57AM -0700, bfo wrote:
> Or maybe change in the base code workflow is needed?
> 1. design the change

currently done

> 2. find out which modules are affected

would require a lot of cleanup in the codebase to make sensible predictions for
nontrivial changes here. We are working towards that, but we inherited a _lot_
of cruft.

> 3. plan testing

If you change e.g. refactor SfxItemSet that might impact ~everything. From a
prediction point of view our tests are good enough. Realistically though there
are cornercases, that wont get cought by unittests or subsequenttest. And we
wont catch those cornercases if we spend a year on writing tests. They are
cornercases and our codebase is huge.

> 4. code
> 5. prepare unit tests

Shouldnt 5 come first?

> 6. careful code review (not just OKeying)

Will you help there?

> 7. commit in the unstable branch

currently done.

> 8. QA confirm

currently done implicitly for every bug not reported by QA at branchoff
(because there is to few testing of master).

> 9. commit in the stable branch

currently done

> I think many bugs introduced are an effect of omitting one (or more) steps
> from that list by the developer.

nope, I think you are just underestimating the size of the codebase (and the
range of our target platforms).
Suggested reading: Michael Feathers, Working Effectively with Legacy Code

> Maybe gerrit will help to achieve this in some way...

It will, with automated testing and, if the QA community grows a bit (well a lot),
also with manual testing.

Best,

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

On 08/13/2012 08:10 PM, Bjoern Michaelsen wrote:
> On Mon, Aug 13, 2012 at 10:26:57AM -0700, bfo wrote:
>> I think many bugs introduced are an effect of omitting one (or more) steps
>> from that list by the developer.
>
> nope, I think you are just underestimating the size of the codebase (and the
> range of our target platforms).
> Suggested reading: Michael Feathers, Working Effectively with Legacy Code

... and suggested action: writing a dozen fixes for LO.  There is no
shortage of wisdom around here how to do things well in theory, I think.
  Sorry for sounding rude...

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

Re: minutes of ESC call ...

On Tue, Aug 14, 2012 at 1:59 AM, Stephan Bergmann <[hidden email]> wrote:
> ... and suggested action: writing a dozen fixes for LO.  There is no
> shortage of wisdom around here how to do things well in theory, I think.
> Sorry for sounding rude...

Nah, that did not sound rude at all... especially compared to what I
had in mind :-)

Norbert
_______________________________________________
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
|

visualising improved quality practices ...


On Tue, 2012-08-14 at 02:25 -0500, Norbert Thiebaud wrote:
> On Tue, Aug 14, 2012 at 1:59 AM, Stephan Bergmann <[hidden email]> wrote:
> > ... and suggested action: writing a dozen fixes for LO.  There is no
> > shortage of wisdom around here how to do things well in theory, I think.
> > Sorry for sounding rude...
>
> Nah, that did not sound rude at all... especially compared to what I
> had in mind :-)

        It's certainly an FAQ :-) We have end-users that have no idea what is
involved in our development process, and how we work to eliminate bugs,
and the innovations we've introduced to try to reduce regressions, and
so on.

        And of course we're not there yet; in particularly I keep meaning to
file my performance regression testing easy-hack to get something setup
there.

        In my ideal world we have someone who wants to write a blog series on
our approach to improving quality - that we can feed with some
outlines / tid-bits & they can research and write-up the good story of
where we're at today.

        Its easy to see the improvements from the inside, but perhaps not so
much from the outside :-)

        ATB,

                Michael.

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

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