You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Grant Ingersoll <gs...@apache.org> on 2010/11/09 14:38:02 UTC
Release?
Now that we have NTLM figured out and the Memex stuff behind us, how do people feel about working towards a release?
-Grant
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I will at least need:
(a) Grant to look at it, to make sure the legal niceties are taken care of, and
(b) Help in getting the images and signature files up to the mirrors
I'll call the vote after (a) is done.
Karl
On Wed, Dec 1, 2010 at 12:02 PM, Jack Krupansky
<ja...@lucidimagination.com> wrote:
> +1
>
> Unfortunately I am maxed out until at least Friday, so there has been no
> chance for me to get to look at it. That said, I won't hold it up. Besides,
> 0.1 is mostly testing the process anyway, so we can fix issues in 0.2 as
> well. So, I say go for it, unless somebody really objects.
>
> -- Jack Krupansky
>
> -----Original Message----- From: Karl Wright
> Sent: Wednesday, December 01, 2010 11:47 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Release?
>
> Should I just call the vote? It's been a week...
> Karl
>
> On Mon, Nov 29, 2010 at 1:18 PM, Karl Wright <da...@gmail.com> wrote:
>>
>> Great!
>> Has anyone else had a chance to look at RC1 yet? If not, should I
>> offer gift certificates or something to encourage participation? ;-)
>>
>> Karl
>>
>>
>> On Sat, Nov 27, 2010 at 7:52 AM, Grant Ingersoll <gs...@apache.org>
>> wrote:
>>>
>>> I'll take a look, but it won't likely be until Tuesday (extended Turkey
>>> going on here!)
>>>
>>> On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:
>>>
>>>> Uploaded RC1.
>>>> Karl
>>>>
>>>> On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>
>>>>> A problem with the FileNet connector has caused me to build an RC1.
>>>>> It's uploading now.
>>>>>
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
>>>>> <ja...@lucidimagination.com> wrote:
>>>>>>
>>>>>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of
>>>>>> the
>>>>>> hardest of the work.
>>>>>>
>>>>>> I'm busy on some other things right now, but maybe next week I can
>>>>>> take a
>>>>>> look.
>>>>>>
>>>>>> -- Jack Krupansky
>>>>>>
>>>>>> -----Original Message----- From: Karl Wright
>>>>>> Sent: Tuesday, November 23, 2010 1:00 PM
>>>>>> To: connectors-dev@incubator.apache.org
>>>>>> Subject: Re: Release?
>>>>>>
>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>
>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>
>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>>>>>> manifoldcf-0.1.tar.gz.md5
>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>>>>>> manifoldcf-0.1.zip.md5
>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55
>>>>>> manifoldcf-0.1.zip
>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06
>>>>>> manifoldcf-0.1.tar.gz
>>>>>> [kwright@minotaur:~]$
>>>>>>
>>>>>> Please let me know what you think.
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>> another way.
>>>>>>> Karl
>>>>>>>
>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>> general@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
>>>>>>>>>>>> <da...@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
>>>>>>>>>>>>> <gs...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com/
>>>
>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>> http://www.lucidimagination.com/search
>>>
>>>
>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
+1
Unfortunately I am maxed out until at least Friday, so there has been no
chance for me to get to look at it. That said, I won't hold it up. Besides,
0.1 is mostly testing the process anyway, so we can fix issues in 0.2 as
well. So, I say go for it, unless somebody really objects.
-- Jack Krupansky
-----Original Message-----
From: Karl Wright
Sent: Wednesday, December 01, 2010 11:47 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?
Should I just call the vote? It's been a week...
Karl
On Mon, Nov 29, 2010 at 1:18 PM, Karl Wright <da...@gmail.com> wrote:
> Great!
> Has anyone else had a chance to look at RC1 yet? If not, should I
> offer gift certificates or something to encourage participation? ;-)
>
> Karl
>
>
> On Sat, Nov 27, 2010 at 7:52 AM, Grant Ingersoll <gs...@apache.org>
> wrote:
>> I'll take a look, but it won't likely be until Tuesday (extended Turkey
>> going on here!)
>>
>> On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:
>>
>>> Uploaded RC1.
>>> Karl
>>>
>>> On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
>>>> A problem with the FileNet connector has caused me to build an RC1.
>>>> It's uploading now.
>>>>
>>>> Karl
>>>>
>>>> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
>>>> <ja...@lucidimagination.com> wrote:
>>>>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of
>>>>> the
>>>>> hardest of the work.
>>>>>
>>>>> I'm busy on some other things right now, but maybe next week I can
>>>>> take a
>>>>> look.
>>>>>
>>>>> -- Jack Krupansky
>>>>>
>>>>> -----Original Message----- From: Karl Wright
>>>>> Sent: Tuesday, November 23, 2010 1:00 PM
>>>>> To: connectors-dev@incubator.apache.org
>>>>> Subject: Re: Release?
>>>>>
>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>
>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>
>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>>>>> manifoldcf-0.1.tar.gz.md5
>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>>>>> manifoldcf-0.1.zip.md5
>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55
>>>>> manifoldcf-0.1.zip
>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06
>>>>> manifoldcf-0.1.tar.gz
>>>>> [kwright@minotaur:~]$
>>>>>
>>>>> Please let me know what you think.
>>>>> Karl
>>>>>
>>>>>
>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>> another way.
>>>>>> Karl
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>> <gs...@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 <da...@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 <da...@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
>>>>>>>>>>> general@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
>>>>>>>>>>> <da...@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
>>>>>>>>>>>> <gs...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem docs using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Should I just call the vote? It's been a week...
Karl
On Mon, Nov 29, 2010 at 1:18 PM, Karl Wright <da...@gmail.com> wrote:
> Great!
> Has anyone else had a chance to look at RC1 yet? If not, should I
> offer gift certificates or something to encourage participation? ;-)
>
> Karl
>
>
> On Sat, Nov 27, 2010 at 7:52 AM, Grant Ingersoll <gs...@apache.org> wrote:
>> I'll take a look, but it won't likely be until Tuesday (extended Turkey going on here!)
>>
>> On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:
>>
>>> Uploaded RC1.
>>> Karl
>>>
>>> On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
>>>> A problem with the FileNet connector has caused me to build an RC1.
>>>> It's uploading now.
>>>>
>>>> Karl
>>>>
>>>> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
>>>> <ja...@lucidimagination.com> wrote:
>>>>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
>>>>> hardest of the work.
>>>>>
>>>>> I'm busy on some other things right now, but maybe next week I can take a
>>>>> look.
>>>>>
>>>>> -- Jack Krupansky
>>>>>
>>>>> -----Original Message----- From: Karl Wright
>>>>> Sent: Tuesday, November 23, 2010 1:00 PM
>>>>> To: connectors-dev@incubator.apache.org
>>>>> Subject: Re: Release?
>>>>>
>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>
>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>
>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>>>>> manifoldcf-0.1.tar.gz.md5
>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>>>>> manifoldcf-0.1.zip.md5
>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>> [kwright@minotaur:~]$
>>>>>
>>>>> Please let me know what you think.
>>>>> Karl
>>>>>
>>>>>
>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>> another way.
>>>>>> Karl
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>
>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>> general@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 <da...@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
>>>>>>>>>>>> <gs...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem docs using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Great!
Has anyone else had a chance to look at RC1 yet? If not, should I
offer gift certificates or something to encourage participation? ;-)
Karl
On Sat, Nov 27, 2010 at 7:52 AM, Grant Ingersoll <gs...@apache.org> wrote:
> I'll take a look, but it won't likely be until Tuesday (extended Turkey going on here!)
>
> On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:
>
>> Uploaded RC1.
>> Karl
>>
>> On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
>>> A problem with the FileNet connector has caused me to build an RC1.
>>> It's uploading now.
>>>
>>> Karl
>>>
>>> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
>>> <ja...@lucidimagination.com> wrote:
>>>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
>>>> hardest of the work.
>>>>
>>>> I'm busy on some other things right now, but maybe next week I can take a
>>>> look.
>>>>
>>>> -- Jack Krupansky
>>>>
>>>> -----Original Message----- From: Karl Wright
>>>> Sent: Tuesday, November 23, 2010 1:00 PM
>>>> To: connectors-dev@incubator.apache.org
>>>> Subject: Re: Release?
>>>>
>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>
>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>
>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>>>> manifoldcf-0.1.tar.gz.md5
>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>>>> manifoldcf-0.1.zip.md5
>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>> [kwright@minotaur:~]$
>>>>
>>>> Please let me know what you think.
>>>> Karl
>>>>
>>>>
>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>
>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>> another way.
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>
>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>> general@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 <da...@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
>>>>>>>>>>> <gs...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem docs using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
I'll take a look, but it won't likely be until Tuesday (extended Turkey going on here!)
On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:
> Uploaded RC1.
> Karl
>
> On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
>> A problem with the FileNet connector has caused me to build an RC1.
>> It's uploading now.
>>
>> Karl
>>
>> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
>> <ja...@lucidimagination.com> wrote:
>>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
>>> hardest of the work.
>>>
>>> I'm busy on some other things right now, but maybe next week I can take a
>>> look.
>>>
>>> -- Jack Krupansky
>>>
>>> -----Original Message----- From: Karl Wright
>>> Sent: Tuesday, November 23, 2010 1:00 PM
>>> To: connectors-dev@incubator.apache.org
>>> Subject: Re: Release?
>>>
>>> While I was looking for a solution, an upload attempt succeeded!
>>>
>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>
>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>>> manifoldcf-0.1.tar.gz.md5
>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>>> manifoldcf-0.1.zip.md5
>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>> [kwright@minotaur:~]$
>>>
>>> Please let me know what you think.
>>> Karl
>>>
>>>
>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>
>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>> another way.
>>>> Karl
>>>>
>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>
>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>> general@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 <da...@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
>>>>>>>>>> <gs...@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
>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Uploaded RC1.
Karl
On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <da...@gmail.com> wrote:
> A problem with the FileNet connector has caused me to build an RC1.
> It's uploading now.
>
> Karl
>
> On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
> <ja...@lucidimagination.com> wrote:
>> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
>> hardest of the work.
>>
>> I'm busy on some other things right now, but maybe next week I can take a
>> look.
>>
>> -- Jack Krupansky
>>
>> -----Original Message----- From: Karl Wright
>> Sent: Tuesday, November 23, 2010 1:00 PM
>> To: connectors-dev@incubator.apache.org
>> Subject: Re: Release?
>>
>> While I was looking for a solution, an upload attempt succeeded!
>>
>> So there is now an RC0 out on people.apache.org/~kwright:
>>
>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
>> manifoldcf-0.1.tar.gz.md5
>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
>> manifoldcf-0.1.zip.md5
>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>> [kwright@minotaur:~]$
>>
>> Please let me know what you think.
>> Karl
>>
>>
>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>> another way.
>>> Karl
>>>
>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>
>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>> general@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 <da...@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
>>>>>>>>> <gs...@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
>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
A problem with the FileNet connector has caused me to build an RC1.
It's uploading now.
Karl
On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
<ja...@lucidimagination.com> wrote:
> That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
> hardest of the work.
>
> I'm busy on some other things right now, but maybe next week I can take a
> look.
>
> -- Jack Krupansky
>
> -----Original Message----- From: Karl Wright
> Sent: Tuesday, November 23, 2010 1:00 PM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Release?
>
> While I was looking for a solution, an upload attempt succeeded!
>
> So there is now an RC0 out on people.apache.org/~kwright:
>
> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
> manifoldcf-0.1.tar.gz.md5
> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
> manifoldcf-0.1.zip.md5
> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
> [kwright@minotaur:~]$
>
> Please let me know what you think.
> Karl
>
>
> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>
>> The upload has failed repeatedly for me, so I'll clearly have to find
>> another way.
>> Karl
>>
>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>> general@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 <da...@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
>>>>>>>> <gs...@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
>>>>>>>>>>> <ja...@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
>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>> <ja...@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
>>>>
>>>>
>>>
>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of the
hardest of the work.
I'm busy on some other things right now, but maybe next week I can take a
look.
-- Jack Krupansky
-----Original Message-----
From: Karl Wright
Sent: Tuesday, November 23, 2010 1:00 PM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?
While I was looking for a solution, an upload attempt succeeded!
So there is now an RC0 out on people.apache.org/~kwright:
[kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
-rw-r--r-- 1 kwright kwright 63 Nov 23 17:57
manifoldcf-0.1.tar.gz.md5
-rw-r--r-- 1 kwright kwright 60 Nov 23 17:57
manifoldcf-0.1.zip.md5
-rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
-rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
[kwright@minotaur:~]$
Please let me know what you think.
Karl
On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
> The upload has failed repeatedly for me, so I'll clearly have to find
> another way.
> Karl
>
> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>> 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 <gs...@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 <da...@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 <da...@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
>>>>>> general@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 <da...@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
>>>>>>> <gs...@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
>>>>>>>>>> <ja...@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
>>>>>>>>>>> <ja...@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
>>>>>>>>>>>> <ja...@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
>>>
>>>
>>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
Hmm, for some reason I can't import the KEYS file
gpg --import KEYS
On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
> Done
> Karl
>
> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>> ok - I might move it there
>> Karl
>>
>>
>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>
>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>
>>> -Grant
>>>
>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>
>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>
>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>
>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>> [kwright@minotaur:~]$
>>>>
>>>> Please let me know what you think.
>>>> Karl
>>>>
>>>>
>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>> another way.
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 2, 2010, at 9:58 PM, Karl Wright wrote:
> For your questions (6) and (7): The json code we use comes from
> www.json.org, and there is no prebuilt jar from that source, just
> source files.
Hmmm. OK. The license on it is fine, but we should make sure it is properly attributed. Either that or just build the jar offline, put a note as to where to get the source and package the jar.
> We therefore build it ourselves.
> For the memex connector, we still have all the build machinery in
> place, on the chance that somebody will supply the connector code. It
> is conditional in any case, so there is no harm in maintaining it
> there. The files that Memex wanted removed are not included.
OK. That sounds fine.
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
For your questions (6) and (7): The json code we use comes from
www.json.org, and there is no prebuilt jar from that source, just
source files. We therefore build it ourselves.
For the memex connector, we still have all the build machinery in
place, on the chance that somebody will supply the connector code. It
is conditional in any case, so there is no harm in maintaining it
there. The files that Memex wanted removed are not included.
Karl
On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
> We're close, but I think we've got a few more things to do. I did get it to compile.
>
> Notes:
>
> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
> 2. Many of the libs require an entry in the NOTICE.txt file
> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
> 6. What's json/org/json all about?
> 7. I still see Memex stuff in connectors dir. I didn't check other places.
> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>
> Other than that, some other eyes on it would be good.
>
> -Grant
>
> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>
>> Done
>> Karl
>>
>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>> ok - I might move it there
>>> Karl
>>>
>>>
>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>
>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>
>>>> -Grant
>>>>
>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>
>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>
>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>
>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>> [kwright@minotaur:~]$
>>>>>
>>>>> Please let me know what you think.
>>>>> Karl
>>>>>
>>>>>
>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>> another way.
>>>>>> Karl
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I've given a first whack at (2) and (3) now. It would be great for
someone to review these to see if I missed anything vital. (Robert, I
figured we could compare and contrast, and see if we seem to have the
same stuff).
Thanks,
Karl
On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
> We're close, but I think we've got a few more things to do. I did get it to compile.
>
> Notes:
>
> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
> 2. Many of the libs require an entry in the NOTICE.txt file
> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
> 6. What's json/org/json all about?
> 7. I still see Memex stuff in connectors dir. I didn't check other places.
> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>
> Other than that, some other eyes on it would be good.
>
> -Grant
>
> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>
>> Done
>> Karl
>>
>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>> ok - I might move it there
>>> Karl
>>>
>>>
>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>
>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>
>>>> -Grant
>>>>
>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>
>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>
>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>
>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>> [kwright@minotaur:~]$
>>>>>
>>>>> Please let me know what you think.
>>>>> Karl
>>>>>
>>>>>
>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>> another way.
>>>>>> Karl
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
It was a person at Microsoft that Andrei pointed me to. He said it
typically takes about 6 months.
I'll dig through my old emails and see if I can find the name.
Karl
On Fri, Dec 3, 2010 at 11:51 AM, Grant Ingersoll <gs...@apache.org> wrote:
> I can live w/ the Metacarta refs for now. I'll open a JIRA issue to track them.
>
> Also, not sure why you didn't get your MSDN access. I got mine a while ago (but haven't set it up yet or downloaded Visual Studio). Who did you contact?
>
> -Grant
>
> On Dec 3, 2010, at 11:04 AM, Karl Wright wrote:
>
>> I believe I've done all I can to make Rat happy. Grant, would you
>> like to run it again and tell me what you think should be still
>> addressed? Other than the MetaCarta Permissions SharePoint web
>> service, the only other consistent problems are the standard library
>> tld's for the UI. These came from an Apache source, if I recall, but
>> they did not have an Apache license header on them when I picked them
>> up.
>>
>> Thanks,
>> Karl
>>
>>
>> On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>>>
>>> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>>>
>>>> Can you be more specific about the files that refer to metacarta? Or
>>>> does Rat know to look for MetaCarta?
>>>
>>> I just happened to notice them in the RAT output. It looked like properties files.
>>>
>>> Examples:
>>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
>>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
>>> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>>>
>>>
>>> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>>>
>>> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>>>
>>>
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
I can live w/ the Metacarta refs for now. I'll open a JIRA issue to track them.
Also, not sure why you didn't get your MSDN access. I got mine a while ago (but haven't set it up yet or downloaded Visual Studio). Who did you contact?
-Grant
On Dec 3, 2010, at 11:04 AM, Karl Wright wrote:
> I believe I've done all I can to make Rat happy. Grant, would you
> like to run it again and tell me what you think should be still
> addressed? Other than the MetaCarta Permissions SharePoint web
> service, the only other consistent problems are the standard library
> tld's for the UI. These came from an Apache source, if I recall, but
> they did not have an Apache license header on them when I picked them
> up.
>
> Thanks,
> Karl
>
>
> On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>>
>>> Can you be more specific about the files that refer to metacarta? Or
>>> does Rat know to look for MetaCarta?
>>
>> I just happened to notice them in the RAT output. It looked like properties files.
>>
>> Examples:
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>>
>>
>> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>>
>> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>>
>>
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I believe I've done all I can to make Rat happy. Grant, would you
like to run it again and tell me what you think should be still
addressed? Other than the MetaCarta Permissions SharePoint web
service, the only other consistent problems are the standard library
tld's for the UI. These came from an Apache source, if I recall, but
they did not have an Apache license header on them when I picked them
up.
Thanks,
Karl
On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>
>> Can you be more specific about the files that refer to metacarta? Or
>> does Rat know to look for MetaCarta?
>
> I just happened to notice them in the RAT output. It looked like properties files.
>
> Examples:
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>
>
> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>
> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>
>
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
nvm - I had a newer rat snapshot jar in there as well, from something else.
Karl
On Fri, Dec 3, 2010 at 9:16 AM, Karl Wright <da...@gmail.com> wrote:
> The metacarta-agents and agents.conf files are danglers and can be
> removed. I'll check out the sharepoint web service.
>
> The rat jars are not sufficient - there are apparently dependencies
> that also need to be installed:
>
> BUILD FAILED
> C:\wip\mcf\trunk\build.xml:1421: java.lang.NoClassDefFoundError: org/apache/comm
> ons/cli/ParseException
> at org.apache.rat.anttasks.Report.createReport(Report.java:273)
> at org.apache.rat.anttasks.Report.execute(Report.java:193)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav
> a:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe
> cutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.Main.runBuild(Main.java:801)
> at org.apache.tools.ant.Main.startAnt(Main.java:218)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
>
>
> I was hoping you had a list of those dependencies, or a document that
> pointed at them. If this is complicated enough it might be best to
> check in the necessary jars in the manifoldcf/lib area, although that
> would bloat the deliverable still further.
>
> Karl
>
>
> On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>>
>>> Can you be more specific about the files that refer to metacarta? Or
>>> does Rat know to look for MetaCarta?
>>
>> I just happened to notice them in the RAT output. It looked like properties files.
>>
>> Examples:
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
>> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>>
>>
>> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>>
>> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>>
>>
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
The metacarta-agents and agents.conf files are danglers and can be
removed. I'll check out the sharepoint web service.
The rat jars are not sufficient - there are apparently dependencies
that also need to be installed:
BUILD FAILED
C:\wip\mcf\trunk\build.xml:1421: java.lang.NoClassDefFoundError: org/apache/comm
ons/cli/ParseException
at org.apache.rat.anttasks.Report.createReport(Report.java:273)
at org.apache.rat.anttasks.Report.execute(Report.java:193)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav
a:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe
cutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
I was hoping you had a list of those dependencies, or a document that
pointed at them. If this is complicated enough it might be best to
check in the necessary jars in the manifoldcf/lib area, although that
would bloat the deliverable still further.
Karl
On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>
>> Can you be more specific about the files that refer to metacarta? Or
>> does Rat know to look for MetaCarta?
>
> I just happened to notice them in the RAT output. It looked like properties files.
>
> Examples:
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>
>
> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>
> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>
>
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
The SharePoint web service file you referred to is an auto-generated
file. In order to change anything about it I need to be able to
change the entire project. Unfortunately, I no longer have access to
a copy of Visual Studio, which would be required for me to do this.
Also, I am not familiar with the process by which service names such
as this would be changed, whether that would affect the soap itself
and thus the client side, etc. I don't have a testing setup either.
If changing the name of this service is a prerequisite for release,
let it be known that I requested a copy of MSDN that I should receive
as an apache developer some six weeks ago. After that arrives, it
will require some time to learn the process, set up servers, and test.
Probably this will delay a 0.1 release until February or March.
Sorry for the bad news,
Karl
On Fri, Dec 3, 2010 at 9:09 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
>
>> Can you be more specific about the files that refer to metacarta? Or
>> does Rat know to look for MetaCarta?
>
> I just happened to notice them in the RAT output. It looked like properties files.
>
> Examples:
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
> /Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
> /Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
>
>
> FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
>
> http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
>
>
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 3, 2010, at 8:32 AM, Karl Wright wrote:
> Can you be more specific about the files that refer to metacarta? Or
> does Rat know to look for MetaCarta?
I just happened to notice them in the RAT output. It looked like properties files.
Examples:
/Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/metacarta-agents
/Volumes/tb/grantingersoll/projects/mcf/trunk/framework/agents/agents.conf
/Volumes/tb/grantingersoll/projects/mcf/trunk/connectors/sharepoint/webservice/Properties/Settings.settings
FYI, to run RAT, you need to download the JARs and place them in your ANT lib.
http://incubator.apache.org/rat/downloads.html will get you the release. See http://incubator.apache.org/rat/ for more info on running
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Can you be more specific about the files that refer to metacarta? Or
does Rat know to look for MetaCarta?
Karl
On Fri, Dec 3, 2010 at 8:28 AM, Grant Ingersoll <gs...@apache.org> wrote:
> I added the RAT stuff
>
> ant rat-sources
>
> It can be refined a bit to exclude some things, but running it shows a whole lot of stuff that doesn't have headers.
>
> Also, I noticed we have a whole lot of files that refer to Metacarta still. I think those need to be changed.
>
>
> -Grant
>
> On Dec 2, 2010, at 11:11 PM, Karl Wright wrote:
>
>> Great!
>> Karl
>>
>> On Thu, Dec 2, 2010 at 10:20 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> I can hook up the RAT stuff.
>>>
>>> On Dec 2, 2010, at 10:02 PM, Karl Wright wrote:
>>>
>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>
>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>> changes in the release branch only?
>>>>>
>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>
>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>
>>>>>
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>> 6. What's json/org/json all about?
>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>
>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>
>>>>>>>> Done
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> ok - I might move it there
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>
>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>
>>>>>>>>>> -Grant
>>>>>>>>>>
>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>
>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>
>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>
>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>
>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>> another way.
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------
>>>>>>>>>> Grant Ingersoll
>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> Grant Ingersoll
>>>>>>> http://www.lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com
>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
I added the RAT stuff
ant rat-sources
It can be refined a bit to exclude some things, but running it shows a whole lot of stuff that doesn't have headers.
Also, I noticed we have a whole lot of files that refer to Metacarta still. I think those need to be changed.
-Grant
On Dec 2, 2010, at 11:11 PM, Karl Wright wrote:
> Great!
> Karl
>
> On Thu, Dec 2, 2010 at 10:20 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> I can hook up the RAT stuff.
>>
>> On Dec 2, 2010, at 10:02 PM, Karl Wright wrote:
>>
>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>
>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>
>>>>> Hi Grant,
>>>>>
>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>> You also seem to be asking for a number of other fixes that are
>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>> changes in the release branch only?
>>>>
>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>
>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>
>>>>
>>>>>
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>> 6. What's json/org/json all about?
>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>
>>>>>> Other than that, some other eyes on it would be good.
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>
>>>>>>> Done
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> ok - I might move it there
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>
>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>
>>>>>>>>> -Grant
>>>>>>>>>
>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>
>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>
>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>
>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>
>>>>>>>>>> Please let me know what you think.
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>> another way.
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------
>>>>>>>>> Grant Ingersoll
>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> Grant Ingersoll
>>>>>> http://www.lucidimagination.com
>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Great!
Karl
On Thu, Dec 2, 2010 at 10:20 PM, Grant Ingersoll <gs...@apache.org> wrote:
> I can hook up the RAT stuff.
>
> On Dec 2, 2010, at 10:02 PM, Karl Wright wrote:
>
>> OK, so I will do the appropriate things to make (1), (4), and maybe
>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>> Karl
>>
>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>
>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>
>>>> Hi Grant,
>>>>
>>>> In offline conversation you clarified that for (1) you are looking for
>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>> You also seem to be asking for a number of other fixes that are
>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>> changes in the release branch only?
>>>
>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>
>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>
>>>
>>>>
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>
>>>>> Notes:
>>>>>
>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>> 6. What's json/org/json all about?
>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>
>>>>> Other than that, some other eyes on it would be good.
>>>>>
>>>>> -Grant
>>>>>
>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>
>>>>>> Done
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> ok - I might move it there
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>
>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>
>>>>>>>> -Grant
>>>>>>>>
>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>
>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>
>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>
>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>
>>>>>>>>> Please let me know what you think.
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>> another way.
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------
>>>>>>>> Grant Ingersoll
>>>>>>>> http://www.lucidimagination.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com
>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
I can hook up the RAT stuff.
On Dec 2, 2010, at 10:02 PM, Karl Wright wrote:
> OK, so I will do the appropriate things to make (1), (4), and maybe
> (5) happen. Does anyone want to help with (2), (3), and (8)?
> Karl
>
> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>
>>> Hi Grant,
>>>
>>> In offline conversation you clarified that for (1) you are looking for
>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>> You also seem to be asking for a number of other fixes that are
>>> specific to a release, that I presume would NOT be in sources on trunk
>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>> changes in the release branch only?
>>
>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>
>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>
>>
>>>
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>
>>>> Notes:
>>>>
>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>> 6. What's json/org/json all about?
>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>
>>>> Other than that, some other eyes on it would be good.
>>>>
>>>> -Grant
>>>>
>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>
>>>>> Done
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>> ok - I might move it there
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>
>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>
>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>
>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>
>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>
>>>>>>>> Please let me know what you think.
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>> another way.
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> Grant Ingersoll
>>>>>>> http://www.lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I uploaded an RC3.
Karl
On Sat, Dec 18, 2010 at 5:04 AM, Karl Wright <da...@gmail.com> wrote:
> I found two other build.xml files that were missing headers. This was
> because Grant's implementation of rat-sources was incomplete. So I'm
> going to have to spin an RC3.
>
> I fixed rat-sources. The current output is as follows (excuse the wrap):
>
> [rat:report] 32 Unknown Licenses
> [rat:report]
> [rat:report] *******************************
> [rat:report]
> [rat:report] Unapproved licenses:
> [rat:report]
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/CDL.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/Cookie.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/CookieList.ja
> va
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/HTTP.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/HTTPTokener.j
> ava
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONArray.jav
> a
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONException
> .java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONML.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONObject.ja
> va
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONString.ja
> va
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONStringer.
> java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONTokener.j
> ava
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONWriter.ja
> va
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/Test.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/XML.java
> [rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/XMLTokener.ja
> va
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
> ce/Test Harness/Installation files/Setup.Ini
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
> ce/Test Harness/source code/TestHarness.cs
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
> ce/Web Service/Installation files/Setup.Ini
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/MCPermissionsService.csproj
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/MetaCarta.snk
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/Properties/AssemblyInfo.cs
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/Properties/Settings.Designer.cs
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/Properties/Settings.settings
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/Web References/SPPermissionsService/Reference.cs
> [rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
> rvice/Web References/SPPermissionsService/Reference.map
> [rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
> in/webapp/WEB-INF/jsp/c.tld
> [rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
> in/webapp/WEB-INF/jsp/fmt.tld
> [rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
> in/webapp/WEB-INF/jsp/sql.tld
> [rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
> in/webapp/WEB-INF/jsp/x.tld
> [rat:report] C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skin
> s/common/xslt/html/split.xsl
> [rat:report] C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skin
> s/lucene/note.txt
> [rat:report]
> [rat:report] *******************************
>
>
> The files under json contain the json.org license, which Apache agreed
> was OK despite rat's complaining.
> The files under framework/crawler-ui/src/main/webapp/WEB-INF/jsp are
> all from tomcat, but they were not labeled with appropriate licenses
> at that time. Should I attach licenses to these?
> The files under site came from Grant's initial check-in of the lcf
> site; I don't know their etiology or which license should apply to
> them.
>
> The SharePoint and Meridio web service files are generated files,
> which I believe do not need licensing. The generating tool is Visual
> Studio.
>
> Before I generate an RC3, can Grant please let me know what further
> should be done here?
>
> Thanks,
> Karl
>
>
> On Thu, Dec 16, 2010 at 7:04 PM, Karl Wright <da...@gmail.com> wrote:
>> There is now an RC2 on people.apache.org.
>>
>> Karl
>>
>>
>> On Thu, Dec 16, 2010 at 3:44 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>
>>> On Dec 16, 2010, at 4:22 AM, Karl Wright wrote:
>>>
>>>> Tests are now complete for the framework changes.
>>>> Robert, Grant, please comment on CONNECTORS-128 about the future of
>>>> the FileNet and Documentum connectors. If those connectors are deemed
>>>> acceptable, I can generate a new release candidate.
>>>>
>>>> Karl
>>>>
>>>> On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> The preliminary change has been done, and I was able to hand-test a
>>>>> good chunk of the modified queries by hand, so I checked it in. I
>>>>> still need to test document expiration, however, and I'd like the
>>>>> automated tests to cover the modified functionality. I won't be able
>>>>> to get to it this until next weekend at the earliest,
>>>>>
>>>>> During the process of removing string constants from all queries, I
>>>>> also noticed that string constants are used by the FileNet and
>>>>> Documentum connectors. These connectors have a proprietary, SQL-like
>>>>> language (I don't know what the FileNet language is called, but the
>>>>> Documentum one is called DQL.) There does not appear to be any way to
>>>>> use the equivalent of query parameters for either sql-like language.
>>>>> If quoting is always unsafe, that would imply that neither the FileNet
>>>>> connector nor the Documentum connector could be made secure, by
>>>>> Robert's standards. Of course, the same is going to be true of any
>>>>> FileNet or Documentum client code.
>>>>>
>>>>> Robert, Grant, do you believe I should delete these connectors?
>>>
>>> No, I don't think you should. If that's the only way to do it, then it is what it is and we have to go with it.
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I found two other build.xml files that were missing headers. This was
because Grant's implementation of rat-sources was incomplete. So I'm
going to have to spin an RC3.
I fixed rat-sources. The current output is as follows (excuse the wrap):
[rat:report] 32 Unknown Licenses
[rat:report]
[rat:report] *******************************
[rat:report]
[rat:report] Unapproved licenses:
[rat:report]
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/CDL.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/Cookie.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/CookieList.ja
va
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/HTTP.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/HTTPTokener.j
ava
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONArray.jav
a
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONException
.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONML.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONObject.ja
va
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONString.ja
va
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONStringer.
java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONTokener.j
ava
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/JSONWriter.ja
va
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/Test.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/XML.java
[rat:report] C:/wip/mcf-release/release-0.1-branch/json/org/json/XMLTokener.ja
va
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
ce/Test Harness/Installation files/Setup.Ini
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
ce/Test Harness/source code/TestHarness.cs
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/meridio/webservi
ce/Web Service/Installation files/Setup.Ini
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/MCPermissionsService.csproj
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/MetaCarta.snk
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/Properties/AssemblyInfo.cs
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/Properties/Settings.Designer.cs
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/Properties/Settings.settings
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/Web References/SPPermissionsService/Reference.cs
[rat:report] C:/wip/mcf-release/release-0.1-branch/connectors/sharepoint/webse
rvice/Web References/SPPermissionsService/Reference.map
[rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
in/webapp/WEB-INF/jsp/c.tld
[rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
in/webapp/WEB-INF/jsp/fmt.tld
[rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
in/webapp/WEB-INF/jsp/sql.tld
[rat:report] C:/wip/mcf-release/release-0.1-branch/framework/crawler-ui/src/ma
in/webapp/WEB-INF/jsp/x.tld
[rat:report] C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skin
s/common/xslt/html/split.xsl
[rat:report] C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skin
s/lucene/note.txt
[rat:report]
[rat:report] *******************************
The files under json contain the json.org license, which Apache agreed
was OK despite rat's complaining.
The files under framework/crawler-ui/src/main/webapp/WEB-INF/jsp are
all from tomcat, but they were not labeled with appropriate licenses
at that time. Should I attach licenses to these?
The files under site came from Grant's initial check-in of the lcf
site; I don't know their etiology or which license should apply to
them.
The SharePoint and Meridio web service files are generated files,
which I believe do not need licensing. The generating tool is Visual
Studio.
Before I generate an RC3, can Grant please let me know what further
should be done here?
Thanks,
Karl
On Thu, Dec 16, 2010 at 7:04 PM, Karl Wright <da...@gmail.com> wrote:
> There is now an RC2 on people.apache.org.
>
> Karl
>
>
> On Thu, Dec 16, 2010 at 3:44 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Dec 16, 2010, at 4:22 AM, Karl Wright wrote:
>>
>>> Tests are now complete for the framework changes.
>>> Robert, Grant, please comment on CONNECTORS-128 about the future of
>>> the FileNet and Documentum connectors. If those connectors are deemed
>>> acceptable, I can generate a new release candidate.
>>>
>>> Karl
>>>
>>> On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <da...@gmail.com> wrote:
>>>> The preliminary change has been done, and I was able to hand-test a
>>>> good chunk of the modified queries by hand, so I checked it in. I
>>>> still need to test document expiration, however, and I'd like the
>>>> automated tests to cover the modified functionality. I won't be able
>>>> to get to it this until next weekend at the earliest,
>>>>
>>>> During the process of removing string constants from all queries, I
>>>> also noticed that string constants are used by the FileNet and
>>>> Documentum connectors. These connectors have a proprietary, SQL-like
>>>> language (I don't know what the FileNet language is called, but the
>>>> Documentum one is called DQL.) There does not appear to be any way to
>>>> use the equivalent of query parameters for either sql-like language.
>>>> If quoting is always unsafe, that would imply that neither the FileNet
>>>> connector nor the Documentum connector could be made secure, by
>>>> Robert's standards. Of course, the same is going to be true of any
>>>> FileNet or Documentum client code.
>>>>
>>>> Robert, Grant, do you believe I should delete these connectors?
>>
>> No, I don't think you should. If that's the only way to do it, then it is what it is and we have to go with it.
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
There is now an RC2 on people.apache.org.
Karl
On Thu, Dec 16, 2010 at 3:44 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Dec 16, 2010, at 4:22 AM, Karl Wright wrote:
>
>> Tests are now complete for the framework changes.
>> Robert, Grant, please comment on CONNECTORS-128 about the future of
>> the FileNet and Documentum connectors. If those connectors are deemed
>> acceptable, I can generate a new release candidate.
>>
>> Karl
>>
>> On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <da...@gmail.com> wrote:
>>> The preliminary change has been done, and I was able to hand-test a
>>> good chunk of the modified queries by hand, so I checked it in. I
>>> still need to test document expiration, however, and I'd like the
>>> automated tests to cover the modified functionality. I won't be able
>>> to get to it this until next weekend at the earliest,
>>>
>>> During the process of removing string constants from all queries, I
>>> also noticed that string constants are used by the FileNet and
>>> Documentum connectors. These connectors have a proprietary, SQL-like
>>> language (I don't know what the FileNet language is called, but the
>>> Documentum one is called DQL.) There does not appear to be any way to
>>> use the equivalent of query parameters for either sql-like language.
>>> If quoting is always unsafe, that would imply that neither the FileNet
>>> connector nor the Documentum connector could be made secure, by
>>> Robert's standards. Of course, the same is going to be true of any
>>> FileNet or Documentum client code.
>>>
>>> Robert, Grant, do you believe I should delete these connectors?
>
> No, I don't think you should. If that's the only way to do it, then it is what it is and we have to go with it.
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 16, 2010, at 4:22 AM, Karl Wright wrote:
> Tests are now complete for the framework changes.
> Robert, Grant, please comment on CONNECTORS-128 about the future of
> the FileNet and Documentum connectors. If those connectors are deemed
> acceptable, I can generate a new release candidate.
>
> Karl
>
> On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <da...@gmail.com> wrote:
>> The preliminary change has been done, and I was able to hand-test a
>> good chunk of the modified queries by hand, so I checked it in. I
>> still need to test document expiration, however, and I'd like the
>> automated tests to cover the modified functionality. I won't be able
>> to get to it this until next weekend at the earliest,
>>
>> During the process of removing string constants from all queries, I
>> also noticed that string constants are used by the FileNet and
>> Documentum connectors. These connectors have a proprietary, SQL-like
>> language (I don't know what the FileNet language is called, but the
>> Documentum one is called DQL.) There does not appear to be any way to
>> use the equivalent of query parameters for either sql-like language.
>> If quoting is always unsafe, that would imply that neither the FileNet
>> connector nor the Documentum connector could be made secure, by
>> Robert's standards. Of course, the same is going to be true of any
>> FileNet or Documentum client code.
>>
>> Robert, Grant, do you believe I should delete these connectors?
No, I don't think you should. If that's the only way to do it, then it is what it is and we have to go with it.
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Tests are now complete for the framework changes.
Robert, Grant, please comment on CONNECTORS-128 about the future of
the FileNet and Documentum connectors. If those connectors are deemed
acceptable, I can generate a new release candidate.
Karl
On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <da...@gmail.com> wrote:
> The preliminary change has been done, and I was able to hand-test a
> good chunk of the modified queries by hand, so I checked it in. I
> still need to test document expiration, however, and I'd like the
> automated tests to cover the modified functionality. I won't be able
> to get to it this until next weekend at the earliest,
>
> During the process of removing string constants from all queries, I
> also noticed that string constants are used by the FileNet and
> Documentum connectors. These connectors have a proprietary, SQL-like
> language (I don't know what the FileNet language is called, but the
> Documentum one is called DQL.) There does not appear to be any way to
> use the equivalent of query parameters for either sql-like language.
> If quoting is always unsafe, that would imply that neither the FileNet
> connector nor the Documentum connector could be made secure, by
> Robert's standards. Of course, the same is going to be true of any
> FileNet or Documentum client code.
>
> Robert, Grant, do you believe I should delete these connectors?
>
> Karl
>
>
> On Fri, Dec 10, 2010 at 10:00 AM, Karl Wright <da...@gmail.com> wrote:
>> The only vulnerability occurs if:
>> (a) People use PostgreSQL configured incorrectly, AND
>> (b) Coders change ManifoldCF after the release to use the
>> quoteSQLString method for non-constant values.
>> OR
>> (a) People use PostgreSQL configured incorrectly, AND
>> (b) Our audit procedures have overlooked a non-constant usage of
>> quoteSQLString somehow.
>>
>> But, clearly, any whiff of a potential security issue, no matter how
>> remote the chances of one actually existing in real life, are clearly
>> enough to require some weeks of work before a release can be made.
>> Personally, I'd be concerned about places where just plain quotes
>> appeared in a string rather than finger quoteSQLString as a bad actor,
>> but so be it.
>>
>> I therefore withdraw the release plan and will delete the release
>> branch. We can discuss strategy for release again when the code has
>> been reworked and all the tests exist to confirm to my satisfaction
>> that we've broken nothing.
>>
>> Karl
>>
>>
>>
>> On Fri, Dec 10, 2010 at 9:50 AM, Jack Krupansky
>> <ja...@lucidimagination.com> wrote:
>>> At this point in the discussion maybe what we need is a clearly stated Jira
>>> on the issue and what specifically is needed. Whether it is needed for 0.1
>>> is another matter. It sounds like (potentially) a definite 1.0 issue, but
>>> could we get by with a clear "statement of vulnerability" for a 0.x release
>>> (if in fact there is an actual vulnerability)?
>>>
>>> It sounds like there may be a distinction between "actual" vulnerability and
>>> "potential" vulnerability. Whether such a distinction really matters is
>>> another matter.
>>>
>>> -- Jack Krupansky
>>>
>>> -----Original Message----- From: Grant Ingersoll
>>> Sent: Friday, December 10, 2010 9:36 AM
>>> To: connectors-dev@incubator.apache.org
>>> Subject: Re: Release?
>>>
>>> I think if there are known vulnerabilities, we need to fix them.
>>>
>>> On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
>>>
>>>> You can be serious about security without agreeing on the remediation.
>>>> This software certainly adhered to MetaCarta standards and was
>>>> audited by government agencies as well. I understand your position,
>>>> but I don't know if everyone will see it in a similar way, since a
>>>> code audit highlights no problems at this time, because quoteSQLString
>>>> is used only on constant values. What do others think? If the
>>>> incubator would prohibit release on this basis, how in the heck did
>>>> solr ever get released?
>>>>
>>>> Karl
>>>>
>>>> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>>>>>
>>>>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>
>>>>>> Do you believe that this is a
>>>>>> requirement for an initial release? If so, I believe we should
>>>>>> suspend plans for that release and revisit it in February or March.
>>>>>>
>>>>>
>>>>> I'll certainly go along with whatever everyone feels on this one... it
>>>>> was just always my impression that Apache was pretty serious about
>>>>> security, but I'm not really sure how this applies to incubating
>>>>> projects etc.
>>>>>
>>>>> I thought it was relevant especially since the Solr Wiki says: The
>>>>> recommended way to add document level security to your search is
>>>>> through Apache Lucene Connector Framework (LCF).
>>>>>
>>>>> http://wiki.apache.org/solr/SolrSecurity
>>>>>
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
The preliminary change has been done, and I was able to hand-test a
good chunk of the modified queries by hand, so I checked it in. I
still need to test document expiration, however, and I'd like the
automated tests to cover the modified functionality. I won't be able
to get to it this until next weekend at the earliest,
During the process of removing string constants from all queries, I
also noticed that string constants are used by the FileNet and
Documentum connectors. These connectors have a proprietary, SQL-like
language (I don't know what the FileNet language is called, but the
Documentum one is called DQL.) There does not appear to be any way to
use the equivalent of query parameters for either sql-like language.
If quoting is always unsafe, that would imply that neither the FileNet
connector nor the Documentum connector could be made secure, by
Robert's standards. Of course, the same is going to be true of any
FileNet or Documentum client code.
Robert, Grant, do you believe I should delete these connectors?
Karl
On Fri, Dec 10, 2010 at 10:00 AM, Karl Wright <da...@gmail.com> wrote:
> The only vulnerability occurs if:
> (a) People use PostgreSQL configured incorrectly, AND
> (b) Coders change ManifoldCF after the release to use the
> quoteSQLString method for non-constant values.
> OR
> (a) People use PostgreSQL configured incorrectly, AND
> (b) Our audit procedures have overlooked a non-constant usage of
> quoteSQLString somehow.
>
> But, clearly, any whiff of a potential security issue, no matter how
> remote the chances of one actually existing in real life, are clearly
> enough to require some weeks of work before a release can be made.
> Personally, I'd be concerned about places where just plain quotes
> appeared in a string rather than finger quoteSQLString as a bad actor,
> but so be it.
>
> I therefore withdraw the release plan and will delete the release
> branch. We can discuss strategy for release again when the code has
> been reworked and all the tests exist to confirm to my satisfaction
> that we've broken nothing.
>
> Karl
>
>
>
> On Fri, Dec 10, 2010 at 9:50 AM, Jack Krupansky
> <ja...@lucidimagination.com> wrote:
>> At this point in the discussion maybe what we need is a clearly stated Jira
>> on the issue and what specifically is needed. Whether it is needed for 0.1
>> is another matter. It sounds like (potentially) a definite 1.0 issue, but
>> could we get by with a clear "statement of vulnerability" for a 0.x release
>> (if in fact there is an actual vulnerability)?
>>
>> It sounds like there may be a distinction between "actual" vulnerability and
>> "potential" vulnerability. Whether such a distinction really matters is
>> another matter.
>>
>> -- Jack Krupansky
>>
>> -----Original Message----- From: Grant Ingersoll
>> Sent: Friday, December 10, 2010 9:36 AM
>> To: connectors-dev@incubator.apache.org
>> Subject: Re: Release?
>>
>> I think if there are known vulnerabilities, we need to fix them.
>>
>> On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
>>
>>> You can be serious about security without agreeing on the remediation.
>>> This software certainly adhered to MetaCarta standards and was
>>> audited by government agencies as well. I understand your position,
>>> but I don't know if everyone will see it in a similar way, since a
>>> code audit highlights no problems at this time, because quoteSQLString
>>> is used only on constant values. What do others think? If the
>>> incubator would prohibit release on this basis, how in the heck did
>>> solr ever get released?
>>>
>>> Karl
>>>
>>> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>>>>
>>>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>
>>>>> Do you believe that this is a
>>>>> requirement for an initial release? If so, I believe we should
>>>>> suspend plans for that release and revisit it in February or March.
>>>>>
>>>>
>>>> I'll certainly go along with whatever everyone feels on this one... it
>>>> was just always my impression that Apache was pretty serious about
>>>> security, but I'm not really sure how this applies to incubating
>>>> projects etc.
>>>>
>>>> I thought it was relevant especially since the Solr Wiki says: The
>>>> recommended way to add document level security to your search is
>>>> through Apache Lucene Connector Framework (LCF).
>>>>
>>>> http://wiki.apache.org/solr/SolrSecurity
>>>>
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
The only vulnerability occurs if:
(a) People use PostgreSQL configured incorrectly, AND
(b) Coders change ManifoldCF after the release to use the
quoteSQLString method for non-constant values.
OR
(a) People use PostgreSQL configured incorrectly, AND
(b) Our audit procedures have overlooked a non-constant usage of
quoteSQLString somehow.
But, clearly, any whiff of a potential security issue, no matter how
remote the chances of one actually existing in real life, are clearly
enough to require some weeks of work before a release can be made.
Personally, I'd be concerned about places where just plain quotes
appeared in a string rather than finger quoteSQLString as a bad actor,
but so be it.
I therefore withdraw the release plan and will delete the release
branch. We can discuss strategy for release again when the code has
been reworked and all the tests exist to confirm to my satisfaction
that we've broken nothing.
Karl
On Fri, Dec 10, 2010 at 9:50 AM, Jack Krupansky
<ja...@lucidimagination.com> wrote:
> At this point in the discussion maybe what we need is a clearly stated Jira
> on the issue and what specifically is needed. Whether it is needed for 0.1
> is another matter. It sounds like (potentially) a definite 1.0 issue, but
> could we get by with a clear "statement of vulnerability" for a 0.x release
> (if in fact there is an actual vulnerability)?
>
> It sounds like there may be a distinction between "actual" vulnerability and
> "potential" vulnerability. Whether such a distinction really matters is
> another matter.
>
> -- Jack Krupansky
>
> -----Original Message----- From: Grant Ingersoll
> Sent: Friday, December 10, 2010 9:36 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Release?
>
> I think if there are known vulnerabilities, we need to fix them.
>
> On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
>
>> You can be serious about security without agreeing on the remediation.
>> This software certainly adhered to MetaCarta standards and was
>> audited by government agencies as well. I understand your position,
>> but I don't know if everyone will see it in a similar way, since a
>> code audit highlights no problems at this time, because quoteSQLString
>> is used only on constant values. What do others think? If the
>> incubator would prohibit release on this basis, how in the heck did
>> solr ever get released?
>>
>> Karl
>>
>> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>>>
>>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>
>>>> Do you believe that this is a
>>>> requirement for an initial release? If so, I believe we should
>>>> suspend plans for that release and revisit it in February or March.
>>>>
>>>
>>> I'll certainly go along with whatever everyone feels on this one... it
>>> was just always my impression that Apache was pretty serious about
>>> security, but I'm not really sure how this applies to incubating
>>> projects etc.
>>>
>>> I thought it was relevant especially since the Solr Wiki says: The
>>> recommended way to add document level security to your search is
>>> through Apache Lucene Connector Framework (LCF).
>>>
>>> http://wiki.apache.org/solr/SolrSecurity
>>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
At this point in the discussion maybe what we need is a clearly stated Jira
on the issue and what specifically is needed. Whether it is needed for 0.1
is another matter. It sounds like (potentially) a definite 1.0 issue, but
could we get by with a clear "statement of vulnerability" for a 0.x release
(if in fact there is an actual vulnerability)?
It sounds like there may be a distinction between "actual" vulnerability and
"potential" vulnerability. Whether such a distinction really matters is
another matter.
-- Jack Krupansky
-----Original Message-----
From: Grant Ingersoll
Sent: Friday, December 10, 2010 9:36 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?
I think if there are known vulnerabilities, we need to fix them.
On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
> You can be serious about security without agreeing on the remediation.
> This software certainly adhered to MetaCarta standards and was
> audited by government agencies as well. I understand your position,
> but I don't know if everyone will see it in a similar way, since a
> code audit highlights no problems at this time, because quoteSQLString
> is used only on constant values. What do others think? If the
> incubator would prohibit release on this basis, how in the heck did
> solr ever get released?
>
> Karl
>
> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>> Do you believe that this is a
>>> requirement for an initial release? If so, I believe we should
>>> suspend plans for that release and revisit it in February or March.
>>>
>>
>> I'll certainly go along with whatever everyone feels on this one... it
>> was just always my impression that Apache was pretty serious about
>> security, but I'm not really sure how this applies to incubating
>> projects etc.
>>
>> I thought it was relevant especially since the Solr Wiki says: The
>> recommended way to add document level security to your search is
>> through Apache Lucene Connector Framework (LCF).
>>
>> http://wiki.apache.org/solr/SolrSecurity
>>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I do not agree there are known vulnerabilities.
Karl
On Fri, Dec 10, 2010 at 9:36 AM, Grant Ingersoll <gs...@apache.org> wrote:
> I think if there are known vulnerabilities, we need to fix them.
>
> On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
>
>> You can be serious about security without agreeing on the remediation.
>> This software certainly adhered to MetaCarta standards and was
>> audited by government agencies as well. I understand your position,
>> but I don't know if everyone will see it in a similar way, since a
>> code audit highlights no problems at this time, because quoteSQLString
>> is used only on constant values. What do others think? If the
>> incubator would prohibit release on this basis, how in the heck did
>> solr ever get released?
>>
>> Karl
>>
>> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>> Do you believe that this is a
>>>> requirement for an initial release? If so, I believe we should
>>>> suspend plans for that release and revisit it in February or March.
>>>>
>>>
>>> I'll certainly go along with whatever everyone feels on this one... it
>>> was just always my impression that Apache was pretty serious about
>>> security, but I'm not really sure how this applies to incubating
>>> projects etc.
>>>
>>> I thought it was relevant especially since the Solr Wiki says: The
>>> recommended way to add document level security to your search is
>>> through Apache Lucene Connector Framework (LCF).
>>>
>>> http://wiki.apache.org/solr/SolrSecurity
>>>
>
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
I think if there are known vulnerabilities, we need to fix them.
On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
> You can be serious about security without agreeing on the remediation.
> This software certainly adhered to MetaCarta standards and was
> audited by government agencies as well. I understand your position,
> but I don't know if everyone will see it in a similar way, since a
> code audit highlights no problems at this time, because quoteSQLString
> is used only on constant values. What do others think? If the
> incubator would prohibit release on this basis, how in the heck did
> solr ever get released?
>
> Karl
>
> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>>> Do you believe that this is a
>>> requirement for an initial release? If so, I believe we should
>>> suspend plans for that release and revisit it in February or March.
>>>
>>
>> I'll certainly go along with whatever everyone feels on this one... it
>> was just always my impression that Apache was pretty serious about
>> security, but I'm not really sure how this applies to incubating
>> projects etc.
>>
>> I thought it was relevant especially since the Solr Wiki says: The
>> recommended way to add document level security to your search is
>> through Apache Lucene Connector Framework (LCF).
>>
>> http://wiki.apache.org/solr/SolrSecurity
>>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
You can be serious about security without agreeing on the remediation.
This software certainly adhered to MetaCarta standards and was
audited by government agencies as well. I understand your position,
but I don't know if everyone will see it in a similar way, since a
code audit highlights no problems at this time, because quoteSQLString
is used only on constant values. What do others think? If the
incubator would prohibit release on this basis, how in the heck did
solr ever get released?
Karl
On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
>> Do you believe that this is a
>> requirement for an initial release? If so, I believe we should
>> suspend plans for that release and revisit it in February or March.
>>
>
> I'll certainly go along with whatever everyone feels on this one... it
> was just always my impression that Apache was pretty serious about
> security, but I'm not really sure how this applies to incubating
> projects etc.
>
> I thought it was relevant especially since the Solr Wiki says: The
> recommended way to add document level security to your search is
> through Apache Lucene Connector Framework (LCF).
>
> http://wiki.apache.org/solr/SolrSecurity
>
Re: Release?
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <da...@gmail.com> wrote:
> Do you believe that this is a
> requirement for an initial release? If so, I believe we should
> suspend plans for that release and revisit it in February or March.
>
I'll certainly go along with whatever everyone feels on this one... it
was just always my impression that Apache was pretty serious about
security, but I'm not really sure how this applies to incubating
projects etc.
I thought it was relevant especially since the Solr Wiki says: The
recommended way to add document level security to your search is
through Apache Lucene Connector Framework (LCF).
http://wiki.apache.org/solr/SolrSecurity
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Ok, thanks for clarifying that.
As I said before, this is a fairly big job which I do not think can be
done in a way that is not destabilizing. I'm therefore going need to
take probably several weeks before it can be completed - in part to
port old MetaCarta tests to the junit testing framework which exercise
more of the queries in question. Do you believe that this is a
requirement for an initial release? If so, I believe we should
suspend plans for that release and revisit it in February or March.
Thanks,
Karl
On Fri, Dec 10, 2010 at 8:03 AM, Robert Muir <rc...@gmail.com> wrote:
> On Tue, Dec 7, 2010 at 8:45 AM, Karl Wright <da...@gmail.com> wrote:
>> I'm really not sure where you are going with this.
>> Are you saying:
>> (a) we should remove quoteSQLString from the abstraction completely;
>
> right, i think a is ideal, we would use real parameters (e.g. via
> PreparedStatement) for all queries, this way parameters are definitely
> parameters and not to be interpreted as sql syntax... and no
> quoting/escaping necessary either.
>
Re: Release?
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Dec 7, 2010 at 8:45 AM, Karl Wright <da...@gmail.com> wrote:
> I'm really not sure where you are going with this.
> Are you saying:
> (a) we should remove quoteSQLString from the abstraction completely;
right, i think a is ideal, we would use real parameters (e.g. via
PreparedStatement) for all queries, this way parameters are definitely
parameters and not to be interpreted as sql syntax... and no
quoting/escaping necessary either.
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I'm really not sure where you are going with this.
Are you saying:
(a) we should remove quoteSQLString from the abstraction completely;
(b) we should audit the code to be sure quoteSQLString is never used
for anything other than to generate a constant;
(c) something else entirely?
I have removed the only case I could find of quoteSQLString being used
on anything other than a constant value, which should satisfy (b). I
would, however, STILL want quoteSQLString to work properly. To that
end, I have examined Derby and find that it appears to follow standard
SQL for quoting in this regard. PostgreSQL will also follow this if
standard_conforming_strings is set to on, and I think it makes a lot
of sense to add that recommendation to the how-to-build-and-deploy
page, which I suggest we do.
Beyond that, I'm waiting for clarification as to your sense of what is
sufficient. "Obviously unsafe" code must be addressed, yes, but what
exactly does that mean? I look at quoting of a constant and see no
danger whatsoever - what am I missing?
Karl
On Tue, Dec 7, 2010 at 8:00 AM, Robert Muir <rc...@gmail.com> wrote:
> On Mon, Dec 6, 2010 at 7:45 PM, Karl Wright <da...@gmail.com> wrote:
>
>> Since quoteSQLString uses ' as it's quotation mark, and properly
>> escapes ' characters within the string, I claim that the method is
>> properly written and cannot be used for a sql attack. If you
>> disagree, provide me a string that "breaks" the escaping that it does.
>
> Just so you know Karl, security issues shouldn't be treated like 'regular bugs'.
> Users/developers shouldnt need to write 'test cases' when code is
> obviously insecure, we should instead write code securely, and specify
> parameters as parameters so that we know they aren't going to be
> interpreted as syntax.
>
> That being said, my examples were just fine, examples. For postgresql
> an example problem is that ' can also be escaped with a \.
> (http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html)
> Thus, in some situations its possible for me to bypass your escaping
> by using the sequence \', which you will escape into \'', giving me an
> unescaped single quote.
>
> This is just *an example*, as i said before to demonstrate why
> escaping is dangerous, I'm not going to go back-and-forth with you on
> this as to whether or not manifoldcf has a problem in any particular
> circumstances.
>
> Someone motivated will always bypass escaping.
> We should make parameters, parameters.
>
Re: Release?
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Dec 6, 2010 at 7:45 PM, Karl Wright <da...@gmail.com> wrote:
> Since quoteSQLString uses ' as it's quotation mark, and properly
> escapes ' characters within the string, I claim that the method is
> properly written and cannot be used for a sql attack. If you
> disagree, provide me a string that "breaks" the escaping that it does.
Just so you know Karl, security issues shouldn't be treated like 'regular bugs'.
Users/developers shouldnt need to write 'test cases' when code is
obviously insecure, we should instead write code securely, and specify
parameters as parameters so that we know they aren't going to be
interpreted as syntax.
That being said, my examples were just fine, examples. For postgresql
an example problem is that ' can also be escaped with a \.
(http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html)
Thus, in some situations its possible for me to bypass your escaping
by using the sequence \', which you will escape into \'', giving me an
unescaped single quote.
This is just *an example*, as i said before to demonstrate why
escaping is dangerous, I'm not going to go back-and-forth with you on
this as to whether or not manifoldcf has a problem in any particular
circumstances.
Someone motivated will always bypass escaping.
We should make parameters, parameters.
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Changes complete.
This was helpful in that it found a bug in the sql generated for
PostgreSQL for two of the history reports. Aside from that, I still
believe this is more of a precaution than a necessity.
Karl
On Mon, Dec 6, 2010 at 8:35 PM, Karl Wright <da...@gmail.com> wrote:
> Here is a list of the pertinent places where quoteSQLString is used.
> Note that EXCEPT in a couple of cases where quoteSQLString was needed
> to furnish an argument for a clause being formed by a database
> abstraction method, ALL other cases are quoting of constant values,
> save in one case, which I am happy to change.
>
>>>>>>>
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/Jobs.java
> getTableName()+" WHERE
> "+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE))+
> " AND "+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE_NOOUTPUT))+
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")
> "+constructOffsetLimitClause(0,1),null,null,null,1);
> statusField+" IN
> ("+quoteSQLString(statusToString(STATUS_READYFORDELETE))+","+
> quoteSQLString(statusToString(STATUS_SHUTTINGDOWN))+")
> "+constructOffsetLimitClause(0,1),
> quoteSQLString(statusToString(STATUS_ACTIVE)) + "," +
> quoteSQLString(statusToString(STATUS_ACTIVESEEDING)) +
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobManager.java
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))+
> " AND
> t1."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+
> ")) OR
> (t0."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+
> " AND
> t3."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
> database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))+
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append(")
> AND EXISTS(SELECT 'x' FROM ").append(jobs.getTableName()).append(" t1
> WHERE t0.")
> .append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_COMPLETE))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_PURGATORY))).append(")")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_READYFORSTARTUP))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_STARTINGUP))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUPFORRESTART))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUP))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTING))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTART))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTARTSEEDING))).append("))
> AND ")
> .append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDING))).append(",")
> .append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(")
> AND (")
> .append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(JobQueue.ACTION_RESCAN)))
> .append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))).append(")
> AND ");
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
> .append(database.quoteSQLString(Jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(Jobs.statusToString(jobs.STATUS_ACTIVESEEDING)))
> .append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))).append(")
> AND t1.")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append(",")
> .append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_INACTIVE))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAIT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAITSEEDING))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDWAIT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDWAITSEEDING))+")
> AND "+
> jobs.startMethodField+"!="+database.quoteSQLString(jobs.startMethodToString(IJobDescription.START_DISABLE))+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_UNINSTALLED))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_UNINSTALLED))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NOOUTPUT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_NOOUTPUT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NEITHER))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_NEITHER))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSED))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDSEEDING))+")
> AND "+
> "t99."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)),
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+"
> AND "+
> jobs.typeField+"="+database.quoteSQLString(jobs.typeToString(jobs.TYPE_CONTINUOUS))+"
> AND ("+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORSTARTUP))+"
> FOR UPDATE",null,null,null);
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE_NOOUTPUT))+")
> FOR UPDATE",null,null,null);
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAIT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_UNINSTALLED))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NOOUTPUT))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NEITHER))+")
> FOR UPDATE",null,null,null);
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_NOTIFYINGOFCOMPLETION)),null,null,null);
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ABORTING))+","+
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_ABORTINGFORRESTART))+")
> FOR UPDATE",null,null,null);
> database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+"
> FOR UPDATE",null,null,null);
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_UNINSTALLED))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_UNINSTALLED))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_NOOUTPUT))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_NOOUTPUT))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_NEITHER))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_NEITHER))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))+","+
> database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))+")";
> Jobs.statusField+"="+database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_INACTIVE))+"
> AND "+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVE))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCAN))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDING))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVEPURGATORY))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDINGPURGATORY))+")"+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_COMPLETE))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PURGATORY))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVEPURGATORY))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
> database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDINGPURGATORY))+")"+
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING))).append("
> THEN 'Not yet processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append("
> THEN 'Not yet processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append("
> THEN 'Not yet processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append("
> THEN 'Processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append("
> THEN 'Processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append("
> THEN 'Processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append("
> THEN 'Processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append("
> THEN 'Processed'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))).append("
> THEN 'Being removed'")
> .append("(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
> .append(" AND (t0.").append(jobQueue.checkActionField).append("
> IS NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND (t0.").append(jobQueue.checkActionField).append("
> IS NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" WHEN
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
> .append("(t0.").append(jobQueue.checkActionField).append(" IS
> NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append("t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(" OR
> ").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(" WHEN
> ").append("(t0.").append(jobQueue.checkActionField).append(" IS NULL
> OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")
> THEN 'Process'")
> .append(" WHEN
> ").append("t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE))).append("
> THEN 'Expire'")
> .append("(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
> .append("(").append(jobQueue.checkActionField).append(" IS NULL
> OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
> .append(" AND (").append(jobQueue.checkActionField).append(" IS
> NULL OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND (").append(jobQueue.checkActionField).append(" IS
> NULL OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> (").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(" OR
> ").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> sb.append(database.constructSubstringClause(columnPrefix+columnName,database.quoteSQLString(bucketDesc.getRegexp()),!isSensitive));
> sb.append(database.constructRegexpClause(fieldPrefix+jobQueue.docIDField,database.quoteSQLString(identifierRegexp.getRegexpString()),identifierRegexp.isInsensitive()));
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(" AND
> (").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
> NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")");
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
> .append(" AND
> ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)));
> sb.append(fieldPrefix).append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)));
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> (").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
> NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> (").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
> NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> .append(" AND
> ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
> .append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
> .append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/HopCount.java
> commonNewExpression =
> intrinsicLinkManager.newField+"="+quoteSQLString(intrinsicLinkManager.statusToString(intrinsicLinkManager.LINKSTATUS_BASE));
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobQueue.java
> quoteSQLString(statusToString(STATUS_PENDING)),list);
> quoteSQLString(statusToString(STATUS_PENDING)),list,null);
> quoteSQLString(statusToString(STATUS_PENDINGPURGATORY))+","+
> quoteSQLString(statusToString(STATUS_COMPLETE))+")",list,null);
> quoteSQLString(statusToString(STATUS_COMPLETE)),list,null);
> quoteSQLString(statusToString(STATUS_ACTIVE))+","+
> quoteSQLString(statusToString(STATUS_ACTIVEPURGATORY))+","+
> quoteSQLString(statusToString(STATUS_ACTIVENEEDRESCAN))+","+
> quoteSQLString(statusToString(STATUS_ACTIVENEEDRESCANPURGATORY))+")
> "+constructOffsetLimitClause(0,1),list,null,null,1);
> ./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/repository/RepositoryHistoryManager.java
> sb.append(constructSubstringClause(columnPrefix+columnName,quoteSQLString(bucketDesc.getRegexp()),!isSensitive));
> sb.append(fieldPrefix).append(ownerNameField).append("=").append(quoteSQLString(connectionName));
> sb.append(quoteSQLString(activity));
> sb.append(constructRegexpClause(fieldPrefix+entityIdentifierField,quoteSQLString(entityMatch.getRegexpString()),entityMatch.isInsensitive()));
> sb.append(constructRegexpClause(fieldPrefix+resultCodeField,quoteSQLString(resultCodeMatch.getRegexpString()),resultCodeMatch.isInsensitive()));
> <<<<<<
>
> The abstractions that require a quote string argument as input are:
> - constructSubstringClause
> - constructRegexpClause
>
> These can, of course, be redefined to work by using parameterized
> queries, but doing so limits their flexibility as abstractions
> considerably, so I'd rather not do that unless it was actually shown
> that quoteSQLString is not or could not be made safe.
>
> The case I will change involves the last file:
> RepositoryHistoryManager, which as you see quotes a connection name
> and an activity name.
>
> Karl
>
>
> On Mon, Dec 6, 2010 at 7:45 PM, Karl Wright <da...@gmail.com> wrote:
>> quoteSQLString is used mainly for data content that is not directly
>> sourced from input, such as state values, etc. So your concern is
>> unlikely to be actually true. But even so, if you are saying that all
>> of these should be converted to prepared values, fine - but this would
>> be a large job and is likely to be error prone. Would it not be
>> better to address any concerns you might have about quoteSQLString
>> instead?
>>
>> Since quoteSQLString uses ' as it's quotation mark, and properly
>> escapes ' characters within the string, I claim that the method is
>> properly written and cannot be used for a sql attack. If you
>> disagree, provide me a string that "breaks" the escaping that it does.
>> The definition of such breakage is a string that, when escaped with
>> quoteSQLString, causes the query to interpret ANY of the string's
>> contents as something other than the string.
>>
>> The link you provided lists many kinds of exploit, most of them
>> fundamentally issues with (a) non-escaping of strings, and (b) taking
>> advantage of flaws in (say) PHP or ASP. ALL of them are thwarted by
>> proper escaping of character content.
>>
>> Karl
>>
>> On Mon, Dec 6, 2010 at 7:30 PM, Robert Muir <rc...@gmail.com> wrote:
>>> On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>>> As for the sql injection question, please elaborate. There is no UI
>>>> ability to do sql injection that I am aware of, because all the
>>>> strings you might enter are properly escaped before being incorporated
>>>> into queries. This includes queries that come via the API and
>>>> Authority Service. So I guess I need an example of how you might
>>>> cause a sql injection given the current code.
>>>>
>>>
>>> Escaping tends to only thwart casual attackers, not motivated ones or
>>> even automated tools.
>>>
>>> For example the escaping i see used here: e.g. quoteSQLString seems to
>>> only quote single-quote characters.
>>>
>>> There are a number of techniques to workaround this type of escaping,
>>> some are listed here:
>>> http://www.slideshare.net/inquis/sql-injection-not-only-and-11
>>>
>>> In my opinion all variables should be explicitly bound via PreparedStatements.
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Here is a list of the pertinent places where quoteSQLString is used.
Note that EXCEPT in a couple of cases where quoteSQLString was needed
to furnish an argument for a clause being formed by a database
abstraction method, ALL other cases are quoting of constant values,
save in one case, which I am happy to change.
>>>>>>
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/Jobs.java
getTableName()+" WHERE
"+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE))+
" AND "+statusField+"!="+quoteSQLString(statusToString(STATUS_READYFORDELETE_NOOUTPUT))+
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")",null,null,null);
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVESEEDING))+")
"+constructOffsetLimitClause(0,1),null,null,null,1);
statusField+" IN
("+quoteSQLString(statusToString(STATUS_READYFORDELETE))+","+
quoteSQLString(statusToString(STATUS_SHUTTINGDOWN))+")
"+constructOffsetLimitClause(0,1),
quoteSQLString(statusToString(STATUS_ACTIVE)) + "," +
quoteSQLString(statusToString(STATUS_ACTIVESEEDING)) +
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobManager.java
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))+
" AND
t1."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+
")) OR
(t0."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))+
" AND
t3."+jobs.statusField+"="+database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))+
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append(")
AND EXISTS(SELECT 'x' FROM ").append(jobs.getTableName()).append(" t1
WHERE t0.")
.append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_COMPLETE))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(JobQueue.STATUS_PURGATORY))).append(")")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_READYFORSTARTUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_STARTINGUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUPFORRESTART))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGSTARTINGUP))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTING))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTART))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ABORTINGFORRESTARTSEEDING))).append("))
AND ")
.append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDING))).append(",")
.append(database.quoteSQLString(JobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append(")
AND (")
.append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(JobQueue.ACTION_RESCAN)))
.append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))).append(")
AND ");
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
.append(database.quoteSQLString(Jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(Jobs.statusToString(jobs.STATUS_ACTIVESEEDING)))
.append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))).append(")
AND t1.")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append(",")
.append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
database.quoteSQLString(jobs.statusToString(jobs.STATUS_INACTIVE))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAIT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAITSEEDING))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDWAIT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDWAITSEEDING))+")
AND "+
jobs.startMethodField+"!="+database.quoteSQLString(jobs.startMethodToString(IJobDescription.START_DISABLE))+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_UNINSTALLED))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_UNINSTALLED))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NOOUTPUT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_NOOUTPUT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NEITHER))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVESEEDING_NEITHER))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSED))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_PAUSEDSEEDING))+")
AND "+
"t99."+jobQueue.statusField+"="+database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)),
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+"
AND "+
jobs.typeField+"="+database.quoteSQLString(jobs.typeToString(jobs.TYPE_CONTINUOUS))+"
AND ("+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORSTARTUP))+"
FOR UPDATE",null,null,null);
database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_READYFORDELETE_NOOUTPUT))+")
FOR UPDATE",null,null,null);
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVEWAIT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_UNINSTALLED))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NOOUTPUT))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ACTIVE_NEITHER))+")
FOR UPDATE",null,null,null);
database.quoteSQLString(jobs.statusToString(jobs.STATUS_NOTIFYINGOFCOMPLETION)),null,null,null);
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ABORTING))+","+
database.quoteSQLString(jobs.statusToString(jobs.STATUS_ABORTINGFORRESTART))+")
FOR UPDATE",null,null,null);
database.quoteSQLString(jobs.statusToString(jobs.STATUS_SHUTTINGDOWN))+"
FOR UPDATE",null,null,null);
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_UNINSTALLED))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_UNINSTALLED))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_NOOUTPUT))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_NOOUTPUT))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVE_NEITHER))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVESEEDING_NEITHER))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSED))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDSEEDING))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAIT))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_ACTIVEWAITSEEDING))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAIT))+","+
database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_PAUSEDWAITSEEDING))+")";
Jobs.statusField+"="+database.quoteSQLString(Jobs.statusToString(Jobs.STATUS_INACTIVE))+"
AND "+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVE))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCAN))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDING))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVEPURGATORY))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDINGPURGATORY))+")"+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_COMPLETE))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PURGATORY))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVEPURGATORY))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))+","+
database.quoteSQLString(JobQueue.statusToString(JobQueue.STATUS_PENDINGPURGATORY))+")"+
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING))).append("
THEN 'Not yet processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE))).append("
THEN 'Not yet processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN))).append("
THEN 'Not yet processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY))).append("
THEN 'Processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY))).append("
THEN 'Processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY))).append("
THEN 'Processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE))).append("
THEN 'Processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY))).append("
THEN 'Processed'")
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED))).append("
THEN 'Being removed'")
.append("(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
.append(" AND (t0.").append(jobQueue.checkActionField).append("
IS NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND (t0.").append(jobQueue.checkActionField).append("
IS NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" WHEN
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
.append("(t0.").append(jobQueue.checkActionField).append(" IS
NULL OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append("t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(" OR
").append("t0.").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(" WHEN
").append("(t0.").append(jobQueue.checkActionField).append(" IS NULL
OR t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")
THEN 'Process'")
.append(" WHEN
").append("t0.").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE))).append("
THEN 'Expire'")
.append("(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
.append("(").append(jobQueue.checkActionField).append(" IS NULL
OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
.append(" AND (").append(jobQueue.checkActionField).append(" IS
NULL OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND (").append(jobQueue.checkActionField).append(" IS
NULL OR ").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
").append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
(").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(" OR
").append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
sb.append(database.constructSubstringClause(columnPrefix+columnName,database.quoteSQLString(bucketDesc.getRegexp()),!isSensitive));
sb.append(database.constructRegexpClause(fieldPrefix+jobQueue.docIDField,database.quoteSQLString(identifierRegexp.getRegexpString()),identifierRegexp.isInsensitive()));
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_COMPLETE)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PURGATORY)))
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(" AND
(").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")");
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVE)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCAN)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVEPURGATORY)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_ACTIVENEEDRESCANPURGATORY)))
.append(" AND
").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)));
sb.append(fieldPrefix).append(jobQueue.statusField).append("=").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_BEINGDELETED)));
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
(").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
(").append(fieldPrefix).append(jobQueue.checkActionField).append(" IS
NULL OR ").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_RESCAN))).append(")")
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
.append(" AND
").append(fieldPrefix).append(jobQueue.checkActionField).append("=").append(database.quoteSQLString(jobQueue.actionToString(jobQueue.ACTION_REMOVE)))
.append("(").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDING)))
.append(",").append(database.quoteSQLString(jobQueue.statusToString(jobQueue.STATUS_PENDINGPURGATORY)))
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/HopCount.java
commonNewExpression =
intrinsicLinkManager.newField+"="+quoteSQLString(intrinsicLinkManager.statusToString(intrinsicLinkManager.LINKSTATUS_BASE));
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/jobs/JobQueue.java
quoteSQLString(statusToString(STATUS_PENDING)),list);
quoteSQLString(statusToString(STATUS_PENDING)),list,null);
quoteSQLString(statusToString(STATUS_PENDINGPURGATORY))+","+
quoteSQLString(statusToString(STATUS_COMPLETE))+")",list,null);
quoteSQLString(statusToString(STATUS_COMPLETE)),list,null);
quoteSQLString(statusToString(STATUS_ACTIVE))+","+
quoteSQLString(statusToString(STATUS_ACTIVEPURGATORY))+","+
quoteSQLString(statusToString(STATUS_ACTIVENEEDRESCAN))+","+
quoteSQLString(statusToString(STATUS_ACTIVENEEDRESCANPURGATORY))+")
"+constructOffsetLimitClause(0,1),list,null,null,1);
./framework/pull-agent/src/main/java/org/apache/manifoldcf/crawler/repository/RepositoryHistoryManager.java
sb.append(constructSubstringClause(columnPrefix+columnName,quoteSQLString(bucketDesc.getRegexp()),!isSensitive));
sb.append(fieldPrefix).append(ownerNameField).append("=").append(quoteSQLString(connectionName));
sb.append(quoteSQLString(activity));
sb.append(constructRegexpClause(fieldPrefix+entityIdentifierField,quoteSQLString(entityMatch.getRegexpString()),entityMatch.isInsensitive()));
sb.append(constructRegexpClause(fieldPrefix+resultCodeField,quoteSQLString(resultCodeMatch.getRegexpString()),resultCodeMatch.isInsensitive()));
<<<<<<
The abstractions that require a quote string argument as input are:
- constructSubstringClause
- constructRegexpClause
These can, of course, be redefined to work by using parameterized
queries, but doing so limits their flexibility as abstractions
considerably, so I'd rather not do that unless it was actually shown
that quoteSQLString is not or could not be made safe.
The case I will change involves the last file:
RepositoryHistoryManager, which as you see quotes a connection name
and an activity name.
Karl
On Mon, Dec 6, 2010 at 7:45 PM, Karl Wright <da...@gmail.com> wrote:
> quoteSQLString is used mainly for data content that is not directly
> sourced from input, such as state values, etc. So your concern is
> unlikely to be actually true. But even so, if you are saying that all
> of these should be converted to prepared values, fine - but this would
> be a large job and is likely to be error prone. Would it not be
> better to address any concerns you might have about quoteSQLString
> instead?
>
> Since quoteSQLString uses ' as it's quotation mark, and properly
> escapes ' characters within the string, I claim that the method is
> properly written and cannot be used for a sql attack. If you
> disagree, provide me a string that "breaks" the escaping that it does.
> The definition of such breakage is a string that, when escaped with
> quoteSQLString, causes the query to interpret ANY of the string's
> contents as something other than the string.
>
> The link you provided lists many kinds of exploit, most of them
> fundamentally issues with (a) non-escaping of strings, and (b) taking
> advantage of flaws in (say) PHP or ASP. ALL of them are thwarted by
> proper escaping of character content.
>
> Karl
>
> On Mon, Dec 6, 2010 at 7:30 PM, Robert Muir <rc...@gmail.com> wrote:
>> On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright <da...@gmail.com> wrote:
>>
>>> As for the sql injection question, please elaborate. There is no UI
>>> ability to do sql injection that I am aware of, because all the
>>> strings you might enter are properly escaped before being incorporated
>>> into queries. This includes queries that come via the API and
>>> Authority Service. So I guess I need an example of how you might
>>> cause a sql injection given the current code.
>>>
>>
>> Escaping tends to only thwart casual attackers, not motivated ones or
>> even automated tools.
>>
>> For example the escaping i see used here: e.g. quoteSQLString seems to
>> only quote single-quote characters.
>>
>> There are a number of techniques to workaround this type of escaping,
>> some are listed here:
>> http://www.slideshare.net/inquis/sql-injection-not-only-and-11
>>
>> In my opinion all variables should be explicitly bound via PreparedStatements.
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
quoteSQLString is used mainly for data content that is not directly
sourced from input, such as state values, etc. So your concern is
unlikely to be actually true. But even so, if you are saying that all
of these should be converted to prepared values, fine - but this would
be a large job and is likely to be error prone. Would it not be
better to address any concerns you might have about quoteSQLString
instead?
Since quoteSQLString uses ' as it's quotation mark, and properly
escapes ' characters within the string, I claim that the method is
properly written and cannot be used for a sql attack. If you
disagree, provide me a string that "breaks" the escaping that it does.
The definition of such breakage is a string that, when escaped with
quoteSQLString, causes the query to interpret ANY of the string's
contents as something other than the string.
The link you provided lists many kinds of exploit, most of them
fundamentally issues with (a) non-escaping of strings, and (b) taking
advantage of flaws in (say) PHP or ASP. ALL of them are thwarted by
proper escaping of character content.
Karl
On Mon, Dec 6, 2010 at 7:30 PM, Robert Muir <rc...@gmail.com> wrote:
> On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright <da...@gmail.com> wrote:
>
>> As for the sql injection question, please elaborate. There is no UI
>> ability to do sql injection that I am aware of, because all the
>> strings you might enter are properly escaped before being incorporated
>> into queries. This includes queries that come via the API and
>> Authority Service. So I guess I need an example of how you might
>> cause a sql injection given the current code.
>>
>
> Escaping tends to only thwart casual attackers, not motivated ones or
> even automated tools.
>
> For example the escaping i see used here: e.g. quoteSQLString seems to
> only quote single-quote characters.
>
> There are a number of techniques to workaround this type of escaping,
> some are listed here:
> http://www.slideshare.net/inquis/sql-injection-not-only-and-11
>
> In my opinion all variables should be explicitly bound via PreparedStatements.
>
Re: Release?
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright <da...@gmail.com> wrote:
> As for the sql injection question, please elaborate. There is no UI
> ability to do sql injection that I am aware of, because all the
> strings you might enter are properly escaped before being incorporated
> into queries. This includes queries that come via the API and
> Authority Service. So I guess I need an example of how you might
> cause a sql injection given the current code.
>
Escaping tends to only thwart casual attackers, not motivated ones or
even automated tools.
For example the escaping i see used here: e.g. quoteSQLString seems to
only quote single-quote characters.
There are a number of techniques to workaround this type of escaping,
some are listed here:
http://www.slideshare.net/inquis/sql-injection-not-only-and-11
In my opinion all variables should be explicitly bound via PreparedStatements.
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
If by third-party, you mean code from Documentum, LiveLink, etc, I
don't actually think we have any third-party dependencies that we
ship. Remember that the compilation is all conditional, so if you
want these connectors you need to drop the right things in the right
places, using your own license to these materials, and then build.
That's all explained in
http://incubator.apache.org/connectors/how-to-build-and-deploy.html.
As for the sql injection question, please elaborate. There is no UI
ability to do sql injection that I am aware of, because all the
strings you might enter are properly escaped before being incorporated
into queries. This includes queries that come via the API and
Authority Service. So I guess I need an example of how you might
cause a sql injection given the current code.
Karl
On Mon, Dec 6, 2010 at 7:12 PM, Robert Muir <rc...@gmail.com> wrote:
> i took a quick look, i definitely agree we need to document all 3rd
> party dependencies in notice.txt and include licenses with them.
>
> separately, i have an additional concern, and that is i'm really
> concerned about a release going out with some of the database
> interface code looking very prone to sql injection attacks.
>
> On Mon, Dec 6, 2010 at 6:45 PM, Karl Wright <da...@gmail.com> wrote:
>> Robert has expressed a willingness to chip in on the remaining issues
>> later this week, when he's no longer being buried alive.
>> Thanks, Robert!
>> Karl
>>
>> On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright <da...@gmail.com> wrote:
>>> Ok, this too has been done.
>>> Still no takers for (2) and (3). Going thrice...
>>>
>>> Karl
>>>
>>>
>>> On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable.
>>>>
>>>> -Grant
>>>>
>>>> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote:
>>>>
>>>>> Does this also apply to the top-level directory in the tar or zip as
>>>>> well? or can that be left as "apache-manifoldcf-0.1"?
>>>>>
>>>>> Karl
>>>>>
>>>>> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>>>>>>
>>>>>> -Grant
>>>>>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>>>>>>
>>>>>>> ... going twice ...
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>>>>>>> (3)... going once....
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>>>>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Grant,
>>>>>>>>>>>
>>>>>>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>>>>>>> changes in the release branch only?
>>>>>>>>>>
>>>>>>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>>>>>>
>>>>>>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>>>>>>
>>>>>>>>>>>> Notes:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>>>>>>> 6. What's json/org/json all about?
>>>>>>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>>>>>>
>>>>>>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>>>>>>
>>>>>>>>>>>> -Grant
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Done
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>> ok - I might move it there
>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Grant
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>>>>>>> another way.
>>>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------
>>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------
>>>>>>>>>> Grant Ingersoll
>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> Grant Ingersoll
>>>>>> http://www.lucidimagination.com/
>>>>>>
>>>>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>>>>> http://www.lucidimagination.com/search
>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com/
>>>>
>>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>>> http://www.lucidimagination.com/search
>>>>
>>>>
>>>
>>
>
Re: Release?
Posted by Robert Muir <rc...@gmail.com>.
i took a quick look, i definitely agree we need to document all 3rd
party dependencies in notice.txt and include licenses with them.
separately, i have an additional concern, and that is i'm really
concerned about a release going out with some of the database
interface code looking very prone to sql injection attacks.
On Mon, Dec 6, 2010 at 6:45 PM, Karl Wright <da...@gmail.com> wrote:
> Robert has expressed a willingness to chip in on the remaining issues
> later this week, when he's no longer being buried alive.
> Thanks, Robert!
> Karl
>
> On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright <da...@gmail.com> wrote:
>> Ok, this too has been done.
>> Still no takers for (2) and (3). Going thrice...
>>
>> Karl
>>
>>
>> On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable.
>>>
>>> -Grant
>>>
>>> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote:
>>>
>>>> Does this also apply to the top-level directory in the tar or zip as
>>>> well? or can that be left as "apache-manifoldcf-0.1"?
>>>>
>>>> Karl
>>>>
>>>> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>>>>>
>>>>> -Grant
>>>>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>>>>>
>>>>>> ... going twice ...
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>>>>>> (3)... going once....
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>>>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>>>>>
>>>>>>>>>> Hi Grant,
>>>>>>>>>>
>>>>>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>>>>>> changes in the release branch only?
>>>>>>>>>
>>>>>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>>>>>
>>>>>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>>>>>
>>>>>>>>>>> Notes:
>>>>>>>>>>>
>>>>>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>>>>>> 6. What's json/org/json all about?
>>>>>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>>>>>
>>>>>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>>>>>
>>>>>>>>>>> -Grant
>>>>>>>>>>>
>>>>>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Done
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>> ok - I might move it there
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Grant
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>>>>>> another way.
>>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --------------------------
>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------
>>>>>>>>> Grant Ingersoll
>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com/
>>>>>
>>>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>>>> http://www.lucidimagination.com/search
>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com/
>>>
>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>> http://www.lucidimagination.com/search
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Robert has expressed a willingness to chip in on the remaining issues
later this week, when he's no longer being buried alive.
Thanks, Robert!
Karl
On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright <da...@gmail.com> wrote:
> Ok, this too has been done.
> Still no takers for (2) and (3). Going thrice...
>
> Karl
>
>
> On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable.
>>
>> -Grant
>>
>> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote:
>>
>>> Does this also apply to the top-level directory in the tar or zip as
>>> well? or can that be left as "apache-manifoldcf-0.1"?
>>>
>>> Karl
>>>
>>> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>>>>
>>>> -Grant
>>>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>>>>
>>>>> ... going twice ...
>>>>>
>>>>> Karl
>>>>>
>>>>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>>>>> (3)... going once....
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>>>>
>>>>>>>>> Hi Grant,
>>>>>>>>>
>>>>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>>>>> changes in the release branch only?
>>>>>>>>
>>>>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>>>>
>>>>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>>>>
>>>>>>>>>> Notes:
>>>>>>>>>>
>>>>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>>>>> 6. What's json/org/json all about?
>>>>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>>>>
>>>>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>>>>
>>>>>>>>>> -Grant
>>>>>>>>>>
>>>>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>>>>
>>>>>>>>>>> Done
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>> ok - I might move it there
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>>>>
>>>>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Grant
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>>>>> another way.
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------
>>>>>>>>>> Grant Ingersoll
>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------
>>>>>>>> Grant Ingersoll
>>>>>>>> http://www.lucidimagination.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com/
>>>>
>>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>>> http://www.lucidimagination.com/search
>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem docs using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Ok, this too has been done.
Still no takers for (2) and (3). Going thrice...
Karl
On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable.
>
> -Grant
>
> On Dec 6, 2010, at 3:10 PM, Karl Wright wrote:
>
>> Does this also apply to the top-level directory in the tar or zip as
>> well? or can that be left as "apache-manifoldcf-0.1"?
>>
>> Karl
>>
>> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>>>
>>> -Grant
>>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>>>
>>>> ... going twice ...
>>>>
>>>> Karl
>>>>
>>>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>>>> (3)... going once....
>>>>>
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>
>>>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>>>
>>>>>>>> Hi Grant,
>>>>>>>>
>>>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>>>> changes in the release branch only?
>>>>>>>
>>>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>>>
>>>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>>>
>>>>>>>>> Notes:
>>>>>>>>>
>>>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>>>> 6. What's json/org/json all about?
>>>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>>>
>>>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>>>
>>>>>>>>> -Grant
>>>>>>>>>
>>>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>>>
>>>>>>>>>> Done
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>> ok - I might move it there
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>>>
>>>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>>>
>>>>>>>>>>>> -Grant
>>>>>>>>>>>>
>>>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>>>
>>>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>>>> another way.
>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------
>>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------
>>>>>>>>> Grant Ingersoll
>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> Grant Ingersoll
>>>>>>> http://www.lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com/
>>>
>>> Search the Lucene ecosystem docs using Solr/Lucene:
>>> http://www.lucidimagination.com/search
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem docs using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable.
-Grant
On Dec 6, 2010, at 3:10 PM, Karl Wright wrote:
> Does this also apply to the top-level directory in the tar or zip as
> well? or can that be left as "apache-manifoldcf-0.1"?
>
> Karl
>
> On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>>
>> -Grant
>> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>>
>>> ... going twice ...
>>>
>>> Karl
>>>
>>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>>> (3)... going once....
>>>>
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>
>>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>>
>>>>>>> Hi Grant,
>>>>>>>
>>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>>> changes in the release branch only?
>>>>>>
>>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>>
>>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>>> 6. What's json/org/json all about?
>>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>>
>>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>>
>>>>>>>> -Grant
>>>>>>>>
>>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>>
>>>>>>>>> Done
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>> ok - I might move it there
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>>
>>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>>
>>>>>>>>>>> -Grant
>>>>>>>>>>>
>>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>>
>>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>>
>>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>>
>>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>>> another way.
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --------------------------
>>>>>>>>>>> Grant Ingersoll
>>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------
>>>>>>>> Grant Ingersoll
>>>>>>>> http://www.lucidimagination.com
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> Grant Ingersoll
>>>>>> http://www.lucidimagination.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem docs using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Does this also apply to the top-level directory in the tar or zip as
well? or can that be left as "apache-manifoldcf-0.1"?
Karl
On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll <gs...@apache.org> wrote:
> FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
>
> -Grant
> On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
>
>> ... going twice ...
>>
>> Karl
>>
>> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>>> (3)... going once....
>>>
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>
>>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>>> You also seem to be asking for a number of other fixes that are
>>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>>> changes in the release branch only?
>>>>>
>>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>>
>>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>>
>>>>>
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>>> 6. What's json/org/json all about?
>>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>>
>>>>>>> Other than that, some other eyes on it would be good.
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>>
>>>>>>>> Done
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> ok - I might move it there
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>>
>>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>>
>>>>>>>>>> -Grant
>>>>>>>>>>
>>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>>
>>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>>
>>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>>
>>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>>
>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>>> another way.
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------
>>>>>>>>>> Grant Ingersoll
>>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> Grant Ingersoll
>>>>>>> http://www.lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com
>>>>>
>>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem docs using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz
-Grant
On Dec 6, 2010, at 8:55 AM, Karl Wright wrote:
> ... going twice ...
>
> Karl
>
> On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
>> I'm done with (1), (4), and (5). Still waiting for help with (2) and
>> (3)... going once....
>>
>> Karl
>>
>> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>>> OK, so I will do the appropriate things to make (1), (4), and maybe
>>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>
>>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>>
>>>>> Hi Grant,
>>>>>
>>>>> In offline conversation you clarified that for (1) you are looking for
>>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>>> You also seem to be asking for a number of other fixes that are
>>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>>> changes in the release branch only?
>>>>
>>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>>
>>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>>
>>>>
>>>>>
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>>> 6. What's json/org/json all about?
>>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>>
>>>>>> Other than that, some other eyes on it would be good.
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>>
>>>>>>> Done
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> ok - I might move it there
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>>
>>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>>
>>>>>>>>> -Grant
>>>>>>>>>
>>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>>
>>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>>
>>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>>
>>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>>
>>>>>>>>>> Please let me know what you think.
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>>> another way.
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------
>>>>>>>>> Grant Ingersoll
>>>>>>>>> http://www.lucidimagination.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> Grant Ingersoll
>>>>>> http://www.lucidimagination.com
>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
... going twice ...
Karl
On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright <da...@gmail.com> wrote:
> I'm done with (1), (4), and (5). Still waiting for help with (2) and
> (3)... going once....
>
> Karl
>
> On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
>> OK, so I will do the appropriate things to make (1), (4), and maybe
>> (5) happen. Does anyone want to help with (2), (3), and (8)?
>> Karl
>>
>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>
>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>
>>>> Hi Grant,
>>>>
>>>> In offline conversation you clarified that for (1) you are looking for
>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>> You also seem to be asking for a number of other fixes that are
>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>>> changes in the release branch only?
>>>
>>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>>
>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>>
>>>
>>>>
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>>
>>>>> Notes:
>>>>>
>>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>>> 6. What's json/org/json all about?
>>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>>
>>>>> Other than that, some other eyes on it would be good.
>>>>>
>>>>> -Grant
>>>>>
>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>
>>>>>> Done
>>>>>> Karl
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> ok - I might move it there
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>>
>>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>>
>>>>>>>> -Grant
>>>>>>>>
>>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>>
>>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>>
>>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>>
>>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>>
>>>>>>>>> Please let me know what you think.
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>>> another way.
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------
>>>>>>>> Grant Ingersoll
>>>>>>>> http://www.lucidimagination.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com
>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I'm done with (1), (4), and (5). Still waiting for help with (2) and
(3)... going once....
Karl
On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright <da...@gmail.com> wrote:
> OK, so I will do the appropriate things to make (1), (4), and maybe
> (5) happen. Does anyone want to help with (2), (3), and (8)?
> Karl
>
> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>
>>> Hi Grant,
>>>
>>> In offline conversation you clarified that for (1) you are looking for
>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>> You also seem to be asking for a number of other fixes that are
>>> specific to a release, that I presume would NOT be in sources on trunk
>>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>>> changes in the release branch only?
>>
>> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>>
>> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>>
>>
>>>
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>>
>>>> Notes:
>>>>
>>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>>> 6. What's json/org/json all about?
>>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>>
>>>> Other than that, some other eyes on it would be good.
>>>>
>>>> -Grant
>>>>
>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>
>>>>> Done
>>>>> Karl
>>>>>
>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>> ok - I might move it there
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>>
>>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>>
>>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>>
>>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>>
>>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>>> [kwright@minotaur:~]$
>>>>>>>>
>>>>>>>> Please let me know what you think.
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>>> another way.
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> Grant Ingersoll
>>>>>>> http://www.lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
OK, so I will do the appropriate things to make (1), (4), and maybe
(5) happen. Does anyone want to help with (2), (3), and (8)?
Karl
On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>
>> Hi Grant,
>>
>> In offline conversation you clarified that for (1) you are looking for
>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>> You also seem to be asking for a number of other fixes that are
>> specific to a release, that I presume would NOT be in sources on trunk
>> (e.g. CHANGES.txt). Are you envisioning that we make these specific
>> changes in the release branch only?
>
> It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
>
> Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>
>
>>
>> Karl
>>
>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>>
>>> Notes:
>>>
>>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>>> 2. Many of the libs require an entry in the NOTICE.txt file
>>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>>> 6. What's json/org/json all about?
>>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>>
>>> Other than that, some other eyes on it would be good.
>>>
>>> -Grant
>>>
>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>
>>>> Done
>>>> Karl
>>>>
>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> ok - I might move it there
>>>>> Karl
>>>>>
>>>>>
>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>>
>>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>>
>>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>>
>>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>>
>>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>>> [kwright@minotaur:~]$
>>>>>>>
>>>>>>> Please let me know what you think.
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>>> another way.
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> Grant Ingersoll
>>>>>> http://www.lucidimagination.com
>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
> Hi Grant,
>
> In offline conversation you clarified that for (1) you are looking for
> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
> You also seem to be asking for a number of other fixes that are
> specific to a release, that I presume would NOT be in sources on trunk
> (e.g. CHANGES.txt). Are you envisioning that we make these specific
> changes in the release branch only?
It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again.
Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release.
>
> Karl
>
> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> We're close, but I think we've got a few more things to do. I did get it to compile.
>>
>> Notes:
>>
>> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
>> 2. Many of the libs require an entry in the NOTICE.txt file
>> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
>> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
>> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
>> 6. What's json/org/json all about?
>> 7. I still see Memex stuff in connectors dir. I didn't check other places.
>> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>>
>> Other than that, some other eyes on it would be good.
>>
>> -Grant
>>
>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>
>>> Done
>>> Karl
>>>
>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>>> ok - I might move it there
>>>> Karl
>>>>
>>>>
>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>>
>>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>>
>>>>> -Grant
>>>>>
>>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>>
>>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>>
>>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>>
>>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>>> [kwright@minotaur:~]$
>>>>>>
>>>>>> Please let me know what you think.
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>>> another way.
>>>>>>> Karl
>>>>>>>
>>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --------------------------
>>>>> Grant Ingersoll
>>>>> http://www.lucidimagination.com
>>>>>
>>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Hi Grant,
In offline conversation you clarified that for (1) you are looking for
the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
You also seem to be asking for a number of other fixes that are
specific to a release, that I presume would NOT be in sources on trunk
(e.g. CHANGES.txt). Are you envisioning that we make these specific
changes in the release branch only?
Karl
On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <gs...@apache.org> wrote:
> We're close, but I think we've got a few more things to do. I did get it to compile.
>
> Notes:
>
> 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
> 2. Many of the libs require an entry in the NOTICE.txt file
> 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
> 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
> 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
> 6. What's json/org/json all about?
> 7. I still see Memex stuff in connectors dir. I didn't check other places.
> 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
>
> Other than that, some other eyes on it would be good.
>
> -Grant
>
> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>
>> Done
>> Karl
>>
>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>>> ok - I might move it there
>>> Karl
>>>
>>>
>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>>
>>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>>
>>>> -Grant
>>>>
>>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>>
>>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>>
>>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>>
>>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>>> [kwright@minotaur:~]$
>>>>>
>>>>> Please let me know what you think.
>>>>> Karl
>>>>>
>>>>>
>>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>>> another way.
>>>>>> Karl
>>>>>>
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --------------------------
>>>> Grant Ingersoll
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
We're close, but I think we've got a few more things to do. I did get it to compile.
Notes:
1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder.
2. Many of the libs require an entry in the NOTICE.txt file
3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance)
4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix)
5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim?
6. What's json/org/json all about?
7. I still see Memex stuff in connectors dir. I didn't check other places.
8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers
Other than that, some other eyes on it would be good.
-Grant
On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
> Done
> Karl
>
> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>> ok - I might move it there
>> Karl
>>
>>
>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>
>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>
>>> -Grant
>>>
>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>
>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>
>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>
>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>> [kwright@minotaur:~]$
>>>>
>>>> Please let me know what you think.
>>>> Karl
>>>>
>>>>
>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>> another way.
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
Never mind.
On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
> Done
> Karl
>
> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
>> ok - I might move it there
>> Karl
>>
>>
>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>>
>>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>>
>>> -Grant
>>>
>>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>>
>>>> While I was looking for a solution, an upload attempt succeeded!
>>>>
>>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>>
>>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>>> [kwright@minotaur:~]$
>>>>
>>>> Please let me know what you think.
>>>> Karl
>>>>
>>>>
>>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>>> another way.
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>>> <ja...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --------------------------
>>> Grant Ingersoll
>>> http://www.lucidimagination.com
>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Done
Karl
On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <da...@gmail.com> wrote:
> ok - I might move it there
> Karl
>
>
> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>>
>> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>>
>> -Grant
>>
>> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>>
>>> While I was looking for a solution, an upload attempt succeeded!
>>>
>>> So there is now an RC0 out on people.apache.org/~kwright:
>>>
>>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>>> [kwright@minotaur:~]$
>>>
>>> Please let me know what you think.
>>> Karl
>>>
>>>
>>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>>> another way.
>>>> Karl
>>>>
>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <ja...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
ok - I might move it there
Karl
On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
>
> FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
>
> -Grant
>
> On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
>
>> While I was looking for a solution, an upload attempt succeeded!
>>
>> So there is now an RC0 out on people.apache.org/~kwright:
>>
>> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
>> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
>> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
>> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
>> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
>> [kwright@minotaur:~]$
>>
>> Please let me know what you think.
>> Karl
>>
>>
>> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>>> The upload has failed repeatedly for me, so I'll clearly have to find
>>> another way.
>>> Karl
>>>
>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>> <ja...@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
>>>>>
>>>>>
>>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright
FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/
-Grant
On Nov 23, 2010, at 1:00 PM, Karl Wright wrote:
> While I was looking for a solution, an upload attempt succeeded!
>
> So there is now an RC0 out on people.apache.org/~kwright:
>
> [kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
> -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
> -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
> -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
> -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
> [kwright@minotaur:~]$
>
> Please let me know what you think.
> Karl
>
>
> On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
>> The upload has failed repeatedly for me, so I'll clearly have to find
>> another way.
>> Karl
>>
>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>>> 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 <gs...@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 <da...@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 <da...@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
>>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>>> <ja...@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
>>>>>>>>>>>> <ja...@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
>>>>>>>>>>>>> <ja...@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
>>>>
>>>>
>>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
While I was looking for a solution, an upload attempt succeeded!
So there is now an RC0 out on people.apache.org/~kwright:
[kwright@minotaur:~]$ ls -lt manifoldcf-0.1.*
-rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5
-rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5
-rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip
-rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz
[kwright@minotaur:~]$
Please let me know what you think.
Karl
On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <da...@gmail.com> wrote:
> The upload has failed repeatedly for me, so I'll clearly have to find
> another way.
> Karl
>
> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
>> 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 <gs...@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 <da...@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 <da...@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
>>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>>> <ja...@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
>>>>>>>>>>> <ja...@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
>>>>>>>>>>>> <ja...@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
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
The upload has failed repeatedly for me, so I'll clearly have to find
another way.
Karl
On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <da...@gmail.com> wrote:
> 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 <gs...@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 <da...@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 <da...@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
>>>>> general@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 <da...@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 <gs...@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
>>>>>>>>> <ja...@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
>>>>>>>>>> <ja...@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
>>>>>>>>>>> <ja...@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
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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 <gs...@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 <da...@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 <da...@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
>>>> general@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 <da...@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 <gs...@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
>>>>>>>> <ja...@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
>>>>>>>>> <ja...@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
>>>>>>>>>> <ja...@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
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
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 <da...@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 <da...@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
>>> general@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 <da...@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 <gs...@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
>>>>>>> <ja...@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
>>>>>>>> <ja...@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
>>>>>>>>> <ja...@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
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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.
Last remaining release issue is getting the release files to a
download mirror. Maybe I can find some doc for that too.
Karl
On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright <da...@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 <da...@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
>> general@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 <da...@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 <gs...@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
>>>>>> <ja...@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
>>>>>>> <ja...@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
>>>>>>>> <ja...@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
>>>>
>>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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
> general@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 <da...@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 <gs...@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
>>>>> <ja...@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
>>>>>> <ja...@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
>>>>>>> <ja...@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
>>>
>>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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
> general@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 <da...@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 <gs...@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
>>>>> <ja...@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
>>>>>> <ja...@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
>>>>>>> <ja...@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
>>>
>>>
>>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
On Nov 17, 2010, at 9:50 PM, Karl Wright 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
> general@incubator.org - is that actually necessary?
Yes, we first vote here, Project PMC votes are binding and then we ask for a vote on general.
> (4) Release branch and tag. Do we want both? What is the correct
> naming for each in apache?
I would just tag, but I would wait to do it until the vote passes to save yourself some work. I doubt we need to branch since we won't be releasing bug fixes for a 0.1 release but will instead just point people to 0.2, etc.
> (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.
yes.
>
> Thanks,
> Karl
>
> On Tue, Nov 16, 2010 at 5:44 PM, Karl Wright <da...@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 <gs...@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
>>>>> <ja...@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
>>>>>> <ja...@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
>>>>>>> <ja...@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
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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
general@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 <da...@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 <gs...@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
>>>> <ja...@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
>>>>> <ja...@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
>>>>>> <ja...@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
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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 <gs...@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
>>> <ja...@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
>>>> <ja...@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
>>>>> <ja...@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
>
>
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
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
>> <ja...@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
>>> <ja...@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
>>>> <ja...@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
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Too late, it is done.
Karl
On Mon, Nov 15, 2010 at 1:23 PM, Jack Krupansky
<ja...@lucidimagination.com> 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.
>
> -- 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
>> <ja...@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
>>> <ja...@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
>>>> <ja...@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
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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
> <ja...@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
>> <ja...@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
>>> <ja...@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
Re: Release?
Posted by Grant Ingersoll <gs...@apache.org>.
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
> <ja...@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
>> <ja...@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
>>> <ja...@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
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
I've added a dist target to the ant build, which creates a zip and a
tar.gz. I didn't yet try to do a source.zip and source.tar.gz - I'm
looking for advice on that one, since there will be .svn files as well
as build directories in the source tree that all should be excluded.
Does anyone have a pointer to a decent way of doing this under ant?
Karl
On Wed, Nov 10, 2010 at 6:34 AM, Karl Wright <da...@gmail.com> wrote:
> According to Grant, nightly builds are unnecessary for a release process.
> A reliable release ant target IS necessary, so after a short comment
> period I'm happy to put that in.
>
> We can (and should) create both a release branch AND a release tag in
> SVN. For the Wiki, I know of no branch or release technology. If
> this, too, is to be branched, the content should be folded into the
> MCF site, which is in SVN and can thus be branched/released like
> everything else.
>
> That begs a broader question. At the moment I don't know how we'd
> handle multiple site versions. Ideally, we'd want to make the release
> # be part of the site URL. But Forrest's way of building sites is
> very unitary; it's not clear we could do it that way. Probably we
> could either structure things so that each release had its own Forrest
> site, with a main Forrest site that would link to each release site,
> or we'd have just one site that we modified to keep materials from
> each release around. Thoughts?
>
> Karl
>
> On Wed, Nov 10, 2010 at 1:22 AM, Jack Krupansky
> <ja...@lucidimagination.com> 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?
>>
>> 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
>> <ja...@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
>>> <ja...@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
>>>> <ja...@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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
According to Grant, nightly builds are unnecessary for a release process.
A reliable release ant target IS necessary, so after a short comment
period I'm happy to put that in.
We can (and should) create both a release branch AND a release tag in
SVN. For the Wiki, I know of no branch or release technology. If
this, too, is to be branched, the content should be folded into the
MCF site, which is in SVN and can thus be branched/released like
everything else.
That begs a broader question. At the moment I don't know how we'd
handle multiple site versions. Ideally, we'd want to make the release
# be part of the site URL. But Forrest's way of building sites is
very unitary; it's not clear we could do it that way. Probably we
could either structure things so that each release had its own Forrest
site, with a main Forrest site that would link to each release site,
or we'd have just one site that we modified to keep materials from
each release around. Thoughts?
Karl
On Wed, Nov 10, 2010 at 1:22 AM, Jack Krupansky
<ja...@lucidimagination.com> 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?
>
> 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
> <ja...@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
>> <ja...@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
>>> <ja...@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
>>>>
>>>
>>>
>>
>>
>
>
RE: Release?
Posted by ka...@nokia.com.
I've already raised the nightly build issue repeatedly. I don't have the resources or knowledge to set one up myself. Simon volunteered at one point, but then got busy. Grant said it was unnecessary.
Karl
________________________________________
From: ext Jack Krupansky [jack.krupansky@lucidimagination.com]
Sent: Wednesday, November 10, 2010 1:22 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?
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?
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
<ja...@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
> <ja...@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
>> <ja...@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
>>>
>>
>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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?
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
<ja...@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
> <ja...@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
>> <ja...@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
>>>
>>
>>
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
Ok - I moved the key bits of stuff that's in the wiki into the site,
and moved the site sources under trunk, so they can be branched and
tagged. All that remains from a release standpoint is adding the
source tar.gz and .zip to the outer-level build, I think. I should
probably also remove the Wiki pages that have been ported to forrest
to avoid confusion, as soon as the site actually updates.
Karl
On Mon, Nov 15, 2010 at 10:24 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> 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?
Posted by Grant Ingersoll <gs...@apache.org>.
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?
Posted by Karl Wright <da...@gmail.com>.
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
<ja...@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
> <ja...@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
>> <ja...@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
>>>
>>
>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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
<ja...@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
> <ja...@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
>>
>
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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
<ja...@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
> <ja...@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
>>
>
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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
<ja...@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
>
Re: Release?
Posted by Karl Wright <da...@gmail.com>.
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
<ja...@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
>
Re: Release?
Posted by Jack Krupansky <ja...@lucidimagination.com>.
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