Florian Moga wrote:
I'm +1 for having a set of standard requirements for the samples to be
promoted to trunk and released. That's why I started the samples
checklist wiki page in the first place.
However, I don't think we need another two month long thread in order to
determine which these standards should be. We already had this
discussion and we can just summarize it.
I've updated the samples wiki page by adding a "Checklist" section
which is my attempt to write down what's expected (at a minimum)
for samples that are in the trunk. There's some overlap between this
and the preceding text but I didn't feel comfortable attempting a
merge at this stage.
I've used the term "expected" rather than something like "mandatory
requirements" because (as Ant has pointed out) there isn't any
mechanism for policing or enforcing this.
I've made the checklist as short as I think it can be. This means
that it doesn't contain any details of how the samples are built
(maven, ant, base + extension, pom or jar dependency) or run (shell,
maven Tuscany plugin, ant, etc.) I think it would be worth discussing
how prescriptive we want to be about these aspects, and anything else
that people think should be added (or subtracted).
Comments?
Simon
As I mentioned before on the other thread, I'm fine with doing the
release only with getting-started/ samples. With that in mind, I would
say we shouldn't delay 2.0-Beta3 any more. It's a minor release anyway
and most importantly users need the runtime code released. So I'm +1 for
releasing 2.0-Beta3 now.
On Wed, Apr 6, 2011 at 12:34 AM, Simon Nash <[email protected]
<mailto:[email protected]>> wrote:
ant elder wrote:
On Tue, Apr 5, 2011 at 5:45 PM, Simon Nash <[email protected]
<mailto:[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
