Re: Release?

Wed, 01 Dec 2010 09:03:02 -0800 

+1
Unfortunately I am maxed out until at least Friday, so there has been no chance for me to get to look at it. That said, I won't hold it up. Besides, 0.1 is mostly testing the process anyway, so we can fix issues in 0.2 as well. So, I say go for it, unless somebody really objects. 

-- Jack Krupansky


-----Original Message----- 
From: Karl Wright

Sent: Wednesday, December 01, 2010 11:47 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?

Should I just call the vote?  It's been a week...
Karl

On Mon, Nov 29, 2010 at 1:18 PM, Karl Wright <daddy...@gmail.com> wrote:

Great!
Has anyone else had a chance to look at RC1 yet?  If not, should I
offer gift certificates or something to encourage participation? ;-)

Karl



On Sat, Nov 27, 2010 at 7:52 AM, Grant Ingersoll <gsing...@apache.org> 
wrote:

I'll take a look, but it won't likely be until Tuesday (extended Turkey 
going on here!)


On Nov 24, 2010, at 8:39 AM, Karl Wright wrote:


Uploaded RC1.
Karl

On Wed, Nov 24, 2010 at 7:04 AM, Karl Wright <daddy...@gmail.com> wrote:

A problem with the FileNet connector has caused me to build an RC1.
It's uploading now.

Karl

On Tue, Nov 23, 2010 at 1:12 PM, Jack Krupansky
<jack.krupan...@lucidimagination.com> wrote:

That's a great leap forward... RC0 of ManifoldCF 0.1! That's a lot of 
the

hardest of the work.


I'm busy on some other things right now, but maybe next week I can 
take a

look.

-- Jack Krupansky

-----Original Message----- From: Karl Wright
Sent: Tuesday, November 23, 2010 1:00 PM
To: connectors-dev@incubator.apache.org
Subject: Re: Release?

While I was looking for a solution, an upload attempt succeeded!

So there is now an RC0 out on people.apache.org/~kwright:

[kwri...@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
manifoldcf-0.1.zip.md5

-rw-r--r--  1 kwright  kwright  158734230 Nov 23 17:55 
manifoldcf-0.1.zip
-rw-r--r--  1 kwright  kwright  156742315 Nov 23 17:06 
manifoldcf-0.1.tar.gz

[kwri...@minotaur:~]$

Please let me know what you think.
Karl



On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright <daddy...@gmail.com> 
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 <daddy...@gmail.com> 
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 
<gsing...@apache.org>

wrote:


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 people.apache.org/~YOURUSERNAME/... 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 http://apache.org/dev/#releases for more info.





Karl

On Fri, Nov 19, 2010 at 4:13 AM, Karl Wright <daddy...@gmail.com>
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 <daddy...@gmail.com>
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 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

gene...@incubator.org - 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 
<daddy...@gmail.com>

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
<gsing...@apache.org> 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: connectors-dev@incubator.apache.org
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: connectors-dev@incubator.apache.org
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
<jack.krupan...@lucidimagination.com> 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: connectors-dev@incubator.apache.org
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
<jack.krupan...@lucidimagination.com> wrote:


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: connectors-dev@incubator.apache.org
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
<jack.krupan...@lucidimagination.com> wrote:



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: connectors-dev@incubator.apache.org
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
http://www.lucidimagination.com


--------------------------
Grant Ingersoll
http://www.lucidimagination.com










--------------------------
Grant Ingersoll
http://www.lucidimagination.com













--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search



































					Reply via email to