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. 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 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
