minutes of tech steering call ...

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

minutes of tech steering call ...

Attendees:
        + Michael, Caolan, Kendy, Andreas, Rainer, Timar,
          Tor, Thorsten, Petr, Francois, Norbert, Cedric

* Completed AA's
        + binned dlsym'd fontconfig & non-fontconfig X font code paths (Caolan)
        + avoid: completely junking gnome-vfs backend & startup hooks (Caolan)
                + glib not built internally, and system integration issues with gio
                + RHEL5 & similar vintage don't have gio => gnome-vfs still needed
        + put Rainer in touch with Gerv (Michael)
        + kill Adabas integration dead in master (Francois)
                + disabled for a release, removed next release

* AA still pending:
        + Easy Hacks - completion / fixing (Bjoern)
        + get SmartArt into master as an experimental feature (Thorsten)
        + remove old non-cairo cases (Caolan)
        + bin monochrome & paletised display support with prejudice (Caolan)

* Action Items
* QA feedback (Rainer)
        + short report concerning results of our German QA Meeting last weekend
                + lots of barbeque, fun, and some results
                + bugzilla - leave it at freedesktop.org or not ?
                        + collect goals & required features eg.
                          UNCONFIRMED as default & some timelines
                        + then discuss with freedesktop guys.
                        + concerns: wrt. compromises wrt. other projects
                        + probably: some day, one year out ? migrate away.
                        + decision in six months time.
                        + eg. automated access for bug reporting agent ?
                        + bugzilla setup easy, but upgrade / migration hard.
                + bug hunting ...
                        + try bug-hunting session each month:
                          every 1st Tuesday of a month, EU afternoon - night
                        + wiki page coming to list details
                        + main-page / August banner ads to encourage that
                        + goals: to confirm / triage bugs - no hacking skills
                          necessary
                + help quality
                        + getting out of step with code changes in places
                        + a common feeling, something should be done
AA: + contact / discuss with the documentation team to
                          find owners for help bugs (Rainer)
                        + Timar to help out with minor cleanups / removals
                + Extensions repo testing / status (Andreas Mantke)
                        + site is setup / working / published to website list
                        + http://extensions2.libreoffice.org/
                        + branding work improved, not opened for new accounts yet
                        + work on anti-spam account filtering ongoing
                        + populate with existing Free Software extensions
                        + contact extension authors to populate the site
                        + readying to go live.
        + graphical comparison tool
                - update regression tests ongoing

* Cross-compilation update (Tor)
        + what works
                + configure script configures for cross-compilation
                + make compiles native build-time tooling
                + then cross-compilation starts
                + for Windows - approx. 1/2 the way before errors,
                  due to missing pieces in MingW
                        + Jesus getting involved too, and re-appling
                          GSOC 2009 work to the problem from 'build'
                        + problematic msi creation tools, WINE ?
                + for iOS - gets quite far, nothing is linked
                        + Matus' work should help here.
                + for Android - tries to link things, much missing
                  from VCL etc.
                        + hopefully gtk3 / broadway work can help GUI-wise.
                + to PPC Mac from Intel Mac - not tried it much, in
                  theory the easiest target.
        + lots more work to do, but nothing really impossible
        + UI for embedded platforms requires much more work

* Releng bits (Petr)
        + 3.3.3 post-release roundup
                + out last week, no known regressions filed
        + future of 3.3 branch (Rainer)
                + QA meeting tested 3.3.3
                        + less community interest in testing 3.3.3
                        + eagerness to test new features etc.
                        + concern for wasted man-power on 3.3.x
                + what are our goals ?
                        + unify distro maintenance work
                        + keep security up-to-date
                        + key as balance for less stable point-zero versions etc.
AA: + communicate more minimal QA requirements for each release (Petr)
        + 3.4.1 status / roundup & 3.4.2
                + fdo#38590 charts seem to be leaking meta-file descriptors
                  as they are rendered (amazingly) - nasty.
                        + if in 3.4.0, no regression, release note & move on.
                + otherwise large numbers of bugs fixed, RC2 pre-release builds ready
                + should get announced tomorrow

* Release quality / complaints ... (Cor / Italo / Olivier)
        + presenters not present
        + extend the feature-freeze period for 3.5 ?
                + Norbert: may not help people fix things, just move
                  their work to the next generation.
                + Petr: earlier Beta / Alpha releases ? need to be useable
                  and QA done continuously / before freeze as well.
                + Norbert: 3.4 impacted by merging m106, don't have this
                  issue next time around
                + Caolan: nightly builds are now working, and should help
                  get QA access to the code, and insight into progress
                + Caolan: more automatic regression tests are coming too
                + Rainer: not much penetration in QA team of nightly
                  snapshots, most don't know where to find them.
AA: + check out nightlies, and encourage others to use (Rainer)
                + Nobert: treat feature-freeze as a release for QA purposes ?
                + Caolan: master perception - should be always ok, ready to ship
                  at any time - not actually broken modulo occasional build issues
        + the future should not be as bad as the 3.4.0 panic.

* Posting TSC minutes on the blog ...
        + Norbert: wording is very terse, not enough context, not suitable
          for mass public consumption.
        + Suggestion: needs to be expanded, and made more comprehensible,
          someone who wants that can/should do it.

