It looks like in the end there's been a misunderstanding about the process.
Personally, I would like to have a "review first" approach as it helps
improving the code quality over time but that doesn't seem to work for us so
it's ok to move forward with the previous approach. Glad we're all speaking
the same language now.

Regarding the consistency of the samples, I consider this a very important
aspect which we should maintain as it helps a lot new users. Especially the
way the samples are launched. I'm saying this from my own experience with
Tuscany last year when I had a hard time understanding concepts partly
because I wasn't able to start the samples. I believe that a user starting
to look at Tuscany is much more concerned to understand components,
services, references, scdl rather than deployment environments in the early
stage. For that kind of experiments, we have the running-tuscany/ category
which is excellent for that. This is the reasoning behind me supporting the
shell all the time. It provides an easy to use, build tool agnostic way of
starting the samples and even more, gives the user the ability to interact
with components. I find this a suitable way of presenting the samples to the
users. Let me know if you feel different.

Florian


On Mon, Apr 4, 2011 at 7:12 PM, Raymond Feng <enjoyj...@gmail.com> wrote:

> I like the "commit then review" approach much better. When we add samples
> into trunk, we have the responsibility to keep them working (in the right
> way).
>
> Thanks,
> Raymond
>  *________________________________________________________________
>  Raymond Feng
> rf...@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________*
>
> On Apr 4, 2011, at 9:04 AM, Simon Nash wrote:
>
> ant elder wrote:
>
> On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <n...@apache.org> wrote:
>
> Also in [1], I said that a new sample that doesn't yet meet the mandatory
>
> release requirements should go in unreleased/ initially.  AFAICT, the store
>
> sample does meet the mandatory release requirements, so I'm not sure why
>
> it was moved to unreleased/.
>
>
> Because without asking first there is no way of know if there is
>
> consensus with everyone to include something in trunk. I give up on
>
> this new approach to the samples, it is sucking away way to much time.
>
> Please from now on lets go back to trunk/samples working just the same
>
> as any other part of tuscany svn.
>
>   ...ant
>
> I think the process should work the other way round, i.e., that if
> a sample is committed to trunk and it doesn't meet the mandatory
> requirements (which we can discuss and hopefully agree), then it should
> be moved to unreleased/ until it does meet the mandatory requirements.
> Is this a workable approach?
>
>  Simon
>
>
>

Reply via email to