I'm uploading a release candidate now. But someone needs to feed the hamsters turning the wheels or something, because the upload speed to that machine is 51KB/sec, so it's going to take 3 hours to get the candidate up there, if my network connection doesn't bounce in the interim. Is there any other place available?
Karl On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Nov 19, 2010, at 6:18 AM, Karl Wright wrote: > >> I've created a signing key, and checked in a KEYS file. Apache >> instructions for this are actually decent, so I didn't have to make >> much stuff up. Glad about that. >> > > Yep, sorry, have been in meetings. > >> Last remaining release issue is getting the release files to a >> download mirror. Maybe I can find some doc for that too. > > > Next steps would be to generate a candidate release which the rest of us can > download. Put it up on people.apache.org/~YOURUSERNAME/... and then send a > note to the list saying where to locate it. Rather than call a vote right > away, just ask us to check it out and try it as there will likely be issues > for the first release. Once we all feel we have a decent candidate, we can > call a vote, which should be a formality. > > See http://apache.org/dev/#releases for more info. > > > >> >> Karl >> >> On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright <daddy...@gmail.com> wrote: >>> The build changes are complete. I removed the modules level from the >>> hierarchy because it served no useful purpose and complicated matters. >>> The outer level build.xml now allows you build code, docs, and run >>> tests separately from one another, and gives you help as a default. >>> "ant image" builds you the deliverable .zip and tar.gz files. Online >>> site has been polished so that it now contains complete javadoc, as >>> does the built and delivered .zip and tar.gz's. In short, we *could* >>> actually do a release now, if only we had (and incorporated) the KEYS >>> file I alluded to earlier, which I do not know how to build or obtain. >>> I believe this needs to be both generated and registered. The site >>> also needs to refer to a download location/list of mirrors before it >>> could go out the door. >>> >>> Help? Grant? >>> >>> 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 >>>>>> >>>>>> >>>>> >>>> >>> > > -------------------------- > Grant Ingersoll > http://www.lucidimagination.com > >