* library merging plan (Matus)
        + didn't make it to the call

* gettext - should we use it for everything ?
        + punt until next time ... need: Caolan, Bjoern
        + preliminary thoughts:
                + if no slower - cold / warm start
                + if no bigger - bloating codebase
                + then should use it, otherwise as a fallback.
        + is fallback mode useful for translators ?
                + not so useful for entirely new language
                  because the code needs lots of touching
                + could be useful for established translators who
                  want to check their work quickly

* Norbert's whitespace cleaning C app
AA: + review it ASAP (Kendy, Tor)
        + is the speed / correctness trade-off right ?
        + speedup is 2x orders of magniture over sed on a 36hr conversion
        + Tor: how fast is 'expand' as an alternative ?

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

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

Re: minutes of tech steering call ...

On Thu, Jun 23, 2011 at 07:27:36PM +0100, Michael Meeks wrote:
>
> * Completed AA's
>       + kill Adabas integration dead in master (Francois)
> + disabled for a release, removed next release

I have found no evidence it is still used, but there still may be people
living under a rock somewhere.
This way it gives them a chance to re-enable the Adabas D driver without
too much work after the first 3.5 release.

> AA: + check out nightlies, and encourage others to use (Rainer)

I'm packaging snapshots of -master in pkgsrc-wip:

http://pkgsrc-wip.sourceforge.net/
http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/libreoffice/

A handful of people are downloading the distribution files; almost no
feedback apart from wiz@ so far.

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

Re: minutes of tech steering call ...

In reply to this post by Michael Meeks
Hi *,

Michael Meeks wrote (23-06-11 20:27)

> * Release quality / complaints ... (Cor / Italo / Olivier)
> + presenters not present

Apologies for that - but it was about what I expected. (Have to try to
focus on making a living during the day-hours ;-) )

> + extend the feature-freeze period for 3.5 ?
> + Norbert: may not help people fix things, just move
>  their work to the next generation.
> + Petr: earlier Beta / Alpha releases ? need to be useable
>  and QA done continuously / before freeze as well.
> + Norbert: 3.4 impacted by merging m106, don't have this
>  issue next time around
> + Caolan: nightly builds are now working, and should help
>  get QA access to the code, and insight into progress
> + Caolan: more automatic regression tests are coming too
> + Rainer: not much penetration in QA team of nightly
>  snapshots, most don't know where to find them.
> AA: + check out nightlies, and encourage others to use (Rainer)
> + Nobert: treat feature-freeze as a release for QA purposes ?
> + Caolan: master perception - should be always ok, ready to ship
>  at any time - not actually broken modulo occasional build issues
> + the future should not be as bad as the 3.4.0 panic.

Thanks for discussing the subject and the ideas brought forward.

I am quite optimistic about what we will achieve in the future (...) and
very positive about our improvements.
On the other hand, we do not yet know how
  - the time of the year (Christmas, Western New year);
  - the speed of the growth of people involved in QA;
  - the fact that QA-time has to be devided among various versions
simultaneously,
  - etc,
will affect the reality in 6 months from now :-)

Plus - especially with the unfortunate experience from 3.4.0, and to do
something good for users, testers, marketing etc - IMO it is better that
in the end we have three weeks extra, than that we lack three days.
So I would really love to be on the save side ..

However, we do not have to decide that exactly right now, do we?!
So, imagine we would choose for say a three or four weeks extra between
freeze and release, when should that have to be decided? Somewhere
September, early October? Then we can hold on the detailed discussion
and decision on this subject until then..

Sounds OK?

Best,

--
  - Cor
  - http://nl.libreoffice.org

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

Re: minutes of tech steering call ...

In reply to this post by Michael Meeks
Michael Meeks wrote (23-06-11 20:27)

> * Posting TSC minutes on the blog ...
> + Norbert: wording is very terse, not enough context, not suitable
>  for mass public consumption.
> + Suggestion: needs to be expanded, and made more comprehensible,
>  someone who wants that can/should do it.

Short highlights  + link to mail archive might be useful too..


--
  - Cor
  - http://nl.libreoffice.org

_______________________________________________
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 tech steering call ...

On Thu, Jun 23, 2011 at 6:11 PM, Cor Nouws <[hidden email]> wrote:
> Michael Meeks wrote (23-06-11 20:27)
>
>> * Posting TSC minutes on the blog ...
>>        + Norbert: wording is very terse, not enough context, not suitable
>>          for mass public consumption.
>>        + Suggestion: needs to be expanded, and made more comprehensible,
>>          someone who wants that can/should do it.
>
> Short highlights  + link to mail archive might be useful too..

I think the problem is not to make them shorter, but to make them
'longer', more digestible for people who do not follow these call and
the dev-ML in general.
I'm thinking about the difference between reading the linux-kernel
mailing list and reading, once a week an highlight of the noticeable,
interesting event by Colbert on LWN.
The later is a great thing, I enjoy very much reading them... but I,
for one, would be completely incapable to do what Jonathan Corbet
does, even If I read every email of linux-kernel and had nothing else
to do but that...

