2008/9/16 Emmanuel Lecharny [EMAIL PROTECTED]:
The problem with a release injected in maven is that it will be there
forever. If a release has some problems (IP issues, etc), you can't remove
it from maven, as some projects might depend on it, and the users will
immediately carpet bomb the
Hi,
On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting [EMAIL PROTECTED] wrote:
Please vote on accepting or rejecting this policy change! This
majority vote is open for a week and only votes from the Incubator PMC
members are binding.
I am extending the vote period for another week as there is
Hi Henning,
thanks for your vote.
Here are a few answers to your comments:
Testing is currently performed by running the two example applications provided
with the distribution, which contain various tasks. Each of them is run once
for each supported database, and the logs are checked. This
On Wed, Sep 17, 2008 at 7:11 AM, Henning Schmiedehausen
[EMAIL PROTECTED] wrote:
Branch and experiment. FtpServer does not need to be one-dimensional.
You will probably not release this code to an unsuspecting public
anyway, will you? ;-)
I wouldn't know about unsuspecting :-) Yes, I would
Niklas Gustavsson wrote:
On Wed, Sep 17, 2008 at 7:11 AM, Henning Schmiedehausen
[EMAIL PROTECTED] wrote:
Branch and experiment. FtpServer does not need to be one-dimensional.
You will probably not release this code to an unsuspecting public
anyway, will you? ;-)
I wouldn't know about
On Wed, Sep 17, 2008 at 6:14 AM, Noel J. Bergman [EMAIL PROTECTED] wrote:
I don't know of anybody who goes to actual users and tell
them here you go, unzip that stuff there, set your
JAVA_HOME and your MAVEN_HOME properly, execute 'mvn install'
and once all test cases pass you're golden.
LOL
On 10-Sep-08, at 8:34 AM, Jukka Zitting wrote:
Hi,
We've had a number of long discussions about the incubating projects
using the central Maven repository to distribute their releases. The
current policy is that incubating releases should not go to there. The
related discussion threads have
+1
On 10-Sep-08, at 8:34 AM, Jukka Zitting wrote:
Hi,
We've had a number of long discussions about the incubating projects
using the central Maven repository to distribute their releases. The
current policy is that incubating releases should not go to there. The
related discussion threads
I voted +1, but I personally think the vote is kind of irrelevant.
FACT: The stuff in the incubator repo are Apache releases. They had the 3
binding +1 votes from the incubator IPMC members. They are releases.
FACT: The stuff in the incubator repo is all Apache Licensed artifacts.
On Wed, Sep 17, 2008 at 2:17 AM, Bertrand Delacretaz [EMAIL PROTECTED]
wrote:
On Wed, Sep 17, 2008 at 6:14 AM, Noel J. Bergman [EMAIL PROTECTED] wrote:
I don't know of anybody who goes to actual users and tell
them here you go, unzip that stuff there, set your
JAVA_HOME and your
Matthieu Riou wrote:
Exactly - that's when actual users are software developers, which is
the case for many of our projects.
Precisely. And those should be aware of disclaimers if those serve any
purpose.
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the
Dan,
It is a policy matter, not a legal one. And enforcing artifact signing
would address this and other crucial, fatal, flaws in Maven's repository
management.
I still maintain that unless Maven makes swift strides to enforce signing,
the ASF should ban the use of the Maven repository for all
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however, suggest that pressure be put on Maven to enforce
signing.
--- Noel
Noel J. Bergman wrote:
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however, suggest that pressure be put on Maven to enforce
Jukka Zitting wrote:
Hi,
On Fri, Sep 12, 2008 at 12:42 AM, Eddie Epstein [EMAIL PROTECTED] wrote:
The *UIMA* project dev-list vote to release *UIMACPP* was 6 +1's, and no
other votes; see the vote here: http://markmail.org/message/dmf2wk6zzq7dlsft
Hi Noel,
If the problem your trying to solve with artifact signing is detect
and reject malicious artifacts that have been deployed to hacked
repository, then there is a simpler fix that is available today. Just
use the checksum plugin that I described here:
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly aware of
and
agree to use of Incubator artifacts.
Maven doesn't *hide* anything, it simply makes requests via http. You
can use your browser to pull stuff from
Ah! i was just waiting for this response :)
I don't see any patches yet to help out
-- dims
On Wed, Sep 17, 2008 at 2:36 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly
On Wed, Sep 17, 2008 at 1:19 PM, Noel J. Bergman [EMAIL PROTECTED] wrote:
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly aware of and
agree to use of Incubator artifacts.
We I think this could easily be fixed
Just to clarify things, the artefact published on the apache maven
repository are signed (well, to be exact, most are signed. See [1]
for the current status)
However, maven doesn't [yet] validate the signature when downloading
the artefacts (ivy neither). See [2]
[1]
[
https://issues.apache.org/jira/browse/INCUBATOR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631893#action_12631893
]
Ryan McKinley commented on INCUBATOR-77:
Unless someone else is working on this,
[
https://issues.apache.org/jira/browse/INCUBATOR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631911#action_12631911
]
Grant Ingersoll commented on INCUBATOR-77:
--
Note, I created issues in both
[
https://issues.apache.org/jira/browse/INCUBATOR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631925#action_12631925
]
Ryan McKinley commented on INCUBATOR-77:
For reference, here are the issues:
On Wed, Sep 17, 2008 at 11:36 AM, Brian E. Fox [EMAIL PROTECTED]wrote:
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly aware of
and
agree to use of Incubator artifacts.
Maven doesn't *hide* anything, it simply
Hi,
On Wed, Sep 17, 2008 at 7:34 PM, Noel J. Bergman [EMAIL PROTECTED] wrote:
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus.
IMHO this
On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
I voted +1, but I personally think the vote is kind of irrelevant.
[...]
Thus:
If the central maven repository maintainers (Maven PMC) decide to put
incubator artifacts into their repository without a click through this is
On Wed, 2008-09-17 at 13:19 -0400, Noel J. Bergman wrote:
I still maintain that unless Maven makes swift strides to enforce signing,
the ASF should ban the use of the Maven repository for all ASF projects, and
go so far as to remove all of our artifacts.
sorry, but that is ridiculous. That
On Wed, 2008-09-17 at 10:31 +0200, Rainer Döbele wrote:
Hi Henning,
thanks for your vote.
Here are a few answers to your comments:
Testing is currently performed by running the two example applications
provided with the distribution, which contain various tasks. Each of them is
run
Something else that needs to be considered is what happens if
someone's private key in the web of trust gets compromised?
Once compromised. malicious releases could get re-rolled, and deployed.
I think GPG would be good to validate an initial dependency/checksum
for an artifact, but after that
On Wed, Sep 17, 2008 at 6:34 PM, Noel J. Bergman [EMAIL PROTECTED] wrote:
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however,
Henning Schmiedehausen wrote:
On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
I voted +1, but I personally think the vote is kind of irrelevant.
Thus:
If the central maven repository maintainers (Maven PMC) decide to put
incubator artifacts into their repository without a click
Bill,
Since you are stating facts. Let's make it clear that when someone
download the artifacts, there's a good chance that you will see the
disclaimers. With maven, we don't. That's the hiccup that caused the
policy in place right now and the bruising battle now being fought is
caused by the
true. these are the reasons i voted the way i did. basically throwing
up my hands saying nothing much we can do other than just continue
pissing off our users...I am sure the numerous maven pmc members here
are taking note, but are probably waiting for patches :)
-- dims
On Wed, Sep 17, 2008 at
William A. Rowe, Jr. wrote:
Noel J. Bergman wrote:
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however, suggest that pressure
On Wed, 2008-09-17 at 20:14 -0500, William A. Rowe, Jr. wrote:
Henning Schmiedehausen wrote:
On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
I voted +1, but I personally think the vote is kind of irrelevant.
Thus:
If the central maven repository maintainers (Maven PMC) decide
I noticed that the apache.org/dist/incubator distribution area
had no header file to explain itself. Hence each mirror was
missing that information.
I created it now, modelling it on other ASF distribution areas.
This now has the disclaimer from
36 matches
Mail list logo
