Re: [Libreoffice] 3.5 release from QA to point-zero

Hi,

[Please *first read my next mail* on this list !]


Let me also reply on the minutes of tech. steering call:

from Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (08-09-11 17:28)

>         + Cor's considerations on release timing

  Better: time available between Beta1 / RC1 and release.

>                 + existing schedule is here:
>                   http://wiki.documentfoundation.org/ReleasePlan#3.5_release
>                 + very vague, lots of factors and no data / heuristics (Thorsten)

  That is by intention. As written: "Goal: take a clear look at what
  influences the development and QA of 3.5.0, in order "

  So I wanted to gather the areas of interest first, rather
  then examples for every item.
  Sorry if that was not clear, or not inspiring ;-)

>                 + could try a slushy feature-freeze on master around an
>                   earlier release with new features (Norbert)

  Sounds interesting.

>                 + some new features have good QA coupling with their own
>                   builds eg. Jean Baptiste (Cedric)

  Some ...
  I think it would be good to know on which features that is
  and on which not.
  (BTW, I do like that co-operation ! )

>                 + lots of reasons already provided why next time would be
>                   better quality-wise than last time (Michael)

  Looks rather unspecified and does not wipe away remaining/new reasons.

>                 + not too late to discuss at the conference and move
>                   freeze dates by a week or two (Norbert)

  Do all working on features agree?

>                 + always a trade-off between quality, community fun,
>                   pace of development (Michael)

  No real argument. I am more interested in the question: do we want
  avoid another 3.4-style release?


>         + Release mgmt (Petr)
>                 + concern wrt. bugs in master - need some focus there
>                 + no more releases until after the conference
>         + QA update (Rainer)

>                 + master in v. good shape currently modulo a few annoying bugs
>                         + eg. PDF export from writer completely broken

  Only few annoying bugs might as well mean that too few people
  work with master..
  I file some, post some on IRC/dev@.
  (But also come across problems that are so time-consuming to
  try to make understandable / reproducible, that until now I
  did not.)
  Rainers does master-bugs. Mow many others do?
  We have to be careful for a 'I see no problems so there
  are no problems' trap.


>                 + monthly bug hunting session last week:
>                         + not so successful

  Alas. And not a signal that adds trust.


Cor Nouws wrote (06-09-11 22:41)

> [resend of my post from 2011-09-04, 20:38 UTC with one little change]

  Obviously, my more conceptual approach did not work.
  So this time, I will try to add some more content.


> So, items that come to my mind:
>
> - number and severity of changes on code
> how many difficult/basic stuff are touched in these months?
> We know that when so much is changed, for sure many nasty hidden
> older bugs will surface..

  I have deep respect for the work of Kohei, Eike and Marcus.
  But they do change a whole lot of stuff these days, weeks, months.
  Is it strange that we have to expect quite some unexpected
  side effects?
  We cannot on the one side complain that the old code is quite filled
  with oddities, mistakes, redundancies etc etc, and on the other
  hand do light on the risk of side effect with large code changes

  Same for other devs / area of development.

> - How much time can one annoying bug ask? Two day, two weeks?
> (many bugs show that is can be very time consuming)
>
> - what is the progress in the weak spots in our attention?
> Base e.g.

  Base, Windows, Mac

> - what can we expect for new large code chunks in the coming months
> or integration of some older CWS'es

  there will be, isn't it?

> - the increase in the number of people available for testing
> - how many people start working/testing with master/nightly builds?
> - how many issues see we from there?
> - and how fast are those solved?
> - development in the quality and the use of tools for testing
> - is attention in testing well spread over Windows / Linux / MacOS ?

  Do we see more or about the same activity by testers?
  Growth or decline in bugs?
  I read (about) bugs in BugZilla sometimes, that are annoying
  and regressions, yet did not make it to one of the most annoying
  gathering issues, and without doubt partly because of lack
  of attention of QA, either hard to simply reproduce. Compatibility
  with older versions, older document, ...

> - are there other releases/tasks that need attention during that time ?
>
> - how many people are available for beta-RC testing and fixing bugs ?
> e.g. the time of the year (Christmas, Western New year)

  Does it really make sense to have one release on Dec. 23 and the
  next one on Jan 6th?

> - can we attract many people for beta-testing
> (prize for the top-5 (clear, useful) issue submitting testers ?)

  Yeah, good idea :-)

> Also on the discussion we had before, there was a simple and sound idea
> from Norbert (3), worth to consider (expand the time between Beta/RC /
> release on Thursday / QA still need to use Daily Build)

  Good idea too.
  Maybe two/three weeks between Beta1 and Beta2 and the same for RC1 and
  RC2 is smart?
  Or, like what I heard from Ubuntu, a world wide three day bug hunting
  event with the first beta, so that the devs have some input for the
  weeks following that tests?

Kind regards,

> 1) http://lists.freedesktop.org/archives/libreoffice/2011-June/014201.html
> 2) http://wiki.documentfoundation.org/ReleasePlan#3.5_release
> 3) http://lists.freedesktop.org/archives/libreoffice/2011-June/014293.html


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