Proper reporting for a wider audience is a skill in and of itself.

Giving these 'minutes' as-is to a wider audience is begging for
blogger and journalist to mis-understand and mis-quote them. Most of
them would not use such minute for a dev ML as a 'source', but if TDF
'publish' them, then it is another ballgame...

I mean, looks at what happen, even when communication expert spend
time to have a long conversation with a journalist: the headline is
'TDF not production-ready until August'.
So now imagine th same journalist, which is very unlikely to scour the
dev-ML for info, now get that terse and lingo-prone summary in his
rss-feed ? I dare not imagine what the next 'headline' will be....

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

Re: minutes of tech steering call ...

Hi Norbert,
Norbert Thiebaud wrote (24-06-11 01:32)

> On Thu, Jun 23, 2011 at 6:11 PM, Cor Nouws<[hidden email]>  wrote:
>> Michael Meeks wrote (23-06-11 20:27)
>>
>>> * Posting TSC minutes on the blog ...
>>>         + Norbert: wording is very terse, not enough context, not suitable
>>>           for mass public consumption.
>>>         + Suggestion: needs to be expanded, and made more comprehensible,
>>>           someone who wants that can/should do it.
>>
>> Short highlights  + link to mail archive might be useful too..
>
> I think the problem is not to make them shorter, but to make them
> 'longer', more digestible for people who do not follow these call and
> the dev-ML in general.
> I'm thinking about the difference between reading the linux-kernel
> mailing list and reading, once a week an highlight of the noticeable,
> interesting event by Colbert on LWN.
> The later is a great thing, I enjoy very much reading them... but I,
> for one, would be completely incapable to do what Jonathan Corbet
> does, even If I read every email of linux-kernel and had nothing else
> to do but that...
>
> Proper reporting for a wider audience is a skill in and of itself.
>
> Giving these 'minutes' as-is to a wider audience is begging for
> blogger and journalist to mis-understand and mis-quote them. Most of
> them would not use such minute for a dev ML as a 'source', but if TDF
> 'publish' them, then it is another ballgame...
>
> I mean, looks at what happen, even when communication expert spend
> time to have a long conversation with a journalist: the headline is
> 'TDF not production-ready until August'.
> So now imagine th same journalist, which is very unlikely to scour the
> dev-ML for info, now get that terse and lingo-prone summary in his
> rss-feed ? I dare not imagine what the next 'headline' will be....

I agree with this potential problem.
What if we thrive for a clear description to one/few of the highlights
(+ link to mail archive as reference) ?

--
  - Cor
  - http://nl.libreoffice.org

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

Re: minutes of tech steering call ...

In reply to this post by Cor Nouws
Cor Nouws wrote
Plus - especially with the unfortunate experience from 3.4.0, and to do
something good for users, testers, marketing etc - IMO it is better that
in the end we have three weeks extra, than that we lack three days.
So I would really love to be on the save side ..
Thank you Cor for listening to the users instead of the "mighty schedule"

BTW since only Betas can be installed in parallel with the stable build under Windows and that was not added to the 3.4.x branch (at least from my understanding) I guess Windows Beta testers will have to wait for 3.5.x, right?
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: minutes of tech steering call ...

Hi Pedro,

plino wrote (24-06-11 02:03)
> Cor Nouws wrote:
>>
>> Plus - especially with the unfortunate experience from 3.4.0, and to do
>> something good for users, testers, marketing etc - IMO it is better that
>> in the end we have three weeks extra, than that we lack three days.
>> So I would really love to be on the save side ..
>>
>
> Thank you Cor for listening to the users instead of the "mighty schedule"

Well,  thanks for the complement .. :-)
But of course  ... I don't think that it is the intention of  the
"mighty schedule" to hurt anyone or let alone the project :-) - we are
all learning how this should work best for us. And that definitely will
change over the months, years...

> BTW since only Betas can be installed in parallel with the stable build
> under Windows and that was not added to the 3.4.x branch (at least from my
> understanding) I guess Windows Beta testers will have to wait for 3.5.x,
> right?

Well, I don't see any betas coming for the 3.4.x branch, so whether is
has been added or not, does not make sense.
I only can point to my favourite page:
http://wiki.documentfoundation.org/Installing_in_parallel

I hope that helps people to run more versions (early versions) on
Windows too, so that it give them the opportunity to give feed back in
an early stage.
(Personal note: I really appreciate that I have not (or only seldom) to
work with Windows any more. Public drawback: I cannot do serious testing
there and already find it hard to understand, to follow the items going
on Windows.)

Cheers,

--
  - Cor
  - http://nl.libreoffice.org

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

Re: minutes of tech steering call ...

Cor Nouws wrote
Well, I don't see any betas coming for the 3.4.x branch, so whether is
has been added or not, does not make sense.
Unless TDF is going to adopt the absurd Chrome (and now Firefox) version model, the next version should be 3.5.0 indeed. I guess we (Windows users) will have to wait :)

Cor Nouws wrote
I only can point to my favourite page:
http://wiki.documentfoundation.org/Installing_in_parallel

