On Sat, Feb 5, 2011 at 11:58 AM, ant elder <ant.el...@gmail.com> wrote:
> > Great stuff Florian, thanks for doing that work. > > Some of those I know are relatively easy to fix and its just a matter > of getting around to it. That's right, some of them are trivial, but some are pretty nasty... I'd consider moving samples like helloworld-js-client-webapp to the unreleased folder. > I'll try to find some time on it over the > next days. Some of those don't have unit or integration tests run in > the build is why they got broken but quite a lot of them do but the > tests just aren't testing enough or properly. > Talking about unit tests, I've noticed quite a lot of tests marked as skipped in the maven log... This worries me and I think we should definitely revisit them in the next releases. I'm starting to wonder if we should find a new sample approach. An > issue is presently anyone can add a sample which may or may not have > doc or tests or work in a standard or unusual way and it gets included > in the releases and then adds to perceived quality seen by users and > release reviewers. Because of that what we often do is delay releasing > until "most" of the samples have been brought up to a reasonable > consistent standard but thats not perfect as it slows down releases > and theres still usually some samples that don't work normally and > without doc which users to find a get confused about. As I've already mentioned on another thread, I think a code review tool would help a lot achieving more quality in our project. I'd go for no major commits without code review but that might not fit everyones taste. It actually isn't that painful as it sounds. A good percent of the bugs are found, knowledge is transferred, more filtering / brushing up until something actually gets in trunk. It might all determine us to write more quality code, add tests, doc. I'm also thinking that as we're heading to alpha releases, we need to 'freeze' the runtime code and do more maintenance releases (samples, unit tests, documentation). It might not be as fun as doing development in the runtime code but I'm afraid it is the only way to have a quality 2.0 out. Last time I heard, we had good oasis compliance, so I think we can afford doing this. With that in mind, I'd like to propose for the upcoming releases to start spinning a new release right after we're done with another one. > One thing we could try is releasing the samples separately from the > main code, a lot of other projects do that, and our SDO releases had > the samples separate. That would mean we could do much more frequent > releases of the runtime code as releases wouldn't get held up with > sample quality issues. Is any one for or against trying something like > that? > I think keeping samples together with the runtime code is a good thing because it forces us to maintain samples as well :) If we split samples from code, I think we're going to run into version mismatch problems and it will be much harder and more painful to do sample releases than it is now. I'm calling -0 at the moment, I'd like to see other opinions as well. > ...ant >
