Proposal: Release to consist of two things: tar and zip of a complete source tree, and tar and zip of the modules/dist area after the build. The implied way people are to work with this is:
- to use just the distribution, untar or unzip the distribution zip/tar into a work area, and either use the multiprocess version, or the quickstart example. - to add a connector, untar or unzip the source zip/tar into a work area, and integrate your connector into the build. Is this acceptable for a 0.1 release? Karl On Tue, Nov 9, 2010 at 10:22 AM, Jack Krupansky <jack.krupan...@lucidimagination.com> wrote: > Oh, I wasn't intending to disparage the RSS or other connectors, just giving > my own priority list of "must haves." By all means, the "well-supported" > connector list should be whatever list you want to feel is appropriate and > exclude only those where "we" feel that "we" would not be able to provide > sufficient support and assistance online. > > That's great that qBase is offering access. > > BTW, I was just thinking that maybe we should try to keep logs of each > connector type in action so that people have a reference to consult when > debugging their own connector-related problems. In other words, what a > successful connection session is supposed to look like. So, have a test and > its "reference" log. > > -- Jack Krupansky > > -----Original Message----- From: Karl Wright > Sent: Tuesday, November 09, 2010 9:46 AM > To: connectors-dev@incubator.apache.org > Subject: Re: Release? > > If you can claim "well supported" for the web connector, you certainly > should be able to claim it for the RSS connector. You could also > reasonably include the JDBC connector because it does not require a > proprietary system to test. > > But if your definition is that tests exist for all the "well > supported" ones, somebody has some work to do. I'd like to see a plan > on how we get from where we are now to a more comprehensive set of > tests. I've gotten qBase to agree to let me have access to their Q/A > infrastructure (which used to be MetaCarta's), but that's only going > to be helpful for diagnosing problems and doing development, not for > automated tests that anyone can run. > > Karl > > On Tue, Nov 9, 2010 at 9:38 AM, Jack Krupansky > <jack.krupan...@lucidimagination.com> wrote: >> >> And one of the issues on the list should be to define the "well-supported" >> connectors for 0.5 (or whatever) as opposed to the "code is there and >> thought to work, you are on your own for testing/support" connectors. >> Longer >> term, "we" should get most/all connectors into the well-supported >> category, >> but I wouldn't use that as the bar for even 1.0. >> >> My personal minimum "well-supported" connector list for a 0.5 would be >> file >> system, web, and SharePoint*. >> >> * Oh... there is the issue of SharePoint 2010 or whatever the latest is, >> but >> current MCF support should be good enough for a 0.5 release, I think. >> >> (Got to keep up with Google Connectors!) >> >> -- Jack Krupansky >> >> -----Original Message----- From: Karl Wright >> Sent: Tuesday, November 09, 2010 9:28 AM >> To: connectors-dev@incubator.apache.org >> Subject: Re: Release? >> >> I'm in favor of a release. I'm not sure, though, what the release >> parameters ought to be. I think the minimum is that we need to build >> a release infrastructure and plan, set up a release process, and >> decide what the release packaging should look like (zip's, tar's, >> sources, deliverables) and where the javadoc will be published online. >> (It's possible that we may, for instance, decide to change the way >> the ant build scripts work to make it easier for people to build the >> proprietary connectors after the fact, for instance. Or we could >> claim that the release is just the sources, either way.) >> >> After that, we need to figure out what tickets we still want done >> before the release occurs. I'd argue for more testing, and I'm also >> trying to figure out issues pertaining to Documentum and FileNet, >> because these connectors require sidecar processes that are not well >> supported in the example. We could go substantially beyond that, but >> I agree with Jack that 0.1 would be useful if we only get that far. >> >> Thoughts? >> Karl >> >> >> >> On Tue, Nov 9, 2010 at 8:58 AM, Jack Krupansky >> <jack.krupan...@lucidimagination.com> wrote: >>> >>> At least get a release 0.1 dry-run with code as-is out ASAP to flush out >>> release process issues. This would help to send out a message to the rest >>> of >>> the world that MCF is an available product rather than purely >>> development/incubation. >>> >>> Then come up with a list of issues that people strongly feel need to be >>> resolved before a true, squeaky-clean 1.0 release. Maybe that is the >>> original list of tasks, including better testing, but some >>> review/decisions >>> are probably needed. That will be the ultimate target. >>> >>> Then decide on a "close enough" subset of issues that would constitute >>> what >>> people consider a "solid beta" and target that as a release 0.5 and focus >>> on >>> that as the near-term target (after getting 0.1 out ASAP.) I personally >>> do >>> not have any major issues on the top of my head that I would hold out as >>> "blockers" for a 0.5. >>> >>> Or, get 0.1 out and then move on to a 0.2, etc. on a monthly/bi-monthly >>> basis as progress is made. >>> >>> In short, get MCF as-is 0.1 out ASAP, have a very short list for MCF 0.5 >>> to >>> get it out reasonably soon, and then revisit what 1.0 really means versus >>> 0.6, etc. >>> >>> -- Jack Krupansky >>> >>> -----Original Message----- From: Grant Ingersoll >>> Sent: Tuesday, November 09, 2010 8:38 AM >>> To: connectors-dev@incubator.apache.org >>> Subject: Release? >>> >>> Now that we have NTLM figured out and the Memex stuff behind us, how do >>> people feel about working towards a release? >>> >>> -Grant >>> >> >> > >
