ant elder wrote:
On Sun, Feb 6, 2011 at 2:44 PM, Simon Nash <n...@apache.org> wrote:
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
An issue with that approach is that it will make getting releases out
harder as there's a good chance some sample will have some problem and
someone will insist on a respin to fix it.
Once a sample is working, it should continue to work. If it stops working
then this presumably indicates a runtime problem, which should raise a
concern about whether the runtime code is in good enough shape to release.
I think we need to find ways to make doing release easier so that we
do them more often. We have most things automated now like legal
stuff, header checking, and simplified NOTICE file which has helped a
lot, but this new approach is going back to needing to spend ages
manually reviewing and running all samples and opening things up for
people to ask for more RC respins.
I don't understand why this approach would make releases harder to do.
If we eliminate the samples that aren't working, and avoid adding any
new samples in minor releases, this should reduce the time needed to
verify that the included samples are working.
I do agree good quality samples are important for users though. Maybe
if we have this more strict quality approach then we also need to do
some vetting of what goes into samples so there isn't so many of them
and try to include just a few main ones in the releases, perhaps with
others available in SVN which we document as available?
...ant
That's exactly what I was suggesting. Quality is more important than
quantity. Let's be selective and only include samples in a release if
they are working and have some documentation saying how to run them.
For those that make the cut, I think there is a requirement to keep
them working in future releases (both major and minor), so let's make
the selection with that in mind.
Simon