I hope that helps people to run more versions (early versions) on
Windows too, so that it give them the opportunity to give feed back in
an early stage.
As I mentioned before, that is useful for a very limited number of Windows users. If TDF wants a significant number of  Windows beta testers that simply won't do.

Cor Nouws wrote
(Personal note: I really appreciate that I have not (or only seldom) to
work with Windows any more. Public drawback: I cannot do serious testing
there and already find it hard to understand, to follow the items going
on Windows.)
I'm sure more Windows users would be available for serious testing if TDF took the Windows users more seriously and in proportion to the platform importance (given the sheer number of users)

http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: minutes of tech steering call ...

plino wrote (24-06-11 09:03)
> Cor Nouws wrote:
>>
>> Well, I don't see any betas coming for the 3.4.x branch, so whether is
>> has been added or not, does not make sense.
>
> Unless TDF is going to adopt the absurd Chrome (and now Firefox) version
> model, the next version should be 3.5.0 indeed.

Hmm - apart from your off topic comment on Chrome/FireFox - I see no
rationale for that.
There is a monthly schedule for bug-fix releases that is very important
for all kind of users. See http://wiki.documentfoundation.org/ReleasePlan

> I guess we (Windows users) will have to wait :)

Wait for what? I don't understand what you are trying to say here.

>> I only can point to my favourite page:
>> http://wiki.documentfoundation.org/Installing_in_parallel
>>
>> I hope that helps people to run more versions (early versions) on
>> Windows too, so that it give them the opportunity to give feed back in
>> an early stage.
>
> As I mentioned before, that is useful for a very limited number of Windows
> users.

But those that can, should use it and help others...

> If TDF wants a significant number of  Windows beta testers that
> simply won't do.

And as known, 3.5 betas will install without conflict with the 3.4.x
installation, so where is the problem?

>> (Personal note: I really appreciate that I have not (or only seldom) to
>> work with Windows any more. Public drawback: I cannot do serious testing
>> there and already find it hard to understand, to follow the items going
>> on Windows.)
>
> I'm sure more Windows users would be available for serious testing if TDF
> took the Windows users more seriously and in proportion to the platform
> importance (given the sheer number of users)

I know no evidence that Windows (users) is (are) not taken seriously.
I think it will help if people try more serious to improve on where we
are, also with QA/testing, rather then complain.

Best,

--
  - Cor
  - http://nl.libreoffice.org

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

Re: minutes of tech steering call ...

Cor Nouws wrote (24-06-11 09:21)

> I know no evidence that Windows (users) is (are) not taken seriously.
> I think it will help if people try more serious to improve on where we
> are, also with QA/testing, rather then complain.

Hmm, while slicing an excellent mango (hmm ;-) , my thoughts drifted to
this subject again (for the last time today!).
I have the feeling of fighting some acid rain, when replying to your
mail Pedro. And indeed, I can imagine that this has been caused by the
words used by some developers, in a much older thread. Some are so much
convinced of what they think, and also bring that across in such a way,
that it easily gives the impression that other opinions are moot or so.
Which is a sad situation :-(
That might be an explanation for the feeling that I get with your mail.
But the again, probably I must have had written, expressed this before.
So after acknowledging, my advise would still be the same: understand
and improve ;-)

Have a nice day :-)
Cor

--
  - Cor
  - http://nl.libreoffice.org

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

Re: minutes of tech steering call ...

In reply to this post by Cor Nouws
Michael @ OP - awesome set of notes!

Cor @
> I only can point to my favourite page:
> http://wiki.documentfoundation.org/Installing_in_parallel

Even though I have two build configs (3.4 and master), OOo3.2 and the 3.4 release installed, I have been frustrated in doing full triage/testing and other qa by no access to 3.3  -  I can see why that is your favorite page and now I can see why you (and others) are able to test issues in any version.  

Thank you so much!  
LeMoyne
Michael Meeks Michael Meeks
Reply | Threaded
Open this post in threaded view
|

Re: minutes of tech steering call ...

In reply to this post by Cor Nouws

On Fri, 2011-06-24 at 01:11 +0200, Cor Nouws wrote:
> > * Posting TSC minutes on the blog ...
> > + Norbert: wording is very terse, not enough context, not suitable
> >  for mass public consumption.
> > + Suggestion: needs to be expanded, and made more comprehensible,
> >  someone who wants that can/should do it.
>
> Short highlights  + link to mail archive might be useful too..

        Certainly - anyone is welcome to do the work and come up with that
content - the minutes are public; if someone writes a nice summary, I'm
happy to quickly sanity check it before release too.

        HTH,

                Michael.

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

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

Re: minutes of tech steering call ...

In reply to this post by Cor Nouws
Hi Cor,

On Fri, 2011-06-24 at 01:09 +0200, Cor Nouws wrote:
> Apologies for that - but it was about what I expected. (Have to try to
> focus on making a living during the day-hours ;-) )

        Sure, sure ...

> > + extend the feature-freeze period for 3.5 ?
> > + Norbert: may not help people fix things, just move
> >  their work to the next generation.
..
> Thanks for discussing the subject and the ideas brought forward.

        Hey - I'm only sorry that there was no-one there to argue the other
point of view ;-)

