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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
