Florian MOGA wrote:
I've just checked out "mvn ant:ant" and seems to do a decent job in
generating an ant build file.
Figuring out what should samples look like imply taking other decisions
first (how will documentation look like, what type of launcher is
required, ...). So, for now I'd suggest to temporarily move the samples
that don't work at all and require a reasonable amount of resources to
fix (most of them are trivial fixes so there will be a fairly small
number that will get moved). IMO that should be enough to ship the
release. After that we might need to first agree on the other topics in
order to have a knowledgeable context for this discussion.
+1 for this approach. See my comments below for what I think it means
for a sample to "work".
On Sun, Feb 6, 2011 at 1:48 PM, ant elder <ant.el...@gmail.com
<mailto:ant.el...@gmail.com>> wrote:
On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <n...@apache.org
<mailto:n...@apache.org>> wrote:
> Florian MOGA wrote:
>>
>> Current naming with beta isn't that flexible. We could continue
doing a
>> lot of betaX releases or start naming betaX.X. I'm fine with
both of them.
>> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
2.1.1, ....,
>> 2.2 and things will get more obvious.
>>
>> Regarding samples, we can either move them to unreleased/ and
move them
>> back as they get fixed or we can just open a ticket with
subtasks for each
>> sample to keep track of them. I assume we're now doing a 'minor'
release so
>> doesn't really matter at the moment.
>>
> IMO it would be better to only include samples that work. It's
> frustrating and confusing for users when they attempt to run a sample
> that's included in a release and find that it doesn't work.
>
> Are there a few samples that could be got working quite easily?
> If so, I think it would be good to include those few in this release
> and move the rest to unreleased/ until the next major release.
> If the release includes working samples (even a few) then we could
> regard it as a "major" release.
>
> Simon
>
That sounds reasonable but what does "work" mean? Up till now we've
had no minimum standard so anyone can add anything to samples/ and it
gets included in a release. I'd probably in favour of tightening that
up a bit now but I wonder if we'd agree on a minimum set of
requirements.
We have samples with no Ant build, no doc, no obvious way of running
them, and not even a sentence in a README saying what the purpose of
the sample is, but some of them do still "work" if you happen to know
what to do with it. Must there be proper tests so we know if the
sample gets broken? What if someone doesn't particularly care about
Ant builds so doesn't write a build.xml, is that sample excluded or is
a release held up till someone else write the build file?
...ant
From a user perspective, I think at a minimum:
1) There must be instructions saying how to build and run the sample and
what the sample should do if it runs successfully.
2) The sample must build and run successfully if the user follows the
instructions provided.
The other things you mentioned are desirable but not essential:
3) an ant script for building and/or running the sample
4) automated tests for ensuring that the sample works
When someone is creating a new sample that doesn't yet meet the minimum
release requirements, I think it should go in unreleased/ initially and
be moved to the main trunk when it meets the release requirements.
Simon