> On the other hand, we do not yet know how
>   - the time of the year (Christmas, Western New year);
>   - the speed of the growth of people involved in QA;
>   - the fact that QA-time has to be devided among various versions
> simultaneously,
>   - etc,
> will affect the reality in 6 months from now :-)

        Of course; predicting the future is hard.

> Plus - especially with the unfortunate experience from 3.4.0, and to do
> something good for users, testers, marketing etc - IMO it is better that
> in the end we have three weeks extra, than that we lack three days.
> So I would really love to be on the save side ..

        So - the problem is, there is really no safe side, it is a balance.
There is no guarantee that people will work more on bug-fixing if we
feature freeze earlier, nor is there a guarantee that people will do QA
and find the bugs until we are in the late RC phase no matter how early
we release. Much QA seems to be deferred to post release - when it seems
most people really start testing ;-). So this is some sort of
psychological game, which (I hope) we already play quite well by
releasing and then doing lots of iterative incremental improved
versions.

        Indeed - by freezing earlier we could potentially make things worse ;-)
because QA will not have started at all, and thus there will apparently
be no bugs to fix, and hackers will then get really stuck into working
on another branch, which will diverge far more from the code we're
releasing, such that they have less interest / ability to fix bugs in
the stable version by the time QA arrives in earnest so ...

        So, this all needs to be discussed explained; that is best done in
person I think.

> However, we do not have to decide that exactly right now, do we?!

        Quite. So - what I think we should do is to propose a joint talk on the
topic at the LibreOffice conference in Paris in October - preferably
with some good assessment of the quality of master at that time; then we
can decide whether to move the existing (December) freeze date forward
or back at our leisure - and over beer.

        How does that sound ? any chance you could recruit a suitable panel ?
I'd want Caolan, Petr, myself and Bjoern on it - and yourself, Rainer,
and whomever else you can choose that is actively working on QA / etc.
Any chance you can bash off a web-form submissions at:

        http://conference.libreoffice.org/submit-your-paper/

        Thanks,

                Michael.

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


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

[cairo] minutes of tech steering call

In reply to this post by Michael Meeks
On Thu, 2011-06-23 at 19:27 +0100, Michael Meeks wrote:
> + remove old non-cairo cases (Caolan)
> + bin monochrome & paletised display support with prejudice (Caolan)

Now that I look at it properly the non-cairo code path was vertical
text, not monochrome X :-), oops. Will have a poke at that over the
week.

C.

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

[schedule] minutes of tech steering call ...

In reply to this post by Pedro
On Thu, 2011-06-23 at 17:03 -0700, plino wrote:
> Cor Nouws wrote:
> >
> > Plus - especially with the unfortunate experience from 3.4.0, and to do
> > something good for users, testers, marketing etc - IMO it is better that
> > in the end we have three weeks extra, than that we lack three days.
> > So I would really love to be on the save side ..
> >
>
> Thank you Cor for listening to the users instead of the "mighty schedule"

The underlying assumption here seems to be that there is only one tool
available, that of "changing the schedule" which can be used to fix
something or a set of somethings.

I'd prefer to talk in terms of the explicit problems to be solved,
instead of talking in terms of a single pre-selected solution, otherwise
we end up talking about a schedule hammer we're holding and everything
begins to look like a nail we can bang it with.

[problem a: getting the product out the door]
[problem b: knowing in advance when the product goes out the door]
[problem c: seeing your work getting used]

e.g. presumably it's not a problem for users that each release is a
fairly fixed X months apart as an issue in and of itself. For me it's a
good thing, I know when the release is going to happen and I can plan
effectively from that. I know when my changes will appear in a released
product and they get out there into the wider world. If something misses
a release, I don't have to wait too long for the next one.

If releases are e.g. 12 or 18 months apart there is *huge* pressure to
stuff something in that isn't quite finished in order to get it out
there if I need it to be in there in 6 months time. While if its 3
months apart then it can wait until the next one when finished.

If major releases are far apart the major release spirals out of
control, e.g. OpenOffice.org 2 was *forever* getting finished. There
ends up being a lot of pressure to start hacking the last stable version
instead and ship a lot of minor version updates that do more than
obvious bug fixes. That sucks development and testing resources out of
the development branch, which delays it further. Developers that
provided some nifty new feature for the next stable release don't get to
see it shipped for ages, which demotivates them from working on it.

If there are other problem, especially with respect to the mention of an
"unfortunate 3.4.0 experience", it'd probably be best to enumerate the
exact problems and see if they are outcomes of the schedule, or if they
are maybe tangential issues, e.g. unavailability of daily builds for
early testing, insufficient automated testing, insufficient notification
for updating documentation, platform specific nasties, or so on.

C.

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

Re: minutes of tech steering call ...

In reply to this post by Michael Meeks
Hi Michael,

Michael Meeks wrote (24-06-11 10:52)

> On Fri, 2011-06-24 at 01:09 +0200, Cor Nouws wrote:
>> Apologies for that - but it was about what I expected. (Have to try to
>> focus on making a living during the day-hours ;-) )
>
> Sure, sure ...
>
>>> + extend the feature-freeze period for 3.5 ?
>>> + Norbert: may not help people fix things, just move
>>>  their work to the next generation.
> ..
>> Thanks for discussing the subject and the ideas brought forward.
>
> Hey - I'm only sorry that there was no-one there to argue the other
> point of view ;-)

