ant elder wrote:
On Tue, Apr 5, 2011 at 10:20 AM, Simon Nash <n...@apache.org> wrote:
Luciano Resende wrote:
On Mon, Apr 4, 2011 at 9:12 AM, 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).
+1, And this might really be the reason for having this whole
discussion. In Tuscany, usually people would dump samples into samples
and only look into them when during the release time. Having a reduced
number of samples will help, but sample ownership might be the main
issue here.
I agree that sample code shouldn't be dumped into trunk with the expectation
that someone will get it into proper shape for the next release.
Regarding ownership, this word might be interpreted in different ways by
different people. If it means that someone who commits a new sample should
do the whole job of making sure that it meets all the requirements for
samples in trunk, I'm +1 for this. Another interpretation of ownership
could
be to regard a particular individual as responsible for maintaining
particular
samples (or other parts of the codebase) on an ongoing basis. In Tuscany we
don't have this kind of personal ownership but instead regard the whole
community as responsible, and I wouldn't want to see that change.
For non-sample code that's added to trunk, I think we have general agreement
that the new code needs to build OK, have unit tests, and pass its unit
tests.
For sample code that's added to trunk, all the above apply and there are
additional requirements that the sample includes documentation describing
what it does, how to run it, and the expected results from running it.
It's also a requirement that the sample runs correctly and does what the
documentation says it will do.
Simon
What we know from recent and past events is that there isn't really
that much agreement on many things and that people may get upset if
things are taken out of trunk. If you read back in the sample thread
even something like the requirement to have a sample readme doesn't
have universal support, and, if a readme is so banal that it doesn't
add much over what you already get from the sample name then the
existence of one doesn't really make the world that much of a better
place. I think one of the most important things we can do is try to
keep each other happy. We've a relatively small dev community so we
should do what we can to keep everyone involved and productive and
find ways to make space for everyone to do what we they think is
important or useful.
...ant
Yes, keeping each other happy is definitely a good thing. However,
let's not forget that we have users who will definitely not be happy
if we deliver releases with samples that don't work or have no
instructions for running them or have instructions that are wrong.
Also, certain members of our own community will not be happy if we
deliver releases that cause our users to be unhappy.
I'll start a separate discussion thread on whether our community
agrees with the principle of establishing some minimum standards
for the samples in trunk that we deliver in our released binary
disitributions. If there's agreement on that, I'll start a discussion
on what those mimimum standards should be.
Simon
