You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by Chris Mattmann <ch...@jpl.nasa.gov> on 2007/12/24 05:19:44 UTC
[Release Candidate] 0.1-incubating
Hi Folks,
I have posted a candidate for the Apache Tika 0.1-incubating release at
http://people.apache.org/~mattmann/apache-tika-0.1-incubating/rc1/
See the included CHANGES.txt file for details on release contents and latest
changes. The release was made from the 0.1-incubating trunk.
Please vote on releasing these packages as Apache Tika 0.1-incubating. The
vote is open for the next 72 hours. Only votes from Tika committers are
binding, but everyone is welcome to check the release candidate and voice
their approval or disapproval. The vote passes if at least three binding +1
votes are cast.
[ ] +1 Release the packages as Apache Tika 0.1-incubating
[ ] -1 Do not release the packages because...
Thanks!
Cheers,
Chris
______________________________________________
Chris Mattmann, Ph.D.
Chris.Mattmann@jpl.nasa.gov
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: [Release Candidate] 0.1-incubating
Posted by "Keith R. Bennett" <kb...@bbsinc.biz>.
Thanks for that information, Chris.
The +1 was for the quoted text, that we vote on something that has been
frozen, for the reasons given by others.
Regards,
Keith
Chris Mattmann wrote:
>
> Hi Keith,
>
> Was this a +1 to the RC2 for Tika that I just posted?
>
> W.r.t level of confidence, on Nutch, we (loosely) do the following:
>
> 1. Verify the .asc and the .md5 sum actually describes the delivered
> (src+bin) code
> 2. Run build/unit tests
> 3. Small test of the software (if not covered by unit tests)
>
> Thanks!
>
> Cheers,
> Chris
>
>
>
>
> On 12/28/07 12:32 PM, "Keith R. Bennett" <kb...@bbsinc.biz> wrote:
>
>>
>> +1.
>>
>> BTW, I may not have the time to thoroughly review the release candidates.
>> What level of confidence do you suggest as a criterion for voting? (In
>> other words, if I take a brief look, and it looks ok, would you like me
>> to
>> vote +1, or only vote +1 if I review the release candidate thoroughly?)
>>
>> Happy Holidays and New Year to everyone,
>> - Keith
>
>
>
--
View this message in context: http://www.nabble.com/-Release-Candidate--0.1-incubating-tp14484515p14533738.html
Sent from the Apache Tika - Development mailing list archive at Nabble.com.
Re: [Release Candidate] 0.1-incubating
Posted by Chris Mattmann <ch...@jpl.nasa.gov>.
Hi Keith,
Was this a +1 to the RC2 for Tika that I just posted?
W.r.t level of confidence, on Nutch, we (loosely) do the following:
1. Verify the .asc and the .md5 sum actually describes the delivered
(src+bin) code
2. Run build/unit tests
3. Small test of the software (if not covered by unit tests)
Thanks!
Cheers,
Chris
On 12/28/07 12:32 PM, "Keith R. Bennett" <kb...@bbsinc.biz> wrote:
>
> +1.
>
> BTW, I may not have the time to thoroughly review the release candidates.
> What level of confidence do you suggest as a criterion for voting? (In
> other words, if I take a brief look, and it looks ok, would you like me to
> vote +1, or only vote +1 if I review the release candidate thoroughly?)
>
> Happy Holidays and New Year to everyone,
> - Keith
>
>
> Bertrand Delacretaz wrote:
>>
>> On Dec 27, 2007 2:59 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>
>>> ...What I'm concerned about is that we
>>> don't have a release vote on something that still gets modified before
>>> it gets published....
>>
>> Agreed, and that's why I like it when the md5 digests of the artifacts
>> that we vote on are included in the vote threads.
>>
>> This allow people to check that they're using the exact same stuff
>> that we vote on.
>>
>> -Bertrand
>>
>>
______________________________________________
Chris Mattmann, Ph.D.
Chris.Mattmann@jpl.nasa.gov
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: [Release Candidate] 0.1-incubating
Posted by Chris Mattmann <ch...@jpl.nasa.gov>.
BTW, happy holidays and new year!
Cheers,
Chris
On 12/28/07 12:32 PM, "Keith R. Bennett" <kb...@bbsinc.biz> wrote:
>
> +1.
>
> BTW, I may not have the time to thoroughly review the release candidates.
> What level of confidence do you suggest as a criterion for voting? (In
> other words, if I take a brief look, and it looks ok, would you like me to
> vote +1, or only vote +1 if I review the release candidate thoroughly?)
>
> Happy Holidays and New Year to everyone,
> - Keith
>
>
> Bertrand Delacretaz wrote:
>>
>> On Dec 27, 2007 2:59 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>
>>> ...What I'm concerned about is that we
>>> don't have a release vote on something that still gets modified before
>>> it gets published....
>>
>> Agreed, and that's why I like it when the md5 digests of the artifacts
>> that we vote on are included in the vote threads.
>>
>> This allow people to check that they're using the exact same stuff
>> that we vote on.
>>
>> -Bertrand
>>
>>
______________________________________________
Chris Mattmann, Ph.D.
Chris.Mattmann@jpl.nasa.gov
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: [Release Candidate] 0.1-incubating
Posted by "Keith R. Bennett" <kb...@bbsinc.biz>.
+1.
BTW, I may not have the time to thoroughly review the release candidates.
What level of confidence do you suggest as a criterion for voting? (In
other words, if I take a brief look, and it looks ok, would you like me to
vote +1, or only vote +1 if I review the release candidate thoroughly?)
Happy Holidays and New Year to everyone,
- Keith
Bertrand Delacretaz wrote:
>
> On Dec 27, 2007 2:59 PM, Jukka Zitting <ju...@gmail.com> wrote:
>
>> ...What I'm concerned about is that we
>> don't have a release vote on something that still gets modified before
>> it gets published....
>
> Agreed, and that's why I like it when the md5 digests of the artifacts
> that we vote on are included in the vote threads.
>
> This allow people to check that they're using the exact same stuff
> that we vote on.
>
> -Bertrand
>
>
--
View this message in context: http://www.nabble.com/-Release-Candidate--0.1-incubating-tp14484515p14531136.html
Sent from the Apache Tika - Development mailing list archive at Nabble.com.
Re: [Release Candidate] 0.1-incubating
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 27, 2007 2:59 PM, Jukka Zitting <ju...@gmail.com> wrote:
> ...What I'm concerned about is that we
> don't have a release vote on something that still gets modified before
> it gets published....
Agreed, and that's why I like it when the md5 digests of the artifacts
that we vote on are included in the vote threads.
This allow people to check that they're using the exact same stuff
that we vote on.
-Bertrand
Re: [Release Candidate] 0.1-incubating
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Dec 27, 2007 8:39 AM, <ma...@jpl.nasa.gov> wrote:
> > We can't be voting on a release and then have changes made to it
> > before it goes out. The vote needs to happen on the actual bytes that
> > we will be publishing.
>
> I disagree with you on this Jukka -- there's a difference between
> updating text in a CHANGES.txt file that affects nothing, and updating
> source code.
Changing anything in the release package affects at least the
checksums and signatures, and verifying them is an important part of
the audit associated with the release vote.
> Additionally, it wouldn't be updating a tag (which is
> suppossed to be "sacred"), it would be updating a branch (which
> inherently can be modified). That's why branch first, tag later, is a
> good practice. So, as you'll see below, because I *branched* and
> didn't *tag*, it's perfectly OK to update the branch (e.g., with the
> new CHANGES.txt file), and then create a new RC from it. I suggest
> doing this as a compromise.
Certainly. How the release is handled in svn is not that essential,
and there's no requirement of even having any branches or tags for a
releases. The stuff that's really important for the release vote is
the packaged release candidate, so repackaging and calling a new vote
on the new RC is quite OK even without any svn activity (though making
the changes go through svn would certainly be good).
> > I suggest we make the suggested changes, tag and package the modified
> > release candidate, and restart the vote in a "[VOTE]" thread (it's
> > good practice to use that subject tag to make the vote threads easier
> > to filter and find).
>
> I could go both ways on this. I'm not sure that we need a brand new
> vote thread just to have a new message header, and a few nominal
> changes, however, if you feel strongly about it, I am willing to bend.
I think it's better to start a new vote thread. It doesn't cost much
and keeps things nice and clear by avoiding potential confusion about
what we really are voting on.
The purpose of the release vote is to make the release an action (and
thus a liability) of the ASF instead of the individual release
manager. It's best not to muddy those waters even for "nominal
changes" as later on (say a few years down the line) it'll be quite
difficult to determine what those changes really were, and whether the
the release vote really did imply that the ASF should embrace also the
modified release.
Sure, this is probably a rather academic concern for Tika at this
stage, but it's better to get the process straight right at the
beginning instead of later on when the audience of our releases will
likely be higher.
> I'm not sure there's *only* one right way to do this.
+1 There's quite a lot of freedom for a project and a release manager
to decide what best suits them. What I'm concerned about is that we
don't have a release vote on something that still gets modified before
it gets published.
> Yes, let's make an update to the 0.1 branch. I see that you've already
> made a few changes. I will go ahead and update CHANGES.txt there as
> well, create a new release candidate, and then call for a new vote.
> Sound good?
Yes, thanks! While you're at it, please also include your key in the
KEYS file and and post the file along with the release candidate.
BR,
Jukka Zitting
Re: [Release Candidate] 0.1-incubating
Posted by ma...@jpl.nasa.gov.
> I'm with Niall on that we should include the Maven artifacts in the
> release vote. I've built the artifacts from the 0.1-incubating release
> candidate you posted and deployed them to a staging repository at
> http://people.apache.org/~jukka/tika/0.1-incubating/repository/. I've
> also signed the artifacts (jar and pom) with my key, so unless we want
> to scrap this vote and start a new one after a few changes (see below)
> we could just consider these artifacts as being within the scope of
> this vote.
Exactly my point. That's what I was saying. I believe that this was
what we decided before? Correct?
>> This will be updated before I officially tag the branch, and make the
>> release.
>
> We can't be voting on a release and then have changes made to it
> before it goes out. The vote needs to happen on the actual bytes that
> we will be publishing.
I disagree with you on this Jukka -- there's a difference between
updating text in a CHANGES.txt file that affects nothing, and updating
source code. Additionally, it wouldn't be updating a tag (which is
suppossed to be "sacred"), it would be updating a branch (which
inherently can be modified). That's why branch first, tag later, is a
good practice. So, as you'll see below, because I *branched* and
didn't *tag*, it's perfectly OK to update the branch (e.g., with the
new CHANGES.txt file), and then create a new RC from it. I suggest
doing this as a compromise.
>
> I suggest we make the suggested changes, tag and package the modified
> release candidate, and restart the vote in a "[VOTE]" thread (it's
> good practice to use that subject tag to make the vote threads easier
> to filter and find).
I could go both ways on this. I'm not sure that we need a brand new
vote thread just to have a new message header, and a few nominal
changes, however, if you feel strongly about it, I am willing to bend.
>
>> > 2) Usual convention I've seen on other projects is to use "tags" for
>> > releases and "branches" for alternative development branches:
>> > http://svn.apache.org/viewvc/incubator/tika/branches/
>>
>> I've seen both conventions on projects for this. In my mind, it makes sense
>> to first branch, then if there are any issues during rc evaluation, and
>> patches need to be applied, the patches can be first applied to the branch.
>> Once an rc is accepted by the committers, then, the branch is tagged as "the
>> release". Then, if there are any more changes to a particular product line,
>> the same cycle ensues (update branch, come to agreement, tag branch as
>> "release").
>
> See my above point about the release vote happening on the actual
> bytes that get released. Thus there is nothing you should (can!)
> modify after the vote passes, and so tagging the release already
> before the vote and actually using the contents of that tag when
> packaging the release candidate is good practice.
I'm not sure there's *only* one right way to do this. Sure, what you
suggest ensures that the "bytes" don't get modified, but it's not like
we have a sacred process in place of how to do this, nor am I
suggesting updating code. I'm simply suggesting updating the
CHANGES.txt file, on a *branch*, not a *tag*.
I suppose, if you want, I could simply update CHANGES.txt in the
branch, post a new release candidate, and then call for a new vote.
Would that make you happy?
>
>> > 3) The IPMC will probably ask to see a RAT report - the site build
>> > includes one (and it looks fine) - so might be a good idea to either
>> > stage the site built from that tag or just produce a text one manually
>> > - I have produced a text one from the 0.1-incubating source distro
>> > here if that makes life easier:
>> > http://people.apache.org/~niallp/Tika-0.1/
>
> The RAT output points out a few resources (tika-config.xml,
> log4j.properties) that should have a proper license header. IMHO this
> is not a blocker for the release, but I'll be filing an issue for that
> in Jira and fixing it in trunk. If you like we can merge the change to
> the 0.1 branch.
Yes, let's make an update to the 0.1 branch. I see that you've already
made a few changes. I will go ahead and update CHANGES.txt there as
well, create a new release candidate, and then call for a new vote.
Sound good?
Cheers,
Chris
>
> BR,
>
> Jukka Zitting
>
Re: [Release Candidate] 0.1-incubating
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Dec 26, 2007 11:55 PM, Jukka Zitting <ju...@gmail.com> wrote:
> The RAT output points out a few resources (tika-config.xml,
> log4j.properties) that should have a proper license header. IMHO this
> is not a blocker for the release, but I'll be filing an issue for that
> in Jira and fixing it in trunk. If you like we can merge the change to
> the 0.1 branch.
Reported and fixed as TIKA-111. You can merge the change to 0.1-incubating by:
$ svn checkout
https://svn.apache.org/repos/asf/incubator/tika/branches/0.1-incubating
$ cd 0.1-incubating
$ svn merge -r 606968:606969
https://svn.apache.org/repos/asf/incubator/tika/trunk
$ svn commit -m '...'
Note that I don't consider this a blocker, so I won't mind if you
prefer leaving this out of 0.1.
BR,
Jukka Zitting
Re: [Release Candidate] 0.1-incubating
Posted by Jukka Zitting <ju...@gmail.com>.
HI,
On Dec 24, 2007 6:47 PM, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
> > I can't see any issues with the release candidate but it would be nice
> > for windoze users to include "zip" distro - also wouldn't it be nice
> > for users to also release binary distros and not just the source
> > distro?
>
> We (Jukka, Bertrand, Sami) discussed this earlier, and the consensus was to
> make the tika jar file available from a maven repository somewhere. So,
> that's what we're going with for 0.1.
I'm with Niall on that we should include the Maven artifacts in the
release vote. I've built the artifacts from the 0.1-incubating release
candidate you posted and deployed them to a staging repository at
http://people.apache.org/~jukka/tika/0.1-incubating/repository/. I've
also signed the artifacts (jar and pom) with my key, so unless we want
to scrap this vote and start a new one after a few changes (see below)
we could just consider these artifacts as being within the scope of
this vote.
> > Couple of other minor points:
> >
> > 1) CHANGES.txt says "Unreleased changes (0.1-dev)" rather than
> > indicating the 0.1-Incubating release
>
> This will be updated before I officially tag the branch, and make the
> release.
We can't be voting on a release and then have changes made to it
before it goes out. The vote needs to happen on the actual bytes that
we will be publishing.
I suggest we make the suggested changes, tag and package the modified
release candidate, and restart the vote in a "[VOTE]" thread (it's
good practice to use that subject tag to make the vote threads easier
to filter and find).
> > 2) Usual convention I've seen on other projects is to use "tags" for
> > releases and "branches" for alternative development branches:
> > http://svn.apache.org/viewvc/incubator/tika/branches/
>
> I've seen both conventions on projects for this. In my mind, it makes sense
> to first branch, then if there are any issues during rc evaluation, and
> patches need to be applied, the patches can be first applied to the branch.
> Once an rc is accepted by the committers, then, the branch is tagged as "the
> release". Then, if there are any more changes to a particular product line,
> the same cycle ensues (update branch, come to agreement, tag branch as
> "release").
See my above point about the release vote happening on the actual
bytes that get released. Thus there is nothing you should (can!)
modify after the vote passes, and so tagging the release already
before the vote and actually using the contents of that tag when
packaging the release candidate is good practice.
In Jackrabbit I even tag x.y.z-rcN candidates that I only post for
preliminary review before starting the release vote on a x.y.z
candidate package. See
https://svn.apache.org/repos/asf/jackrabbit/tags/ for example.
> > 3) The IPMC will probably ask to see a RAT report - the site build
> > includes one (and it looks fine) - so might be a good idea to either
> > stage the site built from that tag or just produce a text one manually
> > - I have produced a text one from the 0.1-incubating source distro
> > here if that makes life easier:
> > http://people.apache.org/~niallp/Tika-0.1/
The RAT output points out a few resources (tika-config.xml,
log4j.properties) that should have a proper license header. IMHO this
is not a blocker for the release, but I'll be filing an issue for that
in Jira and fixing it in trunk. If you like we can merge the change to
the 0.1 branch.
BR,
Jukka Zitting
Re: [Release Candidate] 0.1-incubating
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 24, 2007 4:47 PM, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
> Hi Niall,
>
> Thanks for the comments. My replies embedded below:
>
> > I can't see any issues with the release candidate but it would be nice
> > for windoze users to include "zip" distro - also wouldn't it be nice
> > for users to also release binary distros and not just the source
> > distro?
>
> We (Jukka, Bertrand, Sami) discussed this earlier, and the consensus was to
> make the tika jar file available from a maven repository somewhere. So,
> that's what we're going with for 0.1.
OK great - as thats a release artifact as well IMO would be good to
post that for the review/vote as well.
> > 1) CHANGES.txt says "Unreleased changes (0.1-dev)" rather than
> > indicating the 0.1-Incubating release
>
> This will be updated before I officially tag the branch, and make the
> release.
>
> > 2) Usual convention I've seen on other projects is to use "tags" for
> > releases and "branches" for alternative development branches:
> > http://svn.apache.org/viewvc/incubator/tika/branches/
>
> I've seen both conventions on projects for this. In my mind, it makes sense
> to first branch, then if there are any issues during rc evaluation, and
> patches need to be applied, the patches can be first applied to the branch.
> Once an rc is accepted by the committers, then, the branch is tagged as "the
> release". Then, if there are any more changes to a particular product line,
> the same cycle ensues (update branch, come to agreement, tag branch as
> "release").
>
> FYI, Apache Nutch uses the "tag first" convention, but during the 0.9
> release (that I made), we discussed doing the "branch first" convention, and
> why it makes sense (similar reasons to above), and I'm really in favor of
> it.
>From the releases I've seen or done then this would mean applying
changes in two places - the branch and the trunk and would just be
unecessary/extra work. I could see the value of creating a branch if a
serious bug turned up after the release and the project wanted to just
put out e.g. Tika 0.1.1 to fix that - but that branch could be created
from the release tag when that occurs.
> > 3) The IPMC will probably ask to see a RAT report - the site build
> > includes one (and it looks fine) - so might be a good idea to either
> > stage the site built from that tag or just produce a text one manually
> > - I have produced a text one from the 0.1-incubating source distro
> > here if that makes life easier:
> > http://people.apache.org/~niallp/Tika-0.1/
>
> Looks good. Could you please include the commands that you used to generate
> the RAT report? I will include it in the guide that I am making describing
> how to make a Tika release.
On windoze..
java -cp c:/j/rat-0.5.1/rat-lib-all-0.5.1.jar rat.Report
apache-tika-0.1-incubating > apache-tika-0.1-incubating.txt
RAT availbale here (although soon to be entering Apache Incubator)
http://code.google.com/p/arat/
Niall
> Thanks,
> Chris
>
>
> >
> > Niall
> >
> > On Dec 24, 2007 4:19 AM, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
> >> Hi Folks,
> >>
> >> I have posted a candidate for the Apache Tika 0.1-incubating release at
> >>
> >> http://people.apache.org/~mattmann/apache-tika-0.1-incubating/rc1/
> >>
> >> See the included CHANGES.txt file for details on release contents and latest
> >> changes. The release was made from the 0.1-incubating trunk.
> >>
> >> Please vote on releasing these packages as Apache Tika 0.1-incubating. The
> >> vote is open for the next 72 hours. Only votes from Tika committers are
> >> binding, but everyone is welcome to check the release candidate and voice
> >> their approval or disapproval. The vote passes if at least three binding +1
> >> votes are cast.
> >>
> >> [ ] +1 Release the packages as Apache Tika 0.1-incubating
> >> [ ] -1 Do not release the packages because...
> >>
> >> Thanks!
> >>
> >> Cheers,
> >>
> >> Chris
>
>
> ______________________________________________
> Chris Mattmann, Ph.D.
> Chris.Mattmann@jpl.nasa.gov
> Cognizant Development Engineer
> Early Detection Research Network Project
> _________________________________________________
> Jet Propulsion Laboratory Pasadena, CA
> Office: 171-266B Mailstop: 171-246
> _______________________________________________________
>
> Disclaimer: The opinions presented within are my own and do not reflect
> those of either NASA, JPL, or the California Institute of Technology.
>
>
>
Re: [Release Candidate] 0.1-incubating
Posted by Chris Mattmann <ch...@jpl.nasa.gov>.
Hi Niall,
Thanks for the comments. My replies embedded below:
> I can't see any issues with the release candidate but it would be nice
> for windoze users to include "zip" distro - also wouldn't it be nice
> for users to also release binary distros and not just the source
> distro?
We (Jukka, Bertrand, Sami) discussed this earlier, and the consensus was to
make the tika jar file available from a maven repository somewhere. So,
that's what we're going with for 0.1.
>
> Couple of other minor points:
>
> 1) CHANGES.txt says "Unreleased changes (0.1-dev)" rather than
> indicating the 0.1-Incubating release
This will be updated before I officially tag the branch, and make the
release.
> 2) Usual convention I've seen on other projects is to use "tags" for
> releases and "branches" for alternative development branches:
> http://svn.apache.org/viewvc/incubator/tika/branches/
I've seen both conventions on projects for this. In my mind, it makes sense
to first branch, then if there are any issues during rc evaluation, and
patches need to be applied, the patches can be first applied to the branch.
Once an rc is accepted by the committers, then, the branch is tagged as "the
release". Then, if there are any more changes to a particular product line,
the same cycle ensues (update branch, come to agreement, tag branch as
"release").
FYI, Apache Nutch uses the "tag first" convention, but during the 0.9
release (that I made), we discussed doing the "branch first" convention, and
why it makes sense (similar reasons to above), and I'm really in favor of
it.
> 3) The IPMC will probably ask to see a RAT report - the site build
> includes one (and it looks fine) - so might be a good idea to either
> stage the site built from that tag or just produce a text one manually
> - I have produced a text one from the 0.1-incubating source distro
> here if that makes life easier:
> http://people.apache.org/~niallp/Tika-0.1/
Looks good. Could you please include the commands that you used to generate
the RAT report? I will include it in the guide that I am making describing
how to make a Tika release.
Thanks,
Chris
>
> Niall
>
> On Dec 24, 2007 4:19 AM, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
>> Hi Folks,
>>
>> I have posted a candidate for the Apache Tika 0.1-incubating release at
>>
>> http://people.apache.org/~mattmann/apache-tika-0.1-incubating/rc1/
>>
>> See the included CHANGES.txt file for details on release contents and latest
>> changes. The release was made from the 0.1-incubating trunk.
>>
>> Please vote on releasing these packages as Apache Tika 0.1-incubating. The
>> vote is open for the next 72 hours. Only votes from Tika committers are
>> binding, but everyone is welcome to check the release candidate and voice
>> their approval or disapproval. The vote passes if at least three binding +1
>> votes are cast.
>>
>> [ ] +1 Release the packages as Apache Tika 0.1-incubating
>> [ ] -1 Do not release the packages because...
>>
>> Thanks!
>>
>> Cheers,
>>
>> Chris
______________________________________________
Chris Mattmann, Ph.D.
Chris.Mattmann@jpl.nasa.gov
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: [Release Candidate] 0.1-incubating
Posted by Niall Pemberton <ni...@gmail.com>.
I can't see any issues with the release candidate but it would be nice
for windoze users to include "zip" distro - also wouldn't it be nice
for users to also release binary distros and not just the source
distro?
Couple of other minor points:
1) CHANGES.txt says "Unreleased changes (0.1-dev)" rather than
indicating the 0.1-Incubating release
2) Usual convention I've seen on other projects is to use "tags" for
releases and "branches" for alternative development branches:
http://svn.apache.org/viewvc/incubator/tika/branches/
3) The IPMC will probably ask to see a RAT report - the site build
includes one (and it looks fine) - so might be a good idea to either
stage the site built from that tag or just produce a text one manually
- I have produced a text one from the 0.1-incubating source distro
here if that makes life easier:
http://people.apache.org/~niallp/Tika-0.1/
Niall
On Dec 24, 2007 4:19 AM, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
> Hi Folks,
>
> I have posted a candidate for the Apache Tika 0.1-incubating release at
>
> http://people.apache.org/~mattmann/apache-tika-0.1-incubating/rc1/
>
> See the included CHANGES.txt file for details on release contents and latest
> changes. The release was made from the 0.1-incubating trunk.
>
> Please vote on releasing these packages as Apache Tika 0.1-incubating. The
> vote is open for the next 72 hours. Only votes from Tika committers are
> binding, but everyone is welcome to check the release candidate and voice
> their approval or disapproval. The vote passes if at least three binding +1
> votes are cast.
>
> [ ] +1 Release the packages as Apache Tika 0.1-incubating
> [ ] -1 Do not release the packages because...
>
> Thanks!
>
> Cheers,
>
> Chris
Re: [Release Candidate] 0.1-incubating
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
[x] -1 Do not release the packages because there is no KEYS file and I
can't find the B876884A key used to sign the release candidate.
As discussed, there are also some other issues that should be
addressed but that IMHO are not blocking.
BR,
Jukka Zitting