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,
Re: Release?
On Nov 9, 2010, at 1:56 PM, Karl Wright wrote: 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? I think so. This first release is about getting something out there that people can dig into a bit. It also is about laying the legal groundwork (NOTICE.txt, licenses, etc.) to show that we know how to do releases. -Grant
Re: Release?
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. -- 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
