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
