On Nov 15, 2010, at 1:23 PM, Jack Krupansky wrote: > I didn't mean to imply that the wiki needs to be physically included in the > release zip/tar, just that snapshotting and versioning of the wiki should be > done, if feasible, so that a user who is on an older release can still see > the doc for that release. I am just thinking ahead for future releases. So, > 0.1 does not need this right now.
Right, and I'm saying that we can't include user generated content in a release unless we have explicitly asked for permission on it in the form of patches and then committed by a committer. Since we don't lock down our wiki, we can't do it. > > -- Jack Krupansky > > -----Original Message----- From: Grant Ingersoll > Sent: Monday, November 15, 2010 10:23 AM > To: connectors-dev@incubator.apache.org > Subject: Re: Release? > > > On Nov 10, 2010, at 1:22 AM, Jack Krupansky wrote: > >> And the wiki doc is also part of the release. Does this stuff get a >> version/release as well? Presumably we want doc for currently supported >> releases, and the doc can vary between releases. Can we easily snapshot the >> wiki? > > You can't put Wiki in a release, as their is no way to track whether the > person has permission to donate it.. > >> >> Will we have nightly builds in place? I think a 0.1 can get released without >> a nightly build, but it would be nice to say that we also have a "rolling >> trunk release" which is just the latest build off trunk and the latest >> wiki/doc as well. So, some people may want the official 0.1, but others may >> want to run straight from trunk/nightly build. >> >> -- Jack Krupansky >> >> -----Original Message----- From: Karl Wright >> Sent: Tuesday, November 09, 2010 1:56 PM >> To: connectors-dev@incubator.apache.org >> Subject: Re: Release? >> >> 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 >>>>> >>>> >>>> >>> >> > > -------------------------- > Grant Ingersoll > http://www.lucidimagination.com -------------------------- Grant Ingersoll http://www.lucidimagination.com
