There were three binding +1's, and nothing else. Release passes!
Karl
On Mon, Jan 31, 2011 at 9:32 PM, Karl Wright daddy...@gmail.com wrote:
It looks like we're going to go ahead and release.
I'll post a [RESULT][VOTE] message when that is certain.
Karl
On Mon, Jan 31, 2011 at 7:56 PM, Karl
If you feel you need to re-release, then so be it.
However, you if can provide specific information about what has changed
since the last RC, that can make voting easier.
Especially seeing as Incubator PMC members are voting on the fact that
the release is legally correct, not so much that it
:-)
Well, the decision of the community was to go ahead with the current
artifact, FWIW. It should be replicating as we speak.
Thanks anyway, though!
Karl
On Tue, Feb 1, 2011 at 6:32 AM, Upayavira u...@odoko.co.uk wrote:
If you feel you need to re-release, then so be it.
However, you if can
About 5 hours after ant voted, a user discovered that a problem we'd
thought was fixed in RC8 is still in fact present, albeit in a
slightly different form. The community is trying to figure out if
this should mean a new RC or not. We did triage the problem initially
as a release blocker.
The
It looks like we're going to go ahead and release.
I'll post a [RESULT][VOTE] message when that is certain.
Karl
On Mon, Jan 31, 2011 at 7:56 PM, Karl Wright daddy...@gmail.com wrote:
About 5 hours after ant voted, a user discovered that a problem we'd
thought was fixed in RC8 is still in fact
+1
...ant
On Thu, Jan 27, 2011 at 8:44 AM, Karl Wright daddy...@gmail.com wrote:
Thanks for the votes! Still need one more binding +1...
Karl
On Tue, Jan 25, 2011 at 11:45 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Karl,
+1 from me (binding).
Signatures
Thanks for the votes! Still need one more binding +1...
Karl
On Tue, Jan 25, 2011 at 11:45 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Karl,
+1 from me (binding).
Signatures check out:
[chipotle:~/tmp/apache-manifoldcf-0.1-incubating] mattmann% gpg --import
+1 (binding), just as voted on ManifoldCF.
-Grant
On Jan 20, 2011, at 9:48 PM, Karl Wright wrote:
Calling the official vote for release of ManifoldCF 0.1 incubating,
RC8, which can be found at http://people.apache.org/~kwright . The
community has voted for release of the new RC, so we're
Hi Karl,
+1 from me (binding).
Signatures check out:
[chipotle:~/tmp/apache-manifoldcf-0.1-incubating] mattmann% gpg --import *.KEYS
gpg: key 03824582: Karl David Wright (CODE SIGNING KEY) kwri...@apache.org
not changed
gpg: key FE045966: Grant Ingersoll (CODE SIGNING KEY) gsing...@apache.org
Oh, forgot to mention that the release candidate tag is at:
http://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.1-incubating-RC8/
Karl
On Thu, Jan 20, 2011 at 9:48 PM, Karl Wright daddy...@gmail.com wrote:
Calling the official vote for release of ManifoldCF 0.1 incubating,
RC8, which
Calling the official vote for release of ManifoldCF 0.1 incubating,
RC8, which can be found at http://people.apache.org/~kwright . The
community has voted for release of the new RC, so we're ready to go
ahead with an incubator vote on the same.
Thanks in advance!
Karl
I still think the binary archive is unnecessarily bloated, and will
cause wasted load and resources for mirrors and consumers.
If it were straightforward, I would already have done it.
Here's a rundown of the space usage in the dist directory of the -bin object:
doc:
995 File(s)
On Sat, Jan 8, 2011 at 4:40 PM, Karl Wright daddy...@gmail.com wrote:
I've attached a new proposed version of README.txt, NOTICE.TXT, and
LICENSE.txt. Any further comments?
Karl
These look good to me.
Its a long thread so a bit hard to keep track of without a new RC but
i think what you
On 9 January 2011 08:14, Karl Wright daddy...@gmail.com wrote:
I still think the binary archive is unnecessarily bloated, and will
cause wasted load and resources for mirrors and consumers.
If it were straightforward, I would already have done it.
Here's a rundown of the space usage in the
Not sure what you mean by open copy.
Open meaning not bound up in a war.
There are also 2 copies of each of the war files, total 37M for one set.
Yes, that's known to me; so you are also suggesting that not just the
dependent jars be treated this way, but all the built artifacts as
well.
Karl Wright wrote:
(4) Grant suggested that we simply not include the PDF portion of the
doc build. This has the disadvantage of causing each site page to
have a broken link, but otherwise the PDFs are not of great value,
excepting perhaps the end-user documentation PDF. Savings: about
On Fri, Jan 7, 2011 at 11:13 AM, Karl Wright daddy...@gmail.com wrote:
- I have made no changes to NOTICE and LICENSE, because the incubator
and community advice seemed contradictory. I would like a general
sense of how many people feel that the current NOTICE and LICENSE
files are
The current NOTICE file has exactly what you specify, plus a preamble
describing components and their licenses. I will remove the preamble
- it was based on the Solr/Lucene NOTICE which I was told to use as an
example.
The LICENSE file, on the other hand, should currently have everything
that's
That NOTICE file still contains additional text about Jetty and
HSQLDB, why is that needed? The Apache License section 4d describes
what must be included in the NOTICE and AIUI it says you only need to
include in your NOTICE the notices from Jetty and HSQLDB if you
distribute derivitave works of
It is true that we've created no derivative Jetty or HSQLDB works. But
the Apache License 4(d) section does not explicitly mention Jetty and
HSQLDB as not requiring NOTICE text, and my understanding is that the
license terms for those components require the text I have included in
NOTICE. I am
Note: the NOTICE year will need to be changed for the next release to 2010-2011.
For the current release I think it can remain as is - there don't seem
to have been any substantive changes made in 2011.
The leading blank lines need to be removed.
Otherwise, I concur with what Ant has mentioned
I've made the 2011 change already. But I'm having trouble reconciling
your instructions with this part of the Apache license:
(d) If the Work includes a NOTICE text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable
I've confirmed the following:
(1) The Jetty notice text I've included came from the source Jetty NOTICE file.
(2) The HSQLDB notice text I've included is NOT the same as the HSQLDB
license text, and very likely came from an HSQLDB NOTICE file also.
So, if I'm doing it wrong, at least I'm being
On Jan 8, 2011, at 7:24 AM, Karl Wright wrote:
I've made the 2011 change already. But I'm having trouble reconciling
your instructions with this part of the Apache license:
(d) If the Work includes a NOTICE text file as part of its
distribution, then any Derivative Works
Ok, so then it sounds like all of the current contents of NOTICE.txt
can technically be removed. Where should these go? LICENSE.txt?
README.txt? The circular file? I've received one recommendation for
each.
Karl
On Sat, Jan 8, 2011 at 10:56 AM, Ralph Goers ralph.go...@dslextreme.com wrote:
with a new RC rev # and include
your three updated text files in it from here. I would also like to see a new
[VOTE] thread, like this:
[VOTE] Release Apache ManifoldCF 0.1 RC #N
That way it's clear in mailing list threads how many +1s were attained, etc.,
without having to do a lot of detective work
a new [VOTE] thread, like this:
[VOTE] Release Apache ManifoldCF 0.1 RC #N
That way it's clear in mailing list threads how many +1s were attained, etc.,
without having to do a lot of detective work.
Thanks for working the process. Trust me: it gets easier :)
Once the above is done, I
contents into a new directory with a new RC rev # and
include your three updated text files in it from here. I would also like to
see a new [VOTE] thread, like this:
[VOTE] Release Apache ManifoldCF 0.1 RC #N
That way it's clear in mailing list threads how many +1s were attained, etc
the current contents into a new directory with a new RC rev # and
include your three updated text files in it from here. I would also like to
see a new [VOTE] thread, like this:
[VOTE] Release Apache ManifoldCF 0.1 RC #N
That way it's clear in mailing list threads how many +1s were attained,
etc
] Release Apache ManifoldCF 0.1 RC #N
That way it's clear in mailing list threads how many +1s were attained,
etc., without having to do a lot of detective work.
Thanks for working the process. Trust me: it gets easier :)
Once the above is done, I don't foresee any objections from me!
Cheers
On 8 January 2011 16:40, Karl Wright daddy...@gmail.com wrote:
I've attached a new proposed version of README.txt, NOTICE.TXT, and
LICENSE.txt. Any further comments?
As previously mentioned, all the files appear to have leading blank lines.
These should be removed.
The README file says:
(1) There already is a separate DISCLAIMER.txt. I have attached it
for your consideration.
(2) As discussed earlier, the LICENSE file already contains sections
for HSQLDB and Jetty; the stuff added to the end of the README came
from NOTICE files in those projects, and is not license material.
(3)
On 9 January 2011 02:33, Karl Wright daddy...@gmail.com wrote:
(1) There already is a separate DISCLAIMER.txt. I have attached it
for your consideration.
OK.
(2) As discussed earlier, the LICENSE file already contains sections
for HSQLDB and Jetty; the stuff added to the end of the README
The ManifoldCF documentation already requires Forrest 0.9-dev. If
there was a downloadable binary version of 0.9-dev available, I'd be
willing to consider requiring the user to install it. But that added
step is just too much, I think, to expect people to do as part of an
initial ManifoldCF
Karl Wright wrote:
The ManifoldCF documentation already requires Forrest 0.9-dev. If
there was a downloadable binary version of 0.9-dev available, I'd be
willing to consider requiring the user to install it. But that added
step is just too much, I think, to expect people to do as part of an
btw, the release number should not be 0.1 but incubation-0.1 according to the
Incubator rules.
LieGrue,
strub
--- On Fri, 1/7/11, David Crossley cross...@apache.org wrote:
From: David Crossley cross...@apache.org
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general
, the release number should not be 0.1 but incubation-0.1 according to the
Incubator rules.
LieGrue,
strub
--- On Fri, 1/7/11, David Crossley cross...@apache.org wrote:
From: David Crossley cross...@apache.org
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general@incubator.apache.org
Date
Crossley cross...@apache.org wrote:
From: David Crossley cross...@apache.org
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general@incubator.apache.org
Date: Friday, January 7, 2011, 8:29 AM
Karl Wright wrote:
The ManifoldCF documentation already requires Forrest
0.9-dev
...@apache.org wrote:
From: David Crossley cross...@apache.org
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general@incubator.apache.org
Date: Friday, January 7, 2011, 8:29 AM
Karl Wright wrote:
The ManifoldCF documentation already requires Forrest
0.9-dev
I have uploaded a new artifact now.
I could call this a release candidate except for the following:
- This artifact has not been voted on by the ManifoldCF community. It
is probably necessary to revote since what is included in the package
has changed (e.g. no build artifacts except for docs).
-
oki that's fine then. Only did read 0.1 and didn't get the suffix.
LieGrue,
stru
--- On Fri, 1/7/11, Karl Wright daddy...@gmail.com wrote:
From: Karl Wright daddy...@gmail.com
Subject: Re: [VOTE] Release Apache ManifoldCF 0.1
To: general@incubator.apache.org
Date: Friday, January 7, 2011
Hi Karl,
Great job. +1 from me.
SIGS check out:
[chipotle:~/tmp/apache-manifoldcf-0.1-incubating] mattmann% gpg --verify
apache-manifoldcf-0.1-incubating.tar.gz.asc
gpg: Signature made Fri Jan 7 02:44:17 2011 PST using RSA key ID 03824582
gpg: Good signature from Karl David Wright (CODE
The community wanted to include both a source and a source+binary
distribution. Accordingly, I spun up one of those, which is RC5. The
RC4 candidate is still up there, so I guess you can vote on either
one.
Thanks!
Karl
On Fri, Jan 7, 2011 at 11:25 AM, Mattmann, Chris A (388J)
Karl Wright wrote:
The RAT report after these changes looks good except for two files,
which come from the skins in the site:
[rat:report] Unapproved licenses:
[rat:report]
[rat:report]
C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skins/common/xslt/html/split.xsl
I don't understand why ManifoldCF needs this special skin processing
that then needs to live in your svn.
At Forrest, we advise not to create their own skin unless absolutely
necessary. We prefer to address any needs in the default skin.
With a quick flick through the ManifoldCF site i do
Hi,
The Apache ManifoldCF community has voted to release our first set of artifacts
and now would like an Incubator vote. Since this is our first release, extra
attention to detail is appreciated.
You can find the artifacts at http://people.apache.org/~kwright/
Thanks,
Grant
Hi Grant,
Is this a source or binary release? How are you guys making the release? Using
Ant or Maven?
Can you guys provide a KEYS and CHANGES.txt file as part of the release
artifacts?
Cheers,
Chris
On Jan 6, 2011, at 5:12 AM, Grant Ingersoll wrote:
Hi,
The Apache ManifoldCF community
Answering on Grant's behalf, the ManifoldCF artifact contains both
source and binary, and the KEYS and CHANGES.txt files are within the
artifact, as seems to be standard Apache practice. You just need to
untar/unzip it.
Karl
On Thu, Jan 6, 2011 at 10:09 AM, Mattmann, Chris A (388J)
Hi Karl,
On Jan 6, 2011, at 7:14 AM, Karl Wright wrote:
Answering on Grant's behalf, the ManifoldCF artifact contains both
source and binary, and the KEYS and CHANGES.txt files are within the
artifact, as seems to be standard Apache practice.
Well I won't say it's standard Apache practice in
I am happy to provide clear-text versions of KEYS and CHANGES.txt if
that is what you require. I've just never seen any other Apache
project that did that.
As for whether there should be separate source and binary
distributions, bear in mind that a binary-only distribution of
ManifoldCF makes
The download size of sources alone is about 32M for each .zip/.tar.gz.
I can't upload CHANGES.txt or KEYS to people.apache.org right now
because of a firewall restriction, so I've attached the files for your
convenience.
Karl
On Thu, Jan 6, 2011 at 11:10 AM, Karl Wright daddy...@gmail.com
On 6 January 2011 16:10, Karl Wright daddy...@gmail.com wrote:
I am happy to provide clear-text versions of KEYS and CHANGES.txt if
that is what you require. I've just never seen any other Apache
project that did that.
All Apache releases require pgp signatures, and the KEYS file must
contain
The key should also be added to a pgp key server.
The key has already been added to the MIT web of trust - I presume
that is what you meant?
AIUI there must be a source distribution; the binary distribution is optional.
The consumer should not be forced to download the binary distribution
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is appreciated.
You can find the
On 6 January 2011 17:34, Karl Wright daddy...@gmail.com wrote:
The key should also be added to a pgp key server.
The key has already been added to the MIT web of trust - I presume
that is what you meant?
Yes, I meant that the key should be retrievable from a pgp key server
- which it is
On 6 January 2011 18:03, sebb seb...@gmail.com wrote:
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra
Very well; we will discontinue all binary distributions.
That's not what I said.
You can have a binary distribution if you wish, but there must be a
source distribution.
As I said before, it makes no sense to distribute ManifoldCF binaries
without complete sources. So we could (I suppose)
Also, the NOTICE and LICENSE files don't seem to be quite right.
The NOTICE file is for required notices only; so for example there is
no need to mention other ASF projects.
The LICENSE file references JUnit, which does not need to be
distributed, so is not needed in the LICENSE.
These
The md5 hash file has an odd syntax, which makes it harder to use with
automated checking tools.
apache-manifoldcf-0.1-incubator.zip: A3 3E 0A 9F 58 94 DC 64 F7 B3 ED DB 63
2E
CB EF
The standard format is
a33e0a9f5894dc64f7b3eddb632ecbef
On 6 January 2011 18:23, Karl Wright daddy...@gmail.com wrote:
Very well; we will discontinue all binary distributions.
That's not what I said.
You can have a binary distribution if you wish, but there must be a
source distribution.
As I said before, it makes no sense to distribute
The whole question of ease-of-use is what drove this packaging
arrangement. I was told it was unacceptable to not have a working
example out of the box that could be executed in a single line. Build
and execution Instructions which involve obtaining a couple of dozen
jars from other places do
Hi Karl,
On Jan 6, 2011, at 10:49 AM, Karl Wright wrote:
The whole question of ease-of-use is what drove this packaging
arrangement. I was told it was unacceptable to not have a working
example out of the box that could be executed in a single line. Build
and execution Instructions which
It's unacceptable to not release software according to Apache guidelines.
There's some flexibility in those guidelines (whether to include a binary
release or not, whether to include jar files in a distro or use Maven, etc.),
and then there's not (must include a source release; must have a
On Thu, Jan 6, 2011 at 1:12 PM, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is appreciated.
You can find the
Hi Karl,
It's all the same license. The dependent jars are copied into the
appropriate target locations by the build process. So without the
build, you have one copy of each dependent jar.
Cool, thanks.
It's a huge issue everywhere. Your release will be mirrored around the world
using
Where is the SVN tag for the release?
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is
Since this is a release candidate, and the release has not yet been
signed off, the tag has not yet been created. There is, however, a
release branch, from which the release candidates get built. When the
sign off occurs, the tag will be created from that branch.
Karl
On Thu, Jan 6, 2011 at
On 6 January 2011 20:06, Karl Wright daddy...@gmail.com wrote:
Since this is a release candidate, and the release has not yet been
signed off, the tag has not yet been created. There is, however, a
release branch, from which the release candidates get built. When the
sign off occurs, the tag
Yes, that is the correct branch.
If there is an official Apache tagging strategy, I'm fine with that.
Heretofore I've been using the MetaCarta release tagging strategy,
which was partly gated on a restriction in the MetaCarta svn setup
that prevented tags from being renamed or deleted. Your
The failure to build occurs because the directory it is complaining
about doesn't seem to exist after the zip is unpacked. The directory
is empty at the time of the build. It's not clear whether the problem
is the built zip itself or the way you are unpacking it. I'll need to
look into this
On 6 January 2011 20:41, Karl Wright daddy...@gmail.com wrote:
The failure to build occurs because the directory it is complaining
about doesn't seem to exist after the zip is unpacked. The directory
is empty at the time of the build. It's not clear whether the problem
is the built zip
Just noticed that there are a lot of source files without AL headers.
The RAT tool can detect these for you.
Also, there should normally be a DISCLAIMER file at the top-level of
archives and SVN trees.
It's simpler to have this in a separate file, which can then just be
deleted upon graduation.
Karl Wright wrote:
Very well; we will discontinue all binary distributions.
One major problem will therefore be that we rely on Apache Forrest to
build the documentation pages. Forrest requires Java 1.5. The
availability of documentation in the release will therefore depend on
the
We've been using the RAT tool. The files without headers are in part
Microsoft project files, which cannot have headers added without
breaking them. Also, we build JSON sources, which are licensed with
an accepted JSON license that RAT does not recognize.
I've captured a lot of these exceptions
On 6 January 2011 22:38, Karl Wright daddy...@gmail.com wrote:
We've been using the RAT tool.
In which case it would be helpful to provide the RAT report(s).
The files without headers are in part
Microsoft project files, which cannot have headers added without
breaking them. Also, we build
The .cs files are maintained by Visual Studio and you cannot change
the format if you want them to keep working. Same with the .map file.
I will add them to exclusions for the rat target
The .tld's were taken from Apache Tomcat, but did not include Apache
headers. I am not sure what I should
They were downloaded from the jakarta standard taglibs 1.1.2, from this URL:
http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi
The project was folded into tomcat, but I simply used the tag
libraries from the separately-bundled artifact. It turns out that the
Apache headers
The RAT report after these changes looks good except for two files,
which come from the skins in the site:
[rat:report] Unapproved licenses:
[rat:report]
[rat:report]
C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skins/common/xslt/html/split.xsl
[rat:report]
78 matches
Mail list logo
