ant elder wrote:
On Tue, Apr 5, 2011 at 5:45 PM, Simon Nash <[email protected]> wrote:
Following on from the discussion in [1], I'd like to establish
whether or not the Tuscany developer community agrees that we
should have some minimum standards for a sample to be part of trunk
and be delivered in a released binary distribution.
If there's agreement that we should establish this principle and
have some minimum standards, I'll start another discussion thread
on what those minimum standards should be.
I am +1 that we should have some minimum standards for a sample to be
in trunk and to be released as part of the binary distribution.
Simon
[1]
http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%[email protected]%3E
I'm -1 Simon. That doesn't mean I think we should have rubbish
samples, i just think the time spent rehashing this again would be
better spent actually writing some samples and documentation. We've
just spent two months debating the finer points of how to do samples
and ended up with just 3 in trunk which not even everyone is
completely happy with. We do have a clearer understanding now of what
people think but now we need to just get on and do some.
The Apache process is clear - it takes three +1s to do a release - it
doesn't matter what rules happen to have been come up here in this
thread 6 months down the road if there is a release with a sample
that doesn't work but the release gets the votes then that is fine.
Tuscany is the hardest project I know of in Apache to do releases, and
i've seen a lot of Apache projects. The actual build process takes
ages and then we drag it out for ages before people will vote and seem
to make it obligatory to redo it several times over before people will
vote +1. Thats shooting ourselves in the foot IMHO and instead of
looking for more rules to make it even harder to get a release out it
would be better to look for ways to get people to be more willing to
promptly vote for releases. We'd get more releases much more often and
then whats the big deal if some new sample slips through with a bug if
it can be fixed in the next release which is only a short time away.
2.x has taken a long time and trunk had got a bit full up of samples
that had been broken with all the refactoring and changes, we've taken
all those out now and things are much more stable so if we're a little
be diligent when adding samples now things should remain in better
shape.
...ant
Actually it should be easier / quicker to do releases if the trunk
samples meet a reasonable quality standard and are kept working on
an ongoing basis. Also, having some criteria for which samples are
included in trunk would mean that we can release the trunk contents
at any time without needing to debate which samples should be in the
release and removing those that are unsuitable.
Simon
