Thanks for reviewing the checklist. See comments inline below.
Simon
Florian Moga wrote:
The checklist is looking good until now. I think that if we want to
enforce a consistent feel over the samples we should agree on build
tool, dependencies and launcher before considering the checklist final.
I would say let's stick with Maven for now, Apache Ant adds complexity
and requires time to find an elegant way of writing a script which we
don't afford now.
I think we also need to show people how to build samples using the
binary distribution without needing to download additional modules.
This is the reason why we have previously provided ant scripts for
building the samples. I don't think it's necessary for every sample
to have an ant script, but at least some of them should have one.
As for how dependencies are declared, you've got much more experience
with Tuscany to weight the pros and cons for each approach but I think
we should use the one we consider best practice and present that to the
user. For me base+extensions seems to be the way to go as it looks more
loosely coupled and there's been the big effort of adding that in Beta1.
Regarding the launcher, I have already expressed my opinion a couple of
times but haven't seen any comments so I guess we're fine with the shell?
This is probably OK for developers but it isn't suitable for deploying
or embedding Tuscany. I think it's important that we include ant scripts
for running some of the samples so that people know how to run Tuscany in
a production or embedded environment.
Simon
Florian
On Wed, Apr 6, 2011 at 6:32 PM, Simon Nash <[email protected]
<mailto:[email protected]>> wrote:
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]> <mailto:[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]>
<mailto:[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
