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
