Feeling somewhat challenged by the other Thorsten’s comments that “some groups in the community say, these [processes] hinder the contribution to the project”, I cannot but present a slightly different view on that topic.
OOo was using child workspaces already for 2.0, so this is not a discriminating factor, and neither is valgrind (which was also in use before – and on top of that, focused fixing of valgrind issues resulted in a total of 35 issues fixed, versus 41 issues still open).
Leaves warning free code and crash reports – the former is all about defect prevention (from personal experience, actually making the code warning free did result in fixing a few serious bugs, but most of them were minor issues – the benefits come afterwards). The latter is about fixing issues after OOo has been released to the general public, and is indeed a great tool – but it does not explain why the numbers of new issues has been kept consistently lower than for 2.0 (if that’s not obvious: something must have changed before releasing the code).
So, my explanation for the significant differences between 2.0 and 3.0 would be
- introduction of some defect prevention measures
- but most importantly: taking the pressure off of the hackers to finish features at a certain point in time
This was achieved via a so-called train model, having frequent feature releases instead of 24-month big-bang style development. Needless to say that this style is standard for almost every opensource development. And coming back to the opening paragraph, I do believe that certain processes in place at vanilla OOo hinder community contributions – I’m talking about code contribution here, and I see a significant difference between contributions of part-time hackers to ooo-build, in comparison to vanilla OOo. The question is, what’s the focus of the project (community? the product?) – and, which of those processes have significant influence on quality and which don’t (and which can be replaced by other, similarly effective measures, that are more hacker-friendly).
Thorsten's Weblog 
2 Comments
Hi Thorsten,
you are right in some points. CWSs were introduced before 2.0 was released. But in the handling with finalizing a Feature/Enhancement in a CWS by an iTeam changed and were enforced after 2.0. Another good point is, that the train-modell were introduced. I forgot this. The result of more frequent feature releases is, that the feature set for OOo does not increased by a OOo 3.0 release so dramatically. It increased every release. This is different to other products in the world.
You asked the question, what is the focus of the project. I cannot give you the correct answer. I know, that the QA project of OOo and I want to have high quality. Unfinished features or not working functionality isn’t high voted in this team. When you are writing about ‘hackers’, I will get the impression that this can be increased, when more ‘hackers’ will work on vanilla OOo. But perhaps I interpret ‘hackers’ too dramatically :-).
Thorsten
Thorsten, right – the enforcement changed after 2.0. The rules have been there before. And the reason for reduced pressure to break the rules was – train model.
Regarding the exceptionality of this process – I beg to differ, this is the norm in the FLOSS world, not the exception. And I believe that no QA person should be afraid of the kind of hacker I was referring to: http://en.wikipedia.org/wiki/Hacker#Open_Source_and_Free_Software_hackers 🙂