[Libreoffice] [schedule] minutes of tech steering call ...

[Caolán McNamara]

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.