Don't worry - we're not going to forget you :-p

>> On the other hand, we do not yet know how
>>    - the time of the year (Christmas, Western New year);
>>    - the speed of the growth of people involved in QA;
>>    - the fact that QA-time has to be devided among various versions
>> simultaneously,
>>    - etc,
>> will affect the reality in 6 months from now :-)
>
> Of course; predicting the future is hard.
>
>> Plus - especially with the unfortunate experience from 3.4.0, and to do
>> something good for users, testers, marketing etc - IMO it is better that
>> in the end we have three weeks extra, than that we lack three days.
>> So I would really love to be on the save side ..
>
> So - the problem is, there is really no safe side, it is a balance.

Sure, sure.

> There is no guarantee that people will work more on bug-fixing if we
> feature freeze earlier, nor is there a guarantee that people will do QA
> and find the bugs until we are in the late RC phase no matter how early
> we release.

What we do know (1+1=2), is that if there is a limited amount of people
doing QA, providing them more time (weeks) will result in more testing.

> Much QA seems to be deferred to post release - when it seems
> most people really start testing ;-).

It looks like. And also is true for some part.
Therefore the step to make it possible to install betas alongside the
stable version, is a major improvement of our work flow.

> So this is some sort of psychological game, which (I hope)
> we already play quite well by releasing and then doing lots
> of iterative incremental improved versions.

I agree with the merits of that approach.
Don't know however if that alone will make more people do QA. Serious
testing and reporting are time-consuming. So starting again with a fresh
version every few weeks, costs time...

> Indeed - by freezing earlier we could potentially make things worse ;-)

Warning: you're going to loose me completely in the next paragraph.

> because QA will not have started at all, and thus there will apparently
> be no bugs to fix, and hackers will then get really stuck into working
> on another branch, which will diverge far more from the code we're
> releasing, such that they have less interest / ability to fix bugs in
> the stable version by the time QA arrives in earnest so ...

Do misunderstand the meaning of 'freezing'? I understand it as the point
from where only bug fixes are allowed to the branch.
So a longer time frame without large clean-up, re-factoring, other smart
improvements and new features. Definitely this gives more time to find
and fix bugs.
The more QA, people, the faster it goes, of course. But that is another
matter.
And of course, QA has to be a continuous state. So a possible longer
time from freeze to release, would IMO not mean that we advise people to
start later with testing :-)

Any change that the time from freeze to release can be too long, and
thus a waste of developer time? I can hardly imagine: if less time is
needed for fixing bugs, more time is left for major work on the master.

> So, this all needs to be discussed explained; that is best done in
> person I think.
>
>> However, we do not have to decide that exactly right now, do we?!
>
> Quite. So - what I think we should do is to propose a joint talk on the
> topic at the LibreOffice conference in Paris in October - preferably
> with some good assessment of the quality of master at that time; then we
> can decide whether to move the existing (December) freeze date forward
> or back at our leisure - and over beer.

OK, half October .. till December 5 is only 7 weeks.
Deciding at that moment, holds the risk that developers suddenly have
say only 3 or 4 weeks left for finishing major work, in stead of 7.
IMO, that is not fair.

Though of course the venue to discuss it, is excellent (which is not yet
a promise from my side that I will be there..)
But still, I would very much prefer to keep an eye on all that is
related the next months, and see if we can discuss this on list, during
a conf. call, somewhere the next months.
Then we can pick up the essentials from my previous mail too: the
reasons to be on the very safe side now.

> How does that sound ? any chance you could recruit a suitable panel ?
> I'd want Caolan, Petr, myself and Bjoern on it - and yourself, Rainer,
> and whomever else you can choose that is actively working on QA / etc.
> Any chance you can bash off a web-form submissions at:
>
> http://conference.libreoffice.org/submit-your-paper/

Still, having a meeting discussing with people at the table how we go
forward with all the stuff, is a great opportunity.
OK?

Cheers,

--
  - Cor
  - http://nl.libreoffice.org

_______________________________________________
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 tech steering call ...

On Fri, Jun 24, 2011 at 6:00 PM, Cor Nouws <[hidden email]> wrote:

>>        Indeed - by freezing earlier we could potentially make things worse
>> ;-)
>
> Warning: you're going to loose me completely in the next paragraph.
>
>> because QA will not have started at all, and thus there will apparently
>> be no bugs to fix, and hackers will then get really stuck into working
>> on another branch, which will diverge far more from the code we're
>> releasing, such that they have less interest / ability to fix bugs in
>> the stable version by the time QA arrives in earnest so ...
>
> Do misunderstand the meaning of 'freezing'? I understand it as the point
> from where only bug fixes are allowed to the branch.
> So a longer time frame without large clean-up, re-factoring, other smart
> improvements and new features. Definitely this gives more time to find and
> fix bugs.

Well true except that it freeze _that_ branch... but it does not
_force_ people to stop working on master.

So what I understand Michael saying is:

