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 01:31:19 GMT
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


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 <> 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 <> 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 <>
>>>> 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 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
>>>>>> 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,
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>>> tar.gz and .zip.
>>>>>>> Issues still to address before release:
>>>>>>> (1) source tar.gz and zip in outer-level build.xml, which I will
>>>>>>> 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
>>>>>>> - 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
>>>>>>> to be included in the release tar.gz, or just the source tar.gz?
>>>>>>> suspect both, but please confirm.  Also, if there is a typical
>>>>>>> organization of the release tar.gz in relation to the source
>>>>>>> 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
>>>>>>>> them to xdocs that are part of the ManifoldCF site.  These
>>>>>>>> have no user content other than stuff Grant or I added, according
>>>>>>>> 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,
>>>>>>>> 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 <>
>>>>>>>>> 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:
>>>>>>>>>> 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
>>>>>>>>>>> - 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
>>>>>>>>>>> <> 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:
>>>>>>>>>>>> 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
>>>>>>>>>>>>> Sent: Tuesday, November 09, 2010 9:28
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <>
>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>> 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

View raw message