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