1/ you freeze and create the 3.X branch
2/ little test is done on 3.X branch for the reasons aforementioned
3/ with little bug reporting, in the mean-time most dev go back to
hacking on master (without freeze)
4/ Just before or just after release there is a rush of QA activity
that uncover all these latent bug...
5/ by this time the dev have been working on something else for 3-6-9
weeks (pick the number of week you want the 'freeze to be')
6/ the level or interest to go back in time (code-wise) is vanishing...

iow: QA should really be a continuous process, just as dev. that is QA
should (also) be done on master, with an emphasis on pre-freeze
period, so that bugs are uncovered pre-freeze as much as possible.
Then the freeze period is the time when: we branch the code and limit
the change to it to fix-bug and QA _intensify_ right when we freeze so
that bug report pour in soon after the freeze, not 3 -4 weeks after
it.

Freezing, in my mind means: we have something close enough of being
good. we freeze and spend some time to make it release-good. but for
that to work, it need a concerted effort of all, not just dev stopping
to code on that branch. By moving the testing more toward master, we
could minimize these epic 'rush' to RC that I have noticed so far,
when all the full time dev are swamped, rushing to fix RC in time...
It is not good for them, and it is not good for the rest of us nor for
master as we are both essentially orphaned for a 3-4 week period, when
our 'champions' have no time and little patience to help and guide...

As caolan said in another post, 'master' should no be seen as
'unstable'. 'master' should be seen as the latest version about to be
released... Sure there will be time when master breaks... but that
should be rare and short-lived. And it is the Dev's responsibility to
take master breakage seriously, it is a 'culture' that we need to
develop and engrain at the core of our 'community'.
We are making progress toward that goal, notably by improving the
automation and tooling around master. Right now Linux and Mac build
breakage are typically detected in less than 30 minutes... Windows is
still a problem, but it is not hopeless... There is a lot of work to
be done to automate testing, and QA can help with that. In the end, as
master become more and more 'reliable' we should be able to convince
QA volunteers that testing Dailies is useful, that the sooner a bug is
caught the cheaper it is to fix... and if Dailies get some coverage
then the 'frozen' version will be that much more stable and there
won't need such a long and epic 'stabilization' period.

I think that one problem may also be an approach to QA: testing
dailies doe not mean 'run the formal test procedure that is needed for
the _validation_ of a Release, it means download it regularly and
'play' with it... run some test, run some work-flow you like or you
think can be tricky, run different test on the next dailies (unless
you try to verify if a bug is fixed)... heck even randomly pick a
dozen or what-many you have time for today and run these on that
daily... tomorrow, or next week-end do another set on the _then_
daily...
Again the point of the exercise is not to 'validate' a version, but to
try to stumble upon bugs as early as possible.... as a bonus side
effect that can also provide 'usability' feed-back on feature while
they are developed... again:the sooner a problem is detected the
cheaper it is to fix.

We could also 'formalize' that a bit by formally producing 'weeklies'
(i.e pick a dailies and 'promote' it) and setup Litmus so that people
could log-in and test the 'release of the week'. Of course in that
case the goal is not necessarily to cover everything every week at all
cost..


> The more QA, people, the faster it goes, of course. But that is another
> matter.
> And of course, QA has to be a continuous state. So a possible longer time
> from freeze to release, would IMO not mean that we advise people to start
> later with testing :-)

Then the question is How would 'freezing' improve that (motivate
poeple to do early testing)

>
> Any change that the time from freeze to release can be too long, and thus a
> waste of developer time? I can hardly imagine: if less time is needed for
> fixing bugs, more time is left for major work on the master.

Changing the freeze date has no impact what-so-ever on the amount of
bug or the time it takes to fix them...
I must be missing your point here...


>
>>        So, this all needs to be discussed explained; that is best done in
>> person I think.
>>
>>> However, we do not have to decide that exactly right now, do we?!
>>
>>        Quite. So - what I think we should do is to propose a joint talk on
>> the
>> topic at the LibreOffice conference in Paris in October - preferably
>> with some good assessment of the quality of master at that time; then we
>> can decide whether to move the existing (December) freeze date forward
>> or back at our leisure - and over beer.
>
> OK, half October .. till December 5 is only 7 weeks.
> Deciding at that moment, holds the risk that developers suddenly have say
> only 3 or 4 weeks left for finishing major work, in stead of 7.
> IMO, that is not fair.

That is the 'norm'... the point of continuous dev is that everyday
could be release day... but since we release fairly often the
consequence of not being ready for
a given release is not that dire...

'Major work' is typically done in a feature-branch.. and that feature
branch is merged when it is ready not when the schedule say so. The
whole idea behind 'time-based-released' is that you release what is
ready at the time you've chosen. not cram the development to squeeze
it in time....

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

Re: minutes of tech steering call ...

Hi Norbert, *,

Norbert Thiebaud wrote (25-06-11 02:21)
> On Fri, Jun 24, 2011 at 6:00 PM, Cor Nouws<[hidden email]>  wrote:

