Hello everyone :) Mox, thanks for your reply.
On 18/12/2006, at 6:58 PM, Mox Soini wrote:
While I agree that 3 months is a tight schedule for all the quality checkingwork etc, I think there would be very big danger of slowing down thedevelopment and lower quality of the products, if the release schedule wouldbe longer than 3 months.Clytie: you already found the solution: you do not have to QA every release.QA only those releases that fit to your schedule.
I think we still have to find a release interval that produces a product of the quality level we want. It's not just about the needs and resources of each project: it's about the result.
We have to balance the resources available with our goals, the expectations of our users and the competition of other products.
If, in order to achieve a quality product, a significant number of OpenOffice.org projects would have to release less often, then our release interval is too short.
Is our product currently of the quality we want and need to achieve? Does it match up to its competition? Does it meet general user expectations?
All this comes down to size of the codebase (complexity) and the amount ofchanges (fastness).
Yes indeed, but it's also about the quality of the product. If we have a lot of change in the codebase, we have to be able to release an enhanced product which still attains our quality goals.
OpenOffice.org is one of the big open source codebases. It is not as big asLinux kernel, but it is bigger than Mozilla.Kernels are released about EVERY TWO MONTHS. And there is very good reason for it: in just two months, the kernel has already changed more than manyother products/projects in a year or two.
The kernel is not userland. We're not dealing with the same situation. If it can be released every two months and meet its quality standard, that's fine. Can we release every three months and meet our quality standard?
Also OpenOffice.org gets lot's of changes in every month. In order to MAINTAIN good quality of the codebase, it is very important to releasequality-controlled releases often. Otherwise too many bugs would not benoticed. Look at this: - OOo 2.1 : 2 months of development, the last 1 month of focused QA- OOo 1.1: 4 months of development -> Beta1, + two months -> Beta 2 +fivemonths -> Release = 7 months QA (!)Longer development cycles are just not acceptable. If QA time is more than 1 month, there will be lot's of new code in the non-stable development branch, that will get bad quality, because everyone is concentrating in QA:ing the stable release. So after the release is done, then there will already be abad quality development release to work with.
I will let people more experienced in OpenOffice.org QA than I answer that.
I don't think I'm the only person who thinks three-month release cycles are too short. It's expecting too much, too soon.
.... Frequent time-based releases are good: you know when there will be a release. You can plan your work according to that.When you plan, don't do: "I want to get all my features to next release"You should do: "Well, there's release X in 3 months, Y release in 6 months and release Z in 9 months. If I work on this issue C for two months, I canget it to release X. The issues A and B take more time, so I'll target release Z for them."
Breaking the code work into briefer schedules is one thing. Breaking the QA work up is quite another. From my own experience, I can tell you that it can take just as long to QA a minor change, or some small changes, as it can to QA a major change, or a lot of changes. QA is a process you have to complete, regardless of the depth or complexity of change.
...We cannot make the schedule fit everybody's needs. You have to adapt to theschedule.Clytie is a good example of a project (vi lang) that has just started - there's lot's of work and few people. It is understandable if only some releases are QA:d. Or that one does not do full QA until later time --->only release "Alpha"s or "Beta"s.On the other hand, there are languages that have already been working for along time and have bigger amounts of participants. For them it is muchsmaller task to fix a few added/modified translations and some other issues.It is not fair to make them wait half a year.
Let's collect situations from the different projects, then we will have a working sample.
Whether I have more resources or not, I don't see release as something I want to do this quickly. In projects where the Vietnamese translation is well-established, there is still a lot to do for release. I also think there's a danger, in release schedules as frequent as three months, that people will start to take QA more lightly.
I work in over 20 other open-source software projects. I don't think any of them release this often, certainly none of the larger ones.It is not the open source mentality to make "perfect" releases that contain "everything". The open source mentality is to release incrementally BETTER releases OFTEN. This is especially the situation when the codebase is big and complex and when there are lot's and lot's of people making changes.
....Make your own plans according to your own resources, but DO NOT FORCE yourschedule on every else.
I support others in their concern about the brevity of the release cycle. I think it is a valid concern.
I've seen this topic discussed on the releases list. What has been the outcome?
The others have their own schedules to worry about.It is not possible to make everybody's schedules fit together. It would justresult in the worst case: the lowest common denominator -http://joelonsoftware.com/items/2006/11/21.html, with the view from theother side:http://moishelettvin.blogspot.com/2006/11/windows-shutdown- crapfest.html
Still, we can find the most effective compromise. Let's do that.from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN
PGP.sig
Description: This is a digitally signed message part
