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:16:48 GMT
Hmm, for some reason I can't import the KEYS file

gpg --import KEYS

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