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 04:11:48 GMT

On Thu, Dec 2, 2010 at 10:20 PM, Grant Ingersoll <> wrote:
> I can hook up the RAT stuff.
> On Dec 2, 2010, at 10:02 PM, Karl Wright wrote:
>> OK, so I will do the appropriate things to make (1), (4), and maybe
>> (5) happen.  Does anyone want to help with (2), (3), and (8)?
>> Karl
>> On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll <> wrote:
>>> On Dec 2, 2010, at 9:54 PM, Karl Wright wrote:
>>>> Hi Grant,
>>>> In offline conversation you clarified that for (1) you are looking for
>>>> the top level dir in the zip/tar to be named "apache-manifoldcf-0.1".
>>>> You also seem to be asking for a number of other fixes that are
>>>> specific to a release, that I presume would NOT be in sources on trunk
>>>> (e.g. CHANGES.txt).  Are you envisioning that we make these specific
>>>> changes in the release branch only?
>>> It's perfectly fine for CHANGES.txt to be on trunk.  You make the change marking
it as 0.1.  Once the release is out, you add a new section at the top for trunk again.
>>> Later, as we mature, we will likely have branches, etc. for this stuff, but for
now let's just assume trunk is under code freeze and the only changes that can be made are
those related to release.
>>>> Karl
>>>> On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll <>
>>>>> We're close, but I think we've got a few more things to do.  I did get
it to compile.
>>>>> Notes:
>>>>> 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 fix)
>>>>> 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
>>>>> 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.
>>>>> -Grant
>>>>> On Dec 2, 2010, at 8:51 PM, Karl Wright wrote:
>>>>>> Done
>>>>>> Karl
>>>>>> On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright <>
>>>>>>> ok - I might move it there
>>>>>>> Karl
>>>>>>> On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll <>
>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> -rw-r--r--  1 kwright  kwright  158734230 Nov 23 17:55
>>>>>>>>> -rw-r--r--  1 kwright  kwright  156742315 Nov 23 17:06
>>>>>>>>> [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 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
<> wrote:
>>>>>>>>>>>> On Nov 19, 2010, at 6:18 AM, Karl Wright
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>> On Fri, Nov 19, 2010 at 4:13 AM, Karl
Wright <> wrote:
>>>>>>>>>>>>>> The build changes are complete.  I
removed the modules level from the
>>>>>>>>>>>>>> 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, 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 <> wrote:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> (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 <> wrote:
>>>>>>>>>>>>>>>> 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 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:
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> - 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 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"
>>>>>>>>>>>>>>>>>>>> -- 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
>>>>>>>>>>>>>>>>>>>>> -----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,
>>>>>>>>>>>>>>>>>>>>>> --
Jack Krupansky
>>>>>>>>>>>>>>>>>>>>>> -----Original
Message----- From: Grant Ingersoll
>>>>>>>>>>>>>>>>>>>>>> Sent:
Tuesday, November 09, 2010 8:38 AM
>>>>>>>>>>>>>>>>>>>>>> To:
>>>>>>>>>>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>>>>>>>>>>> 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
>>> --------------------------
>>> Grant Ingersoll
> --------------------------
> Grant Ingersoll

View raw message