manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: Release?
Date Fri, 10 Dec 2010 11:15:48 GMT
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).


On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <> 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 <> wrote:
>>> ok - I might move it there
>>> Karl
>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <> 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
>>>> -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
>>>>> [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
>>>>> -rw-r--r--  1 kwright  kwright  158734230 Nov 23 17:55
>>>>> -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 <>
>>>>>> The upload has failed repeatedly for me, so I'll clearly have to
>>>>>> another way.
>>>>>> Karl
>>>>>> On Tue, Nov 23, 2010 at 10:47 AM, Karl Wright <>
>>>>>>> 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
>>>>>>> candidate up there, if my network connection doesn't bounce in
>>>>>>> interim.  Is there any other place available?
>>>>>>> Karl
>>>>>>> On Fri, Nov 19, 2010 at 8:34 AM, Grant Ingersoll <>
>>>>>>>> On Nov 19, 2010, at 6:18 AM, Karl Wright wrote:
>>>>>>>>> I've created a signing key, and checked in a KEYS file.
>>>>>>>>> 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
>>>>>>>> Next steps would be to generate a candidate release which
the rest of us can download.  Put it up on 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 for more info.
>>>>>>>>> Karl
>>>>>>>>> On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright <>
>>>>>>>>>> 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 <>
>>>>>>>>>>> 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
>>>>>>>>>>> (3) Voting procedures for release.  I've seen
this done as a vote in
>>>>>>>>>>> - 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
<> 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
<> wrote:
>>>>>>>>>>>>> On Nov 15, 2010, at 1:23 PM, Jack Krupansky
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> To:
>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>> On Tue, Nov 9, 2010 at 10:22
AM, Jack Krupansky
>>>>>>>>>>>>>>> <>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> <>
>>>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> <>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>> Grant Ingersoll
>>>>>>>> --------------------------
>>>>>>>> Grant Ingersoll
>>>> --------------------------
>>>> Grant Ingersoll
> --------------------------
> Grant Ingersoll

View raw message