>> Do misunderstand the meaning of 'freezing'? I understand it as the point
>> from where only bug fixes are allowed to the branch.
>> So a longer time frame without large clean-up, re-factoring, other smart
>> improvements and new features. Definitely this gives more time to find and
>> fix bugs.
>
> Well true except that it freeze _that_ branch... but it does not
> _force_ people to stop working on master.
>
> So what I understand Michael saying is:
>
> 1/ you freeze and create the 3.X branch
> 2/ little test is done on 3.X branch for the reasons aforementioned

  IMO that is a crucial effect to *avoid*.
And indeed, I see no reason why that would be a natural thing happening.
If there is a moment that we know: QA on this build is important, do
this ... that will help focussing :-)

> [...]

( Now I snip a whole lot of words from you with valuable aspects of
QA<>developmet etc.
I expect much of it will be used either by improving the process over
time, or by establishing the topics needed at a certain moment for
judging/choosing what is the best time-set for 3.5.0. )


>> The more QA, people, the faster it goes, of course. But that is another
>> matter.
>> And of course, QA has to be a continuous state. So a possible longer time
>> from freeze to release, would IMO not mean that we advise people to start
>> later with testing :-)
>
> Then the question is How would 'freezing' improve that (motivate
> poeple to do early testing)

Not earlier compared to the moment of freezing. But earlier compared to
the moment of releasing. Thus more time available for that specific testing.

>> Any change that the time from freeze to release can be too long, and thus a
>> waste of developer time? I can hardly imagine: if less time is needed for
>> fixing bugs, more time is left for major work on the master.
>
> Changing the freeze date has no impact what-so-ever on the amount of
> bug or the time it takes to fix them...
> I must be missing your point here...

Hmm, it looks as if I tried to answer a non-existing question.

>> OK, half October .. till December 5 is only 7 weeks.
>> Deciding at that moment, holds the risk that developers suddenly have say
>> only 3 or 4 weeks left for finishing major work, in stead of 7.
>> IMO, that is not fair.
>
> That is the 'norm'... the point of continuous dev is that everyday
> could be release day... but since we release fairly often the
> consequence of not being ready for a given release is not that dire...
>
> 'Major work' is typically done in a feature-branch.. and that feature
> branch is merged when it is ready not when the schedule say so. The
> whole idea behind 'time-based-released' is that you release what is
> ready at the time you've chosen. not cram the development to squeeze
> it in time....

Yes, that is clear and sounds sane.
However, as developer you look at the calendar too, and will sometimes
make some estimates about what you can/would like to do, in order to get
a major work done for a minor release. Therefore I argue that it would
not be fair to decide on 7 weeks from the deadline, that it is shortened
by 3 or 4 weeks.

Regards,

--
  - Cor
  - http://nl.libreoffice.org

_______________________________________________
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 tech steering call ...

On Sat, Jun 25, 2011 at 4:52 PM, Cor Nouws <[hidden email]> wrote:
>> [...]
>
> ( Now I snip a whole lot of words from you with valuable aspects of
> QA<>developmet etc.

Yeah, sometime I tend to to suffer from logorrhea :-)

>
>
>>> The more QA, people, the faster it goes, of course. But that is another
>>> matter.
>>> And of course, QA has to be a continuous state. So a possible longer time
>>> from freeze to release, would IMO not mean that we advise people to start
>>> later with testing :-)
>>
>> Then the question is How would 'freezing' improve that (motivate
>> poeple to do early testing)
>
> Not earlier compared to the moment of freezing. But earlier compared to the
> moment of releasing. Thus more time available for that specific testing.
>

Ok, let me try to reformulate the problem:

Formal testing of a Beta/Rc require an large amount of work just to
regression test things... A lot of these tests are not expected to
yield bug, especially after the first Beta (that is, regression would
be mostly found at that point, and hopefully very few would be
introduced by subsequent fixes)
So a test window of 1 week, will be use mostly doing that and not as
much used to discover new bugs and test new function exhaustively.

Hence the proposal become: make the release rate of Beta/RC slower.
and 5 beta/RC at two week interval would yield better result than 10
Beta/RC at one week interval.

Do I get that right ?

If that is indeed the crux of the argument, then I would suggest:

Expand the time between Beta/RC to two weeks (maybe 3 for the first
beta?) (I would also suggest release on Thursday so that feedback from
the second week-end have a chance to be fixed before the next release)
But then, QA still need to use Daily Build, as much as possible,
during the period to confirm that bugs found in the current Beta/RC
are indeed fixed to satisfaction _before_ the next Beta/RC comes out.
In other words, use a continuous QA process on top of a formal
Release-Based QA, to limit the number of formal Release-QA while
maintaining a good pace of fixing...


Norbert

PS: with the merging of the git repos, it will become fairly trivial
to identify a 'build' using the git-sha of the commit that was used to
build it.
So if, when we close a bug in Bugzilla, we mention the commit-sha that
is associated with the fix, it should be relatively easy to determine
if a given daily build is supposed to include the fix.
Heck we could even make that a web-service: give the sha of your
version and the sha associated with a bug in bugzilla and it tells you
if that bug was meant to be fixed on that version of not....

(for example:  if [ "($git merge-base $build_sha $bugfix_sha)" =
"$bugfix_sha" ] ; then echo "$bugfix_sha Fixed in $build_sha" ; fi )
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12