It looks like one delivery model is a combined source/release tar.gz and zip. That's what Forrest and Solr seem to do. It has the advantage of being very simple and including everything. Disadvantage is that there's a lot to download if all you want to do is run it, but I think we can live with that.
So all that this is is a zip or tar.gz of the pertinent chunks of the release branch, after a build has been completed. Exclusions should be any temporary build areas or test areas or junk like that, but pretty much everything else goes. If anyone has any objection to using this as a delivery strategy, please let me know. It also looks like we're going to need keys to sign our jar files. Grant, where should we get these? Karl On Wed, Nov 17, 2010 at 9:50 PM, Karl Wright <daddy...@gmail.com> wrote: > Hearing nothing, went ahead and made the port of documentation to the > site official. I also now include the generated site in the release > tar.gz and .zip. > Issues still to address before release: > > (1) source tar.gz and zip in outer-level build.xml, which I will try > to address shortly. > (2) vehicle for release downloads, and naming thereof. In short, > where do I put these things so people can download them?? > (3) Voting procedures for release. I've seen this done as a vote in > gene...@incubator.org - is that actually necessary? > (4) Release branch and tag. Do we want both? What is the correct > naming for each in apache? > (5) Legal requirements. CHANGES.txt, LICENSE.txt, etc. Do these need > to be included in the release tar.gz, or just the source tar.gz? I > suspect both, but please confirm. Also, if there is a typical > organization of the release tar.gz in relation to the source tar.gz > this would be a good time to make that known. > > Thanks, > Karl > > On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright <daddy...@gmail.com> wrote: >> What I've done here is taken all the pages that I originally put in >> the Wiki, describing how to set up and run ManifoldCF, and converted >> them to xdocs that are part of the ManifoldCF site. These documents >> have no user content other than stuff Grant or I added, according to >> their logs, so I feel that is safe to do. I've left the wiki pages >> around but am thinking we'll want them to go away at some point. Not >> sure exactly what to do with all the user comments to them, however. >> >> Is this a reasonable way to proceed? We should avoid using the wiki >> in the future for documentation, seems to me, but otherwise I can see >> no issues here. >> >> Karl >> >> On Tue, Nov 16, 2010 at 5:36 PM, Grant Ingersoll <gsing...@apache.org> wrote: >>> >>> 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 >>> >>> >> >
