manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: Release?
Date Fri, 03 Dec 2010 01:49:03 GMT
ok - I might move it there

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 <> 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 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.
>>>>>>> site has been polished so that it now contains complete javadoc,
>>>>>>> does the built and delivered .zip and tar.gz's.  In short,  we
>>>>>>> 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
>>>>>>>  I believe this needs to be both generated and registered.  The
>>>>>>> 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 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
>>>>>>>> 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 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
>>>>>>>> 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
>>>>>>>>> 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 <>
>>>>>>>>>> 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
>>>>>>>>>>>> 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 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
>>>>>>>>>>>>> Sent: Tuesday, November 09, 2010 9:46
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <>
>>>>>>>>>>>>>>> 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