Just to be clear, I'm totally +1 for doing major and minor releases. My comment above was related to Simon's concern about how many samples are actually working and isn't contrary to the major/minor approach. Fixing the trivial ones shouldn't require more than a few days. Is it ok to spin RC3 on Wednesday if no other build issues occur? I'm planning to spend the next 2 days on fixing as many samples as possible. Would it also be possible for you guys to be present on IRC the next days if I'm reaching a dead end at some point? Thanks.
On Sun, Feb 6, 2011 at 8:07 PM, ant elder <ant.el...@gmail.com> 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. > > 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 >
