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:51:06 GMT

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 <> 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 <>
>>>>> 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
>>>>>>> much stuff up.  Glad about that.
>>>>>> Yep, sorry, have been in meetings.
>>>>>>> Last remaining release issue is getting the release files to
>>>>>>> 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 *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 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 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 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
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> Sent: Tuesday, November 09, 2010 1:56
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <>
>>>>>>>>>>>>>> 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 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 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 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