Elizabeth Keogh wrote:
I'd rather have a few badly-needed features, done well, than a bloat of
partly-done features, some of which will never be used. With respect to
Mauro, the code generator is an example. I can't use it in its current
form on any project, even toy ones like the Game of Life. I don't
believe that it should have been checked in to the stable download
(distributed SCM would help solve this problem, and I do have faith in
Mauro's ability to finish the feature. It may not be needed in JBehave
2.0.)
Firstly, it is not included in any stable download. It's a new feature
in trunk and has not been released yet.
While I had not implemented initially the Ant task (but the Ant/Maven
plugins are simply a thin wrapper around the core Java), the Maven
plugin functionality did have from the start integration tests -
possibly not covering all the use cases, but if these need to be voiced
and expressed.
I cannot agree with your view that the code should not have been checked
in. Development is an increment process and if you come up with a use
case that is not satisfied it is welcomed. Commit early and often on
the dev trunk has always been best practice in OS.
Of course, it may well be distributed SCM will change the dev paradigm
to a complete feature one, but as good as the merging algorithms may be
(still to be proven first hand, though) I don't believe that delaying
too much the merging (ie after the feature is "complete") is a good
practice. The golden rule has always been that the build is not broken.
I have great respect for my own time, and yours. I believe that breaking
the build and expecting other people to fix it, or introducing features
without showing why they're needed and how they work, is disrespectful
and contrary to the community spirit. It's stopped me from contributing
as much as I'd have liked to in the past. Having the right to revert a
revision or veto a change will allow us to work around each other more
easily. It doesn't mean we _have_ to revert the build, and it doesn't
mean we can't play with changes and make suggestions. It _will_ make us
all think before we check in.
Sorry - which build has been broken?
I have so much respect for my own time because I remember how much I
spent of it on JBehave 1.x - yet it seems that JBehave 1.x doesn't solve
the problems. I'd like to change the way we work so that JBehave 2.0 does.
I have spent some time looking at the take-up of various projects, and
noted my own frustrations when trying to use new features in other
open-source frameworks. The best frameworks - and the ones which get
used - are not even necessarily the ones which solve the problems best.
They're the ones which allow _users_ to solve the problems best. Our
lack of decent documentation hasn't helped JBehave's case. HowTos and
explanative models make a difference, and will also save the dev team time.
We may be a small team, but we've generated a huge amount of code. Let's
generate the _right_ code this time.
This is my sledgehammer. There are many like it, but this one is mine.
So, what are you saying? That if it doesn't have a toy application (but
has unit and integration tests) it is not worthy of being checked in?
Because that's the impression I got from your original message.
Mind you - I'm in totally in favour of integration tests that satisfy
given use cases, which should drive the development. If you prefer toy
apps, then fine - but please don't mandate it.
If you are willing to discuss and agree a LCD approach, I'd be happy to
sit down and talk about it. If not, then I can't see much space for a
collaboration on jBehave 2.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
