manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Release?
Date Fri, 03 Dec 2010 02:45:23 GMT
We're close, but I think we've got a few more things to do.  I did get it to compile.


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
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.


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 find
>>>>> 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
>>>>>> hamsters turning the wheels or something, because the upload speed
>>>>>> 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 <>
>>>>>>> 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 too.
>>>>>>> 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
>>>>>>>>>  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 <>
>>>>>>>>>>> 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
>>>>>>>>>>>>> Sent: Monday, November 15, 2010 10:23
>>>>>>>>>>>>> To:
>>>>>>>>>>>>> Subject: Re: Release?
>>>>>>>>>>>>> On Nov 10, 2010, at 1:22 AM, Jack Krupansky
>>>>>>>>>>>>>> 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 release?
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> -- 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 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
>>>>>>>>>>>>>>>>> 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