You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/09/24 15:40:46 UTC
[RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi,
On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Please vote on accepting or rejecting this policy change!
The vote ends with the following 15 +1, 12 -1, and one 0 binding votes.
+1 Bertrand Delacretaz
+1 Brett Porter
+1 Bruce Snyder
+1 Davanum Srinivas
+1 Doug Cutting
+1 Guillaume Nodet
+1 James Strachan
+1 Jason van Zyl
+1 Jeffrey Genender
+1 Jukka Zitting
+1 Martin Dashorst
+1 Niall Pemberton
+1 Roland Weber
+1 Upayavira
+1 William Rowe
0 Thomas Fischer
-1 Ant Elder
-1 Craig Russell
-1 Emmanuel Lecharny
-1 Henning Schmiedehausen
-1 Jim Jagielski
-1 Justin Erenkrantz
-1 Kevan Miller
-1 Matt Hogstrom
-1 Matthieu Riou
-1 Noel J. Bergman
-1 Paul Querna
-1 Will Glass-Husain
The following eight +1 and one -1 non-binding votes were also cast:
+1 Assaf Arkin
+1 Eelco Hillenius
+1 Dan Diephouse
+1 Daniel Kulp
+1 Felix Meschberger
+1 Les Hazlewood
+1 Niklas Gustavsson
+1 Stephen Duncan Jr
-1 Sebastian Bazley
This is a slight majority (of binding votes) for accepting the
proposed change, but given the clear lack of consensus and the
concerns voiced about that, I unfortunately need to conclude that this
issue should be tabled until better consensus is reached.
The main impression I got from the related discussion is that the main
concern is not that much the security or transparency of the Maven
repository but rather the status of incubating releases in general.
Are incubating releases official releases of the ASF? Does the ASF
"endorse" these releases, and what does that endorsement mean? How
strong disclaimers are needed and what level of explicit
acknowledgement from users is required? Until we have a clearer policy
on what we actually require of incubating releases and their
distribution, it seems premature to debate whether the Maven
repository meets those requirements.
So, before reopening this release distribution issue, I would expect
us to clarify the policy on incubating releases.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by David Crossley <cr...@apache.org>.
William A. Rowe, Jr. wrote:
> David Crossley wrote:
> > William A. Rowe, Jr. wrote:
> >
> > [snip]
> >> I liked the way you put the question; it's not up to incubator project to
> >> set the rules for Maven. If the maven PMC decides that these incubator
> >> releases don't belong in the primary repository, that's their call. But
> >> this vote makes clear that the incubator has nothing to say about an
> >> artifact's distribution once the release vote is finalized.
> >
> > Other than this important statement from
> > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
> > "Releases for podling MUST be distributed through
> > www.apache.org/dist/incubator/podling"
>
> Exactly. This doesn't state that "Releases for podling must be EXCLUSIVELY
> distributed through www.a.o/dist/incubator/podling".
>
> It was a statement to quit posting the release artifacts in the un-mirrored
> corners, and that these are the first initial official release paths.
> Previously these were scattered throughout on un-mirrored servers in a
> fairly haphazard way.
>
> So they must be shipped through /dist/incubator/podling or there is no
> assertion that they are releases. Once there, they travel unassisted
> to dozens of mirror servers and on to other locations and uses.
We are getting to the nub of it.
This is beyond any particular build system.
We have an infrastructure already, with our mirror system.
If every project would distribute not only their primary
source releases from there, but also secondary artefacts
(e.g. jars, poms, ivys, zips, whatever). These all would
have signatures and checksums.
Then any build system can rely on that distribution
mirror infrastructure.
There is a beautiful gem with our mirror system that
i reckon is underutilised. It can generate an xml list
of the preferred mirrors. Therefore it can be automated.
Over the last few days i have been taking some steps
to solve our Apache Forrest plugin distribution system,
and use the mirror system to do it. Made good progress
on that with an Ant-based build.
(If someone wants a demo of the core part then i can
stick it in my home directory.)
Anyway my point is that any build system (Maven, Ivy,
Ant, etc.) can rely on our mirror infrastructure if
we populate it in a consistent manner. They can replicate
it from the official source to maintain their own mirrors.
We don't need to worry.
In the Incubator case, we do need to find ways
to make people aware of what they are using.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
David Crossley wrote:
> William A. Rowe, Jr. wrote:
>
> [snip]
>> I liked the way you put the question; it's not up to incubator project to
>> set the rules for Maven. If the maven PMC decides that these incubator
>> releases don't belong in the primary repository, that's their call. But
>> this vote makes clear that the incubator has nothing to say about an
>> artifact's distribution once the release vote is finalized.
>
> Other than this important statement from
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
> "Releases for podling MUST be distributed through
> www.apache.org/dist/incubator/podling"
Exactly. This doesn't state that "Releases for podling must be EXCLUSIVELY
distributed through www.a.o/dist/incubator/podling".
It was a statement to quit posting the release artifacts in the un-mirrored
corners, and that these are the first initial official release paths.
Previously these were scattered throughout on un-mirrored servers in a
fairly haphazard way.
So they must be shipped through /dist/incubator/podling or there is no
assertion that they are releases. Once there, they travel unassisted
to dozens of mirror servers and on to other locations and uses.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by David Crossley <cr...@apache.org>.
William A. Rowe, Jr. wrote:
> Jukka Zitting wrote:
> >
[snip]
>
> > Are incubating releases official releases of the ASF?
>
> Yes. Otherwise they must be removed from ASF servers.
> There's no middle ground.
>
[snip]
>
> > How strong disclaimers are needed and what level of explicit
> > acknowledgement from users is required?
>
> how much more explicit do you want? Well, we've added that a disclaimer
> in the package (not a click-through requirement) that this is an incubating
> artifact, and each has a naming convention of {podling}-incubating.
Good. Recently i also added a disclaimer to the top-level
of our mirror system www.apache.org/dist/incubator/
and proposed [1] that each podling do the same, i.e. follow
the ASF release guidelines. This assists the people who
reach the mirrors by other means. It tries to explain and
then redirect them to each podling's download page where
they should have other disclaimers and encouragement to
assist the project to graduate.
[1] header notices for mirrors a.o/dist/incubator
http://marc.info/?t=122171287100004
Trying to re-direct this aspect of the discussion to
that thread.
[snip]
> I liked the way you put the question; it's not up to incubator project to
> set the rules for Maven. If the maven PMC decides that these incubator
> releases don't belong in the primary repository, that's their call. But
> this vote makes clear that the incubator has nothing to say about an
> artifact's distribution once the release vote is finalized.
Other than this important statement from
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
"Releases for podling MUST be distributed through
www.apache.org/dist/incubator/podling"
-David
> Please remember the earliest examples, where IBM distributed the very
> earliest Geronimo incubating releases through other channels, as was
> their right do so. Let's call this decision on "Allow extra release
> distribution channels" approved 15:12, let people who want to use
> the Maven channel take this thread up with Maven folks, and let this
> thread die at last.
>
> Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Sep 24, 2008 at 2:21 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Jukka Zitting wrote:
> >> Of which we have two; released, or not released, and that's a product
> >> of oversight and a [VOTE]. There are no magical in-betweens.
> >
> > As evidenced by this vote this is hardly the consensus. See comments
> > like "incubating releases to be treated as full Apache releases" or
> > "incubator artifacts are distributed the same way as 'regular'
> > artifacts". There is clearly a widely held feeling that incubating
> > releases are different than "normal" ASF releases.
>
> Can you point me to any document which defines the code, social, and/or
> legal difference between them? If not I'd humbly suggest we are still
> stumbling over fud.
>
I'm getting mildly annoyed by your insistence. We can all disagree and it's
fine, hopefully the IPMC is mature enough to find a way to solve this (like
Emmanuel proposed for example). But I don't really understand why you keep
on pressing Jukka and tried to declare the vote as irrelevant.
Matthieu
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jukka Zitting wrote:
>> Of which we have two; released, or not released, and that's a product
>> of oversight and a [VOTE]. There are no magical in-betweens.
>
> As evidenced by this vote this is hardly the consensus. See comments
> like "incubating releases to be treated as full Apache releases" or
> "incubator artifacts are distributed the same way as 'regular'
> artifacts". There is clearly a widely held feeling that incubating
> releases are different than "normal" ASF releases.
Can you point me to any document which defines the code, social, and/or
legal difference between them? If not I'd humbly suggest we are still
stumbling over fud.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Sep 25, 2008 at 5:15 AM, Doug Cutting <cu...@apache.org> wrote:
> This is the crux of the issue.
> Do releases from the Incubator project differ from those of other projects?
The people who created the Incubator should be able to answer this
question. IMHO (I didn't vote), what we all think for our convenience
shouldn't be muddled up with "What was the intention of the
Incubator?" from the Devil's Mouth (The people who constructed this
some 5-6 years ago).
There are voices here saying;
Incubator releases are just another release from ASF.
With RAT and highly concerned PMC individuals, the Incubator releases
are at least as legally safe as any other ASF project.
whereas some others are on the track of;
ASF does not "endorse" Incubator releases.
So, IF we could all agree that the above is somewhat the essence or
crux of the issue, and mostly true, then we are looking at "What does
'endorse' mean?". Well, if Incubator should really by totally legally
safe, then I think the Mentors+PMC really need to step up to make that
a reality, and the "endorsement" will only come down to; "ASF does not
yet think this community will make it." But that is not a guarantee
for any of our project communities anyway...
So, that leaves me with a simple conclusion; The Incubator is a
training ground for incoming projects.
We don't let the podlings move on until they are "fit" and understand
what ASF is all about. While being a podling, they are effectively a
subproject in Incubator (another umbrella ;-) ), where the PMC ensures
that all releases are legally sane, and that the Incubator PMC is the
community that has the ultimate responsibility of releases. HENCE,
releases should be treated no differently... no "-incubating" and no
special distro channels needed.
BUT, that also means; We should be a lot more concerned over projects
arriving, and not blindly accept whatever sounds cool.
Well, I hate my own reasoning as I think Incubator is missing the mark
and becoming an Elephant in the Fridge (don't ask)...
bah!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by Doug Cutting <cu...@apache.org>.
Jukka Zitting wrote:
> There is clearly a widely held feeling that incubating
> releases are different than "normal" ASF releases.
This is the crux of the issue. I fail to see how they are fundamentally
different. Releases and the release process is one of the most
standardized things in the ASF: 3+1 PMC votes, distributed on
www.apache.org/dist, etc. Do releases from the Incubator project differ
from those of other projects? I've always thought felt that the
Incubator is just another project, one that specializes in nursing new
projects to maturity. But it has no special privileges or
responsibilities, does it?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Sep 24, 2008 at 8:17 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Jukka Zitting wrote:
>> This is a slight majority (of binding votes) for accepting the
>> proposed change, but given the clear lack of consensus and the
>> concerns voiced about that, I unfortunately need to conclude that this
>> issue should be tabled until better consensus is reached.
>
> Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL].
> A decision, however frustrating, has been reached.
>From http://www.apache.org/foundation/voting.html, on majority votes:
If the number of votes seems too small to be representative of
a community consensus, the issue is typically not pursued.
We had 28 binding votes out of 85 and the difference in result was
just three votes, which in my opinion is "too small to be
representative".
> I suspect some would prefer the choice against their preference just be
> implemented, over having this thread persist ad infinitum.
If Noel or other people who voted against the proposal feel that the
result is representative, then I will implement the proposed change
>> The main impression I got from the related discussion is that the main
>> concern is not that much the security or transparency of the Maven
>> repository but rather the status of incubating releases in general.
>
> Of which we have two; released, or not released, and that's a product
> of oversight and a [VOTE]. There are no magical in-betweens.
As evidenced by this vote this is hardly the consensus. See comments
like "incubating releases to be treated as full Apache releases" or
"incubator artifacts are distributed the same way as 'regular'
artifacts". There is clearly a widely held feeling that incubating
releases are different than "normal" ASF releases.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi All,
FWIW in my experience, the release process is a key driver for a podling
community to get it's collective act together.
On Qpid, we've done 3 major releases now. Until we worked towards the first,
one couldn't guarantee that the code would compile from trunk every day. Our
project really took shape during this process, and it was a good way to
start getting a handle on the Apache Way.
Having a focus, in the shape of a release, is a really useful way to move a
community towards a clear goal. Even better, it forces the podling to agree
targets (JIRAs etc) and work together to achieve them in a bounded way.
The other major plus is that iirc it took about 6 weeks of to+fro on our
first release to get a viable RC out (with all the necessary bits etc). The
process gets easier each time (at least the Apache bits do). On incubator
projects get oversight etc while all this happens and so they get better at
doing it, fairly early on.
In my view, without releases there wouldn't be any podling projects (as
Aidan suggested earlier).
Trust me, there are plenty of incentives to graduate :-)
Hth,
Marnie
On Tue, Oct 7, 2008 at 5:18 PM, Henning Schmiedehausen <
henning@schmiedehausen.org> wrote:
>
> On Mon, 2008-10-06 at 13:45 -0500, William A. Rowe, Jr. wrote:
> > How about a brand new idea?
> >
> > Lay down a Milestone-style chart of what it takes to operate as an ASF
> > project. Demonstrate community of meritocracy, add committers or ppmc
> > members based on contributions, complete IP review, and then... and only
> > then... they hit the release milestone. One or two releases later, they
> > are ejected from the Incubator - either to the target PMC or as a TLP.
>
> While I like that idea, it is hard for a podling that comes from a
> corporate environment (where the initial committer base is basically a
> development team) to build a developer community without a release.
>
> Giving a podling a defined exit strategy (e.g. "Three incubator
> releases") is nice, but it will be subverted by projects doing "rc,
> alpha and beta" releases ("Oh no, that is not our second release, this
> is 2.0-alpha-1" Which is followed by 2.0-alpha-2 up to 2.0-alpha-8, then
> -beta-1 and so on).
>
> Then again, some podlings could use a kick in their collective ass to do
> at least one release (Hello Shindig).
>
> Ciao
> Henning
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Allow incubator releases? [was: way too wordy]
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Mon, 2008-10-06 at 13:45 -0500, William A. Rowe, Jr. wrote:
> How about a brand new idea?
>
> Lay down a Milestone-style chart of what it takes to operate as an ASF
> project. Demonstrate community of meritocracy, add committers or ppmc
> members based on contributions, complete IP review, and then... and only
> then... they hit the release milestone. One or two releases later, they
> are ejected from the Incubator - either to the target PMC or as a TLP.
While I like that idea, it is hard for a podling that comes from a
corporate environment (where the initial committer base is basically a
development team) to build a developer community without a release.
Giving a podling a defined exit strategy (e.g. "Three incubator
releases") is nice, but it will be subverted by projects doing "rc,
alpha and beta" releases ("Oh no, that is not our second release, this
is 2.0-alpha-1" Which is followed by 2.0-alpha-2 up to 2.0-alpha-8, then
-beta-1 and so on).
Then again, some podlings could use a kick in their collective ass to do
at least one release (Hello Shindig).
Ciao
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Tue, Oct 7, 2008 at 2:45 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>
>> How about a brand new idea?
>>
>> Lay down a Milestone-style chart of what it takes to operate as an ASF
>> project. Demonstrate community of meritocracy, add committers or ppmc
>> members based on contributions, complete IP review, and then... and only
>> then... they hit the release milestone. One or two releases later, they
>> are ejected from the Incubator - either to the target PMC or as a TLP.
>>
>> So releases would reflect the project is probably ready to graduate, the
>> only difference would be that the incubator PMC wants to see this done
>> right before calling the podling baked.
>
> Works for me, although you say nothing about whether that release is
> an ASF release or not. IMHO, it is an Incubator PMC release, just like
> any other PMC operated umbrella project. ;-)
Right - I pointed out earlier that it's a binary condition at the ASF, either
released or not released. I'm not even picky if they would rather release an
alpha or beta (not a bad idea if they followed your org.apache.incubator.foo
naming convention) or wanted to call it a GA/Gold release. That wasn't my
point, it was simply that ratifying their release would be the "last checkmark"
on the steps to graduation.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Oct 7, 2008 at 2:45 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> How about a brand new idea?
>
> Lay down a Milestone-style chart of what it takes to operate as an ASF
> project. Demonstrate community of meritocracy, add committers or ppmc
> members based on contributions, complete IP review, and then... and only
> then... they hit the release milestone. One or two releases later, they
> are ejected from the Incubator - either to the target PMC or as a TLP.
>
> So releases would reflect the project is probably ready to graduate, the
> only difference would be that the incubator PMC wants to see this done
> right before calling the podling baked.
Works for me, although you say nothing about whether that release is
an ASF release or not. IMHO, it is an Incubator PMC release, just like
any other PMC operated umbrella project. ;-)
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>
>> Drop any pretense that the incubator has a say
>> over the already-done code releases, and we can seriously start the real
>> discussion, which would have been "motivating projects to graduate" if we
>> hadn't wasted several hundred posts on a silly topic.
>
> Uhhh... I might misunderstand your English here (mine ain't that refined);
> Are you suggesting that the Incubator PMC has no say over code
> releases of podlings?
Pretty much, that's it. The code is voted released by the Incubator PMC
under the Apache License. The ASF places exactly those AL limits on the
code (very few) and enforces those limits, alone.
To have a successful release vote, we have lots of extra rules, such as
how the Podling vote happens, the IPMC vote ratifies it, rat and other
methods validate that the copyrights, licenses and such line up, that
there is a DISCLAIMER in the package, etc. If preconditions don't happen
they won't have the successful release vote they wanted.
The Incubator PMC has a strong say over what appears on incubator.a.o/*
pages, what is added to or revoked from www.a.o/dist/incubator/*, and so
forth and so on. But that's the extent. Postconditions that aren't in
the license don't exist. You can't say "Commercial use is disallowed",
and so forth.
> My stance is still; Releases from the Incubator are ASF releases of
> code, no different than another PMC. IMHO, the disclaimers are not
> helping anyone, not the podling, not the IPMC, not the downstream
> projects, not the public, not the repository management, not the tool
> chain...
> So, I still think; WTFing Point?
Well we could drop the DISCLAIMER requirement, that's another thread
entirely :)
> Now, we can deal with such situation in two possible ways;
>
> * Accept that projects eventually dies, and that everyone downstream
> needs to deal with that, and that downstream users are capable of
> basic SWOT analysis and let podlings release as much as they want. I
> would like (as a Maven user) the <groupId> in Maven artifacts to be
> org.apache.incubator.<podling> until the graduation occurs.
>
> * Not accept podlings to release code. Possibly having the "final
> act" of the podling to do a release, which effectuates the graduation.
>
> I am Ok with either of these, since I think that downstream users
> ain't stupid and more capable than I think we give them credit for.
How about a brand new idea?
Lay down a Milestone-style chart of what it takes to operate as an ASF
project. Demonstrate community of meritocracy, add committers or ppmc
members based on contributions, complete IP review, and then... and only
then... they hit the release milestone. One or two releases later, they
are ejected from the Incubator - either to the target PMC or as a TLP.
So releases would reflect the project is probably ready to graduate, the
only difference would be that the incubator PMC wants to see this done
right before calling the podling baked.
WDYT?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Oct 6, 2008 at 8:22 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> * Not accept podlings to release code. Possibly having the "final
> act" of the podling to do a release, which effectuates the graduation.
>
> I am Ok with either of these, since I think that downstream users
> ain't stupid and more capable than I think we give them credit for.
>
Not being able to release code from the incubator will have one or more of
three effects:
1) podlings will find building a community massively more difficult.
2) podlings will push releases through non-ASF routes, bypassing the IPMC
entirely. Some projects are already doing this due to not being able to push
to central.
3) potential podlings will ignore the incubator and the ASF entirely.
The first will prolong a podlings stay in the incubator due to diversity
issues. The second will stop podlings getting experience with things like
LICENSE, NOTICE etc, which are surprisingly difficult to get right. The
third is just undesireable.
As for making the incubator a less comfortable place for podlings, waiting
weeks to get a new committer approved and almost a month for a release to be
approved are pretty uncomfortable experiences for a project.
They are also things which actively hinder a project graduating. The focus
seems to be on finding bigger, stickier sticks.
Perhaps a more effective approach would be, as suggested elsewhere, to
require a podling to report on it's progress towards graduation in the board
reports. If unsatisfactory progress is being made, then the mentors should
get involved.
If that isn't sufficent, perhaps podlings should not use the Apache brand in
supporting materials? Changing code layout, distribution channels etc is a
substantial amount of work, but having to refer to it as Frobnicator instead
of Apache Frobnicator gives some incentive to podlings without imposing an
additional burden on them.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
Re: Allow incubator releases? [was: way too wordy]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Drop any pretense that the incubator has a say
> over the already-done code releases, and we can seriously start the real
> discussion, which would have been "motivating projects to graduate" if we
> hadn't wasted several hundred posts on a silly topic.
Uhhh... I might misunderstand your English here (mine ain't that refined);
Are you suggesting that the Incubator PMC has no say over code
releases of podlings?
My stance is still; Releases from the Incubator are ASF releases of
code, no different than another PMC. IMHO, the disclaimers are not
helping anyone, not the podling, not the IPMC, not the downstream
projects, not the public, not the repository management, not the tool
chain...
So, I still think; WTFing Point?
Now, we can deal with such situation in two possible ways;
* Accept that projects eventually dies, and that everyone downstream
needs to deal with that, and that downstream users are capable of
basic SWOT analysis and let podlings release as much as they want. I
would like (as a Maven user) the <groupId> in Maven artifacts to be
org.apache.incubator.<podling> until the graduation occurs.
* Not accept podlings to release code. Possibly having the "final
act" of the podling to do a release, which effectuates the graduation.
I am Ok with either of these, since I think that downstream users
ain't stupid and more capable than I think we give them credit for.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases?
Posted by J Aaron Farr <fa...@apache.org>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Niclas Hedhman wrote:
>> I will support the "initial intent" of no releases out of Incubator.
>
> Which would work, except for the fact that the incubator decided it's a good
> idea to have podlings demonstrate how releases work in a meritocracy. Sure
> they've grokked vetoes over code, but the majority-vote release schema is
> nearly at odds with that. It's good that they demonstrate the entire cycle
> of envisioning ... creating ... collecting ... releasing code as a community.
+1
> So this is a better schema. Drop any pretense that the incubator has a say
> over the already-done code releases, and we can seriously start the real
> discussion, which would have been "motivating projects to graduate" if we
> hadn't wasted several hundred posts on a silly topic.
This is simple, people. This is what mentors are for. When the PMC
submits the board report, someone should mark the ones that need
motivating and task the mentors with doing so. If the mentors can't
(which is fine, we're all volunteers here), then delegate to someone
who can.
As for motivation, escaping the neverending threads on this mailing
list should be encouragement enough.
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Sat, Oct 4, 2008 at 12:45 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>> Color me confused again, but during setup and formation of the Incubator,
>> a podling had to graduate before doing a release. It was rather well
>> established before this rule was modified, but it seems that this change
>> resulted in a number of different interpretations, some of which aren't
>> compatible with the ASF license.
>
> I will support the "initial intent" of no releases out of Incubator.
Which would work, except for the fact that the incubator decided it's a good
idea to have podlings demonstrate how releases work in a meritocracy. Sure
they've grokked vetoes over code, but the majority-vote release schema is
nearly at odds with that. It's good that they demonstrate the entire cycle
of envisioning ... creating ... collecting ... releasing code as a community.
So this is a better schema. Drop any pretense that the incubator has a say
over the already-done code releases, and we can seriously start the real
discussion, which would have been "motivating projects to graduate" if we
hadn't wasted several hundred posts on a silly topic.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Oct 4, 2008 at 12:45 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Color me confused again, but during setup and formation of the Incubator,
> a podling had to graduate before doing a release. It was rather well
> established before this rule was modified, but it seems that this change
> resulted in a number of different interpretations, some of which aren't
> compatible with the ASF license.
I will support the "initial intent" of no releases out of Incubator.
This not only puts an end to this discussion, incl Maven's stance that
policy enforcement is not their responsibility, but also accelerates
the need to graduate for podlings and hopefully make incubation
periods shorter. I would also move for requirement that Mentors remain
PMC members of the graduated project and overseas the initial
releases.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Noel J. Bergman wrote:
> William A. Rowe, Jr. wrote:
>
>> Jukka Zitting wrote:
>
>>> Does the ASF "endorse" these releases, and what does that endorsement mean?
>
>> yes...
>
> You are talking about a legal licensing matter, whereas discussion during the setup and formation of the Incubator was quite clear that Incubator releases are NOT to carry the ASF's imprimatur and unfettered brand. Hence the restrictions and disclaimer requirements.
Color me confused again, but during setup and formation of the Incubator,
a podling had to graduate before doing a release. It was rather well
established before this rule was modified, but it seems that this change
resulted in a number of different interpretations, some of which aren't
compatible with the ASF license.
Nobody is disputing the need for DISCLAIMER at the same visibility as the
LICENSE and NOTICE files. But Maven doesn't demand click through license
acceptance, so click through disclaimers make little sense, either.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
William A. Rowe, Jr. wrote:
> Jukka Zitting wrote:
> > This is a slight majority (of binding votes) for accepting the
> > proposed change, but given the clear lack of consensus and the
> > concerns voiced about that, I unfortunately need to conclude that this
> > issue should be tabled until better consensus is reached.
> Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL].
> A decision, however frustrating, has been reached.
Actually, Jukka's approach is correct. Greg Stein has discussed this sort of situation on multiple occasions with the same conclusion and guidance as Jukka.
> > Does the ASF "endorse" these releases, and what does that endorsement mean?
> yes...
You are talking about a legal licensing matter, whereas discussion during the setup and formation of the Incubator was quite clear that Incubator releases are NOT to carry the ASF's imprimatur and unfettered brand. Hence the restrictions and disclaimer requirements.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jukka Zitting wrote:
>
> The vote ends with the following 15 +1, 12 -1, and one 0 binding votes.
>
> This is a slight majority (of binding votes) for accepting the
> proposed change, but given the clear lack of consensus and the
> concerns voiced about that, I unfortunately need to conclude that this
> issue should be tabled until better consensus is reached.
Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL].
A decision, however frustrating, has been reached. I suspect some would
prefer the choice against their preference just be implemented, over having
this thread persist ad infinitum.
This is a contentious issue. Mostly, because the change - from pseudo
incubator release artifacts in a non-release location - into proper
releases available from www.a.o/dist/incubator/ - was never reflected
in other relevant policies. In hindsight, it's clear they were.
RAT and other methodologies helped us validate the legal aspects of
the ASF releases to the point that this is not uncomfortable anymore.
> The main impression I got from the related discussion is that the main
> concern is not that much the security or transparency of the Maven
> repository but rather the status of incubating releases in general.
Of which we have two; released, or not released, and that's a product
of oversight and a [VOTE]. There are no magical in-betweens. There
are other artifacts, of course. Snapshots are not released. Nightly
builds are not released. Source packages are our official releases.
Binaries are also released when built from release source packages.
> Are incubating releases official releases of the ASF?
Yes. Otherwise they must be removed from ASF servers. There's no
middle ground.
> Does the ASF
> "endorse" these releases, and what does that endorsement mean?
yes...
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
> How strong disclaimers are needed and what level of explicit
> acknowledgement from users is required?
how much more explicit do you want? Well, we've added that a disclaimer
in the package (not a click-through requirement) that this is an incubating
artifact, and each has a naming convention of {podling}-incubating.
Most folks main complaint is that incubator makes things more complicated
than they are or need to be. Why help to persist that modus operandi, or
subvert the decision of the list?
I liked the way you put the question; it's not up to incubator project to
set the rules for Maven. If the maven PMC decides that these incubator
releases don't belong in the primary repository, that's their call. But
this vote makes clear that the incubator has nothing to say about an
artifact's distribution once the release vote is finalized.
Please remember the earliest examples, where IBM distributed the very
earliest Geronimo incubating releases through other channels, as was
their right do so. Let's call this decision on "Allow extra release
distribution channels" approved 15:12, let people who want to use
the Maven channel take this thread up with Maven folks, and let this
thread die at last.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Will Glass-Husain <wg...@gmail.com>.
Thanks, Jukka---
Very much admire your leadership on navigating us through a decision making
process on this tricky issue. Not to mention your peaceful attitude in the
midst of much passion.
cheers,
WILL
On Mon, Oct 13, 2008 at 4:00 PM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <ju...@gmail.com>
> wrote:
> > Just a final heads up that, based on the majority vote, I will be
> > implementing this policy change tonight unless anyone wants to propose
> > an alternative policy.
>
> See revision 704280.
>
> It is now OK for podlings to deploy approved releases (that satisfy
> the labeling and disclaimer requirements) to the central Maven
> repository through m2-ibiblio-rsync-repository.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Brett Porter <br...@apache.org>.
On 18/10/2008, at 6:12 AM, Jason van Zyl wrote:
> Jukka,
>
> Are you intending here to just redirect poddlings distribution
> management to:
>
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/
This alternative seems the most practical suggestion, by the reasoning:
* the separation would be meaningless if both were synced
* projects out there refer to the incubator repo, probably don't want
to double up on the location they can find an artifact
* podlings that don't wish to publish to central can continue to use
the incubator repo unaffected
>
>
> Do you want me to sync the existing repository here:
>
> http://people.apache.org/repo/m2-incubating-repository/
>
> to
>
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/
>
> Or are you handling that?
>
> On 13-Oct-08, at 4:00 PM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <jukka.zitting@gmail.com
>> > wrote:
>>> Just a final heads up that, based on the majority vote, I will be
>>> implementing this policy change tonight unless anyone wants to
>>> propose
>>> an alternative policy.
>>
>> See revision 704280.
>>
>> It is now OK for podlings to deploy approved releases (that satisfy
>> the labeling and disclaimer requirements) to the central Maven
>> repository through m2-ibiblio-rsync-repository.
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
Jukka,
Are you intending here to just redirect poddlings distribution
management to:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/
Do you want me to sync the existing repository here:
http://people.apache.org/repo/m2-incubating-repository/
to
http://people.apache.org/repo/m2-ibiblio-rsync-repository/
Or are you handling that?
On 13-Oct-08, at 4:00 PM, Jukka Zitting wrote:
> Hi,
>
> On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <jukka.zitting@gmail.com
> > wrote:
>> Just a final heads up that, based on the majority vote, I will be
>> implementing this policy change tonight unless anyone wants to
>> propose
>> an alternative policy.
>
> See revision 704280.
>
> It is now OK for podlings to deploy approved releases (that satisfy
> the labeling and disclaimer requirements) to the central Maven
> repository through m2-ibiblio-rsync-repository.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Just a final heads up that, based on the majority vote, I will be
> implementing this policy change tonight unless anyone wants to propose
> an alternative policy.
See revision 704280.
It is now OK for podlings to deploy approved releases (that satisfy
the labeling and disclaimer requirements) to the central Maven
repository through m2-ibiblio-rsync-repository.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Oct 6, 2008 at 9:45 PM, Jukka Zitting <ju...@gmail.com> wrote:
> So, unless within a week from now we start seeing constructive efforts
> at forming an alternative policy (or clarifying the current
> undocumented policy) that we could vote on, I will declare this vote
> as passing and implement the proposed change based on the measured
> majority.
Just a final heads up that, based on the majority vote, I will be
implementing this policy change tonight unless anyone wants to propose
an alternative policy.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Sep 24, 2008 at 3:40 PM, Jukka Zitting <ju...@gmail.com> wrote:
> This is a slight majority (of binding votes) for accepting the
> proposed change, but given the clear lack of consensus and the
> concerns voiced about that, I unfortunately need to conclude that this
> issue should be tabled until better consensus is reached.
The followup discussion seems to be running in circles, with no clear
compromises or alternative solutions being presented. Meanwhile a few
opponents of this proposal have mentioned that their opinion has
changed and a few others that they'd accept the majority decision and
that we should move on.
So, unless within a week from now we start seeing constructive efforts
at forming an alternative policy (or clarifying the current
undocumented policy) that we could vote on, I will declare this vote
as passing and implement the proposed change based on the measured
majority.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Matthieu Riou <ma...@offthelip.org>.
On Fri, Sep 26, 2008 at 9:55 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Matthieu Riou wrote:
> >
> > I've also looked at the mentors votes, those who are basically running
> this
> > place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and
> > Jukka 4 and Doug 3. I'm not saying their votes count more than others,
> just
> > that when those people disagree, we should listen.
>
> Ahhh, and by ommission I suspect you've failed to count those who have
> mentored projects to graduation, and into the graveyard.
No omission, just laziness I must confess :) Do we have good records for
past mentorships? I've checked the project.xml but not all podlings have
listed their mentors (even the current ones, like shindig - nudge).
Matthieu
> Valuable lessons
> there, in both.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Matthieu Riou wrote:
>
> I've also looked at the mentors votes, those who are basically running this
> place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and
> Jukka 4 and Doug 3. I'm not saying their votes count more than others, just
> that when those people disagree, we should listen.
Ahhh, and by ommission I suspect you've failed to count those who have
mentored projects to graduation, and into the graveyard. Valuable lessons
there, in both.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Matthieu Riou <ma...@offthelip.org>.
On Fri, Sep 26, 2008 at 5:31 AM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Thu, Sep 25, 2008 at 12:58 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
> > If this vote doesn't pass then we need to re-write the rules to
> > define how much of a majority overturns the status quo.
>
> I'm following http://www.apache.org/foundation/voting.html and the
> express wish of our PMC chair. I think both are well founded.
>
> > Perhaps two thrids, perhaps no negative votes. If this policy isn't
> > implemented, then I think all the people who voted +1 at least deserve
> > a definition of how short we fell of passing this vote and what the bar
> is.
>
> The way I see it, we make decisions based on consensus, not numbers.
> On procedural issues we define consensus to be the majority opinion,
> but there's a clear reservation for cases where it's unclear whether
> the measured majority is representative of the whole community.
>
I've also looked at the mentors votes, those who are basically running this
place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and
Jukka 4 and Doug 3. I'm not saying their votes count more than others, just
that when those people disagree, we should listen.
Matthieu
>
> This vote has made it quite clear that we have a much deeper
> disagreement over the status of incubating releases, and that we
> really should reach some consensus on that before nailing down
> decisions on release distribution.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 25, 2008 at 12:58 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> If this vote doesn't pass then we need to re-write the rules to
> define how much of a majority overturns the status quo.
I'm following http://www.apache.org/foundation/voting.html and the
express wish of our PMC chair. I think both are well founded.
> Perhaps two thrids, perhaps no negative votes. If this policy isn't
> implemented, then I think all the people who voted +1 at least deserve
> a definition of how short we fell of passing this vote and what the bar is.
The way I see it, we make decisions based on consensus, not numbers.
On procedural issues we define consensus to be the majority opinion,
but there's a clear reservation for cases where it's unclear whether
the measured majority is representative of the whole community.
This vote has made it quite clear that we have a much deeper
disagreement over the status of incubating releases, and that we
really should reach some consensus on that before nailing down
decisions on release distribution.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Oct 3, 2008 at 10:02 PM, sebb <se...@gmail.com> wrote:
> On 03/10/2008, Bruce Snyder <br...@gmail.com> wrote:
>> On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>
>> > Moved to the thread it belongs in ...
>> >
>> > Jason van Zyl wrote:
>> >> Noel J. Bergman wrote:
>> >> > Emmanuel Lecharny wrote:
>> >>>> Better a bad decision than no decision, otherwise, soon, nobody will
>> >>>> vote anymore...
>> >>> Not really. Consider that there appears to be a clear consensus
>> >>> that if Maven were to fix the download situation, requiring that users
>> >>> approve the user of Incubator artifacts, rather than transparently use
>> >>> them, many of the -1 would be +1.
>> >
>> >> That's unlikely to happen. We're not going to be implementing policy
>> >> enforcement for you.
>> >
>> > We don't need for you to implement any "policy" other than the requirement
>> > for users to approve authorized signing keys. You simply need to implement
>> > artifact signing and mandatory authorization, which is why I've moved this
>> > to the thread Brett started for purposes of discussing signing.
>>
>>
>> I'm trying to understand why authorization should be mandatory? To my
>> knowledge, only some of the Linux package management tools (apt, port,
>> rpm, yum) verify signatures by default and in the event of failure,
>> they allow you to continue without the key verification.
>>
>> Also, I've actually spoken to a number of folks about GPG verification
>> of artifacts over the last year and very few folks actually use this
>> today.
GPG is very good for certain purposes. downstream packagers should
check signatures (and know how to do so safely) but for normal users,
checking SHA sums against the main site is probably better.
>> > Did you not see what just happened to Redhat with respect to Fedora? They
>> > take artifact security seriously. For a long time, it has appeared that
>> > Maven does not, but I am hopeful now that mandatory authorization will
>> > appear, so that I and others will not have to increase lobbying efforts to
>> > have the Maven repository closed, at least with respect to ASF projects.
>>
>>
>> Please explain what happened to RedHat with respect to Fedora. I'm not
>> familiar with the situation.
>
> http://rtfa.net/2008/08/25/fedora-package-signing-server-compromise-crls-and-trust/
>
> and
>
> http://rhn.redhat.com/errata/RHSA-2008-0855.html
silver bullets don't work :-)
single key, single point of failure, single compromise required
sounds like it was picked up by their auditing system, though
BTW the RAT auditing stuff seems to be working ok now for the
incubator releases. if anyone wants to extend auditing to other
projects, i'd be happy to help.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by sebb <se...@gmail.com>.
On 03/10/2008, Bruce Snyder <br...@gmail.com> wrote:
> On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <no...@devtech.com> wrote:
>
> > Moved to the thread it belongs in ...
> >
> > Jason van Zyl wrote:
> >> Noel J. Bergman wrote:
> >> > Emmanuel Lecharny wrote:
> >>>> Better a bad decision than no decision, otherwise, soon, nobody will
> >>>> vote anymore...
> >>> Not really. Consider that there appears to be a clear consensus
> >>> that if Maven were to fix the download situation, requiring that users
> >>> approve the user of Incubator artifacts, rather than transparently use
> >>> them, many of the -1 would be +1.
> >
> >> That's unlikely to happen. We're not going to be implementing policy
> >> enforcement for you.
> >
> > We don't need for you to implement any "policy" other than the requirement
> > for users to approve authorized signing keys. You simply need to implement
> > artifact signing and mandatory authorization, which is why I've moved this
> > to the thread Brett started for purposes of discussing signing.
>
>
> I'm trying to understand why authorization should be mandatory? To my
> knowledge, only some of the Linux package management tools (apt, port,
> rpm, yum) verify signatures by default and in the event of failure,
> they allow you to continue without the key verification.
>
> Also, I've actually spoken to a number of folks about GPG verification
> of artifacts over the last year and very few folks actually use this
> today.
>
>
> > Did you not see what just happened to Redhat with respect to Fedora? They
> > take artifact security seriously. For a long time, it has appeared that
> > Maven does not, but I am hopeful now that mandatory authorization will
> > appear, so that I and others will not have to increase lobbying efforts to
> > have the Maven repository closed, at least with respect to ASF projects.
>
>
> Please explain what happened to RedHat with respect to Fedora. I'm not
> familiar with the situation.
http://rtfa.net/2008/08/25/fedora-package-signing-server-compromise-crls-and-trust/
and
http://rhn.redhat.com/errata/RHSA-2008-0855.html
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
>
> Blog: http://bruceblog.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Bruce Snyder <br...@gmail.com>.
On Fri, Oct 3, 2008 at 8:50 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Moved to the thread it belongs in ...
>
> Jason van Zyl wrote:
>> Noel J. Bergman wrote:
>> > Emmanuel Lecharny wrote:
>>>> Better a bad decision than no decision, otherwise, soon, nobody will
>>>> vote anymore...
>>> Not really. Consider that there appears to be a clear consensus
>>> that if Maven were to fix the download situation, requiring that users
>>> approve the user of Incubator artifacts, rather than transparently use
>>> them, many of the -1 would be +1.
>
>> That's unlikely to happen. We're not going to be implementing policy
>> enforcement for you.
>
> We don't need for you to implement any "policy" other than the requirement
> for users to approve authorized signing keys. You simply need to implement
> artifact signing and mandatory authorization, which is why I've moved this
> to the thread Brett started for purposes of discussing signing.
I'm trying to understand why authorization should be mandatory? To my
knowledge, only some of the Linux package management tools (apt, port,
rpm, yum) verify signatures by default and in the event of failure,
they allow you to continue without the key verification.
Also, I've actually spoken to a number of folks about GPG verification
of artifacts over the last year and very few folks actually use this
today.
> Did you not see what just happened to Redhat with respect to Fedora? They
> take artifact security seriously. For a long time, it has appeared that
> Maven does not, but I am hopeful now that mandatory authorization will
> appear, so that I and others will not have to increase lobbying efforts to
> have the Maven repository closed, at least with respect to ASF projects.
Please explain what happened to RedHat with respect to Fedora. I'm not
familiar with the situation.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Blog: http://bruceblog.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Oct 3, 2008 at 4:50 PM, Noel J. Bergman <no...@devtech.com> wrote:
> We don't need for you to implement any "policy" other than the requirement
> for users to approve authorized signing keys. You simply need to implement
> artifact signing and mandatory authorization, which is why I've moved this
> to the thread Brett started for purposes of discussing signing.
This part of the discussion IMHO doesn't belong here in the Incubator.
You want artifact signing and verification so you can enforce users to
explicitly acknowledge the use of incubating dependencies. I say such
click through is not and should not be needed.
Could we please keep the discussion on that policy decision (click
through or no click through) instead of wondering when and how Maven
will support that out of the box.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
On 7-Oct-08, at 12:02 AM, Niclas Hedhman wrote:
> On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl <ja...@maven.org>
> wrote:
>> The central repository is the Maven PMC's business. What results
>> will be
>> public policy but we'd like to avoid the banter of the misinformed
>> so we can
>> arrive at a decision quickly.
>
> Yes, although the PMC is expected to do all non-sensitive discussion
> on the public dev@ list. But, so far I think the central repo has
> served the Java communities (not only Apache) very well. It allows
> sync'ing from other repository hosts, which has made life a lot easier
> for smaller projects.
>
> That said, I think that Maven should move away from a central
> repository, and instead go with distributed ones and possibly harness
> the power of search engines (Yahoo RDF?) to locate stuff everywhere.
This is already possible with Nexus (http://nexus.sonatype.org).
Nexus, or the Nexus CLI tool, produces a Lucene index which Nexus uses
to create a federated searching and retrieval mechanism.
One instance of Nexus can proxy any other Maven repository -- a
repository manager or normal webserver -- and with the presence of the
Nexus index allows federated searching and retrieval of artifacts
through that single instance. Some groups are already starting to
provide Nexus indices:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexed+Maven+Repositories
This means you as a user can setup Nexus locally, create proxied
repositories and get access to the contents of those repositories. So
if everyone did this we could federate all the repositories around the
world and then central just becomes a switchboard. This would be great
as it would distribute the load around, but I think we still might
want to collect everything in one place for safety.
>
> To be able to do that securely, some clever security mechanisms must
> first be developed, and since that is in line with security-concerned
> people, I think it is a good thing to do so. "How hard can it be?",
> considering the expertise around detailing the requirements almost at
> code level, right ;-) ?
Mercury will support PGP validation, and we are building support for
PGP into Nexus so the indices could be retrieved and validated, and
subsequent retrieval of artifacts could then also be validated. The
technology is pretty much there to do what you're asking for but
producing the indices in all the repositories will take time. But
people are doing because it also provides value in the IDEs.
m2eclipse, Netbeans, and IDEA are already integrating Nexus index
technology to provide full POM auto-completion support, and we also
use the index to find Maven plugins, Maven archetypes, and flag
artifacts as having sources, javadocs, and valid checksums and
signatures. So people will create indices to get the value in IDEs and
as a consequence federating everything is possible.
>
>
>
> Cheers
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl <ja...@maven.org> wrote:
> The central repository is the Maven PMC's business. What results will be
> public policy but we'd like to avoid the banter of the misinformed so we can
> arrive at a decision quickly.
Yes, although the PMC is expected to do all non-sensitive discussion
on the public dev@ list. But, so far I think the central repo has
served the Java communities (not only Apache) very well. It allows
sync'ing from other repository hosts, which has made life a lot easier
for smaller projects.
That said, I think that Maven should move away from a central
repository, and instead go with distributed ones and possibly harness
the power of search engines (Yahoo RDF?) to locate stuff everywhere.
To be able to do that securely, some clever security mechanisms must
first be developed, and since that is in line with security-concerned
people, I think it is a good thing to do so. "How hard can it be?",
considering the expertise around detailing the requirements almost at
code level, right ;-) ?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
The central repository is not an Apache project's resource.
We've always discussed issues of the central repository in private
(except for technical details of syncing other project repositories)
and as far as policy goes it's the Maven PMC that will sets it.
Members can see the list and we're fine with that. We already know
what everyone and their uncle wants and it's unlikely a productive
discussion will ensue. You just have to look here to see that. We're
not wasting our time in endless debate. We'll decide, take feedback,
adjust, and move on. We're actually going to setup a group call to
discuss the issues on the table. So by next week we'll stuff for
people to discuss.
As far as Maven development goes, we work like just like every other
project, the repository is different and affects every project and
organization. What we are deciding is beyond the realm of Apache.
On 7-Oct-08, at 11:23 AM, Doug Cutting wrote:
> Jason van Zyl wrote:
>> The central repository is the Maven PMC's business. What results
>> will be public policy but we'd like to avoid the banter of the
>> misinformed so we can arrive at a decision quickly.
>
> I'd love to avoid the banter of the misinformed too, but that's not
> the way Apache projects are supposed to work, is it? Private lists
> should only be used for things which cannot be discussed in public,
> e.g., personnel issues, security breaches, etc.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by Doug Cutting <cu...@apache.org>.
Jason van Zyl wrote:
> The central repository is the Maven PMC's business. What results will be
> public policy but we'd like to avoid the banter of the misinformed so we
> can arrive at a decision quickly.
I'd love to avoid the banter of the misinformed too, but that's not the
way Apache projects are supposed to work, is it? Private lists should
only be used for things which cannot be discussed in public, e.g.,
personnel issues, security breaches, etc.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
The central repository is the Maven PMC's business. What results will
be public policy but we'd like to avoid the banter of the misinformed
so we can arrive at a decision quickly.
On 6-Oct-08, at 10:22 AM, Noel J. Bergman wrote:
> Jason van Zyl wrote:
>
>> The discussions are taking place on the Maven PMC list. If you are a
>> member you can join the list.
>
> Why are those discussions taking place on a private, closed, list
> instead of
> an open one?
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason van Zyl wrote:
> The discussions are taking place on the Maven PMC list. If you are a
> member you can join the list.
Why are those discussions taking place on a private, closed, list instead of
an open one?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
The discussions are taking place on the Maven PMC list. If you are a
member you can join the list.
On 4-Oct-08, at 8:31 AM, Gilles Scokart wrote:
> 2008/10/3 Jason van Zyl <ja...@maven.org>:
>>
>> On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote:
>>
>>> Emmanuel Lecharny wrote:
>>>
>>>> Better a bad decision than no decision, otherwise, soon, nobody
>>>> will
>>>> vote anymore...
>>>
>>> Not really. Consider that there appears to be a clear consensus
>>> that if
>>> Maven were to fix the download situation, requiring that users
>>> approve the
>>> user of Incubator artifacts, rather than transparently use them,
>>> many of
>>> the -1 would be +1.
>>>
>>
>> That's unlikely to happen. We're not going to be implementing policy
>> enforcement for you.
>>
>> Our opinion is forming in the Maven PMC that we will not enforce
>> third party
>> policy but will adhere to the legal distribution rights set forth
>> by the
>> license. All PMC members who have voiced an opinion thus far have
>> this
>> opinion,
>
> Where does this dicussion took places? Is there a thread we can read?
>
>
>
>
>> but we are scheduling a call for next week and we will have a
>> decision and stated policy shortly. We will keep you posted when we
>> reach a
>> decision.
>>
>>> It appears that the Maven community is finally getting a clue, and
>>> we can
>>> hope for a resolution, perhaps 6 months out or less if they don't
>>> falter.
>>>
>>> --- Noel
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> A man enjoys his work when he understands the whole and when he
>> is responsible for the quality of the whole
>>
>> -- Christopher Alexander, A Pattern Language
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Gilles Scokart <gs...@gmail.com>.
2008/10/3 Jason van Zyl <ja...@maven.org>:
>
> On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote:
>
>> Emmanuel Lecharny wrote:
>>
>>> Better a bad decision than no decision, otherwise, soon, nobody will
>>> vote anymore...
>>
>> Not really. Consider that there appears to be a clear consensus that if
>> Maven were to fix the download situation, requiring that users approve the
>> user of Incubator artifacts, rather than transparently use them, many of
>> the -1 would be +1.
>>
>
> That's unlikely to happen. We're not going to be implementing policy
> enforcement for you.
>
> Our opinion is forming in the Maven PMC that we will not enforce third party
> policy but will adhere to the legal distribution rights set forth by the
> license. All PMC members who have voiced an opinion thus far have this
> opinion,
Where does this dicussion took places? Is there a thread we can read?
> but we are scheduling a call for next week and we will have a
> decision and stated policy shortly. We will keep you posted when we reach a
> decision.
>
>> It appears that the Maven community is finally getting a clue, and we can
>> hope for a resolution, perhaps 6 months out or less if they don't falter.
>>
>> --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by sebb <se...@gmail.com>.
On 03/10/2008, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> >We don't have to. We can simply mandate that every ASF project sign
> their
> >artifacts and charge the Maven PMC with enforcing it.
>
>
> And are you going to lobby FireFox and Microsoft to enforce in their
> browsers?
Microsoft already *does* check signatures for ActiveX addons.
> Seriously why is this Maven's problem simply because it
> downloads it when you can't enforce this in any other method that people
> download it?
>
There is a big difference between using a browser to download a
specific file chosen by the user and Maven downloading some file
automatically.
>
> >On the other hand, imagine the fun when
> >someone puts a nice bit of malware into the security-free zone known as
> the
> >Maven repository.
>
>
> Security Free?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>We don't have to. We can simply mandate that every ASF project sign
their
>artifacts and charge the Maven PMC with enforcing it.
And are you going to lobby FireFox and Microsoft to enforce in their
browsers? Seriously why is this Maven's problem simply because it
downloads it when you can't enforce this in any other method that people
download it?
>On the other hand, imagine the fun when
>someone puts a nice bit of malware into the security-free zone known as
the
>Maven repository.
Security Free?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Oct 3, 2008 at 5:31 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Jason van Zyl wrote:
>
>> Noel J. Bergman wrote:
<snip>
>> > Did you not see what just happened to Redhat with respect to
>> > Fedora? They take artifact security seriously. For a long time,
>> > it has appeared that Maven does not, but I am hopeful now that
>> > mandatory authorization will appear, so that I and others will not
>> > have to increase lobbying efforts to have the Maven repository
>> > closed, at least with respect to ASF projects.
>
>> How are you going to stop people from [creating their own artifacts and
> repositories] Noel when its their right?
>
> We don't have to. We can simply mandate that every ASF project sign their
> artifacts and charge the Maven PMC with enforcing it.
sounds very reasonsable
> And perhaps now you start to gain a glimer of the depth of the problem
> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
> towards security, despite other repository exemplars (e.g., linux
> distributions), having had security in place for years.
that's probably a little strong
many distros have only really addressed this in the last year or so,
and even then their solutions are far from perfect
IMO a combination of approaches is require to deliver good defense in
depth combining auditing, automatic signing, publication and wide
dissemination of results together with signatures by release managers.
this is also something that may well be best solved in a common forum.
it would be very useful to reach out to other organisations such as
fedora, debian, eclipse, java.net etc which have similiar problems.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason van Zyl wrote:
> Noel, your comments are completely out of whack with reality. You are
> asking Maven to enforce something that no one does. Pretty much
> almost no one.
> Checking PGP signatures is obviously not something the vast majority of
people do.
Really? Try following the instructions at http://www.medibuntu.org/ for
adding the repository without adding the PGP key, and see how well it works.
Not that I am suggesting a single, centralized, master key for the entire
repository. And, again, RedHat takes it so seriously that they shutdown
their distribution network when they had even the slightest concern that the
signing keys were compromised.
If you are saying that we don't have signed packages, I agree with you that
more projects should be signing. I have signed JAMES releases for years.
But the problem is much worse when using Maven, since users haven't a clue
as to the provanance of the artifacts they don't even realize that they are
loading onto their systems.
In any event, this discussion should be moved to eithe repository@ or
infra-dev@.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Jason van Zyl <ja...@maven.org>.
On 6-Oct-08, at 10:21 AM, Noel J. Bergman wrote:
> Niclas Hedhman wrote:
>
>> Being in the camp "I hate Maven too"
>
> I hate Maven's lack of authentication, the potential for widespread
> damage,
> and am immensely frustrated by their *years* of willfully negligent
> handling
> thereof.
>
>> I would like to swap Noel's statement around and ask; Why doesn't
>> security concerned individuals participate in the Maven effort?
>> Lead by example and not by bashing...
>
> They have received constructive input for years. They continue to
> do so.
> Jason's comments appear to echo the old-school negligence that I'd
> hoped the
> Maven PMC was at long last starting to be cured of.
>
Noel, your comments are completely out of whack with reality. You are
asking Maven to enforce something that no one does. Pretty much almost
no one.
Downloads from our own servers:
57.47% archive.apache.org
40.72% www.apache.org
... almost all are zip's and [.tar].gz's (see extensions report)
92.72% .zip [Zip archives]
2.10% .gz [Gzip compressed files]
2.05% .tar.gz [Compressed archives]
< 0.1% .asc (not even listed)
Almost no one is validating PGP signatures. It's not that we couldn't
in the past, we just had to choose to implement features that
delivered what our users wanted. Checking PGP signatures is obviously
not something the vast majority of people do. So pointing your finger
at us and calling it negligence is not even remotely correct. The same
goes the checksums which people also don't check but Maven does this
automatically so we are, in fact, providing a greater degree of
security to the average user. By default as a big warning message
appears and you can optionally fail builds if the checksum fails.
After having a discussion with Henk about the nature of PGP usage and
checksums I share his sentiments which he has allowed me to quote:
-- In the past I have maintained that the most important reason to
sign stuff is to protect the /ASF/ (as opposed to downloaders).
People trust the ASF to detect malware (trojans etc) and react
upon detection. For downloaders, a simple md5 check should be
sufficient. The ASF should be as cautious/suspicious as the
most cautious/suspicious downloader imaginable. Are we ?
-- Another reason: one day some computer science class is going
to compare various open-software centers (like the ASF) on
how well such centers protect themselves against malware.
The ASF should be examplary. Are we ?
When Mercury is integrated into Maven and people can optionally fail
builds on failed PGP sig validation Maven will again provide a greater
degree of security given that the practice of validating sigs is
pretty much non-existent.
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Being in the camp "I hate Maven too"
I hate Maven's lack of authentication, the potential for widespread damage,
and am immensely frustrated by their *years* of willfully negligent handling
thereof.
> I would like to swap Noel's statement around and ask; Why doesn't
> security concerned individuals participate in the Maven effort?
> Lead by example and not by bashing...
They have received constructive input for years. They continue to do so.
Jason's comments appear to echo the old-school negligence that I'd hoped the
Maven PMC was at long last starting to be cured of.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Oct 6, 2008 at 10:45 AM, Henning Schmiedehausen
<he...@schmiedehausen.org> wrote:
> On Fri, 2008-10-03 at 12:31 -0400, Noel J. Bergman wrote:
>>
>> We don't have to. We can simply mandate that every ASF project sign their
>> artifacts and charge the Maven PMC with enforcing it.
>
> No. The Maven PMC is charged with developing software for the Apache
> Maven project. If we really want to put a distribution policy in place
> and enforce it, I can see us creating a repository PMC which does this
> (and talk to Maven about the features that they would like to see or
> (gasp!) implement them and contribute them back to Maven. I would see
> such a PMC as part of or collaborating with Infrastructure.
I thought this effort was started years and years ago...
> Maven is a piece of software, not a distribution mechanism. They just
> happen to build it because no one else did.
>
>> And perhaps now you start to gain a glimer of the depth of the problem
>> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
>> towards security, despite other repository exemplars (e.g., linux
>> distributions), having had security in place for years. Yes, it may be a
>
> Please stop it, Noel. This is not constructive.
Being in the camp "I hate Maven too", I must say I agree with Henning
that the language used was inappropriate.
I would like to swap Noel's statement around and ask; Why doesn't
security concerned individuals participate in the Maven effort? Lead
by example and not by bashing...
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Mon, 2008-10-06 at 10:21 -0400, Noel J. Bergman wrote:
> Henning Schmiedehausen wrote:
>
> > Noel J. Bergman wrote:
> > > We don't have to. We can simply mandate that every ASF project sign
> their
> > > artifacts and charge the Maven PMC with enforcing it.
>
> > No. The Maven PMC is charged with developing software for the Apache
> > Maven project.
>
> You misunderstand. I mean that the Maven code should enforce
> authentication, not that the Maven PMC must police the repository.
Maven is a modular framework. If you want to enforce such policy, it
should be possible to write plugins to do so. All that is needed is
someone to write them or fund writing. The current Maven group seems to
feel that they don't need them or they are not high on the prio list. So
someone else must do it. This is a do-ocracy. :-)
>
> > If we really want to put a distribution policy in place
> > and enforce it, I can see us creating a repository PMC which does this
>
> We already have that as a subgroup of Infrastructure. The
> repository@apache.org list has existed for *years*.
I know. So why are you bashing the Maven PMC when you mean the
"repository management group"?
Ciao
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Henning Schmiedehausen wrote:
> Noel J. Bergman wrote:
> > We don't have to. We can simply mandate that every ASF project sign
their
> > artifacts and charge the Maven PMC with enforcing it.
> No. The Maven PMC is charged with developing software for the Apache
> Maven project.
You misunderstand. I mean that the Maven code should enforce
authentication, not that the Maven PMC must police the repository.
> If we really want to put a distribution policy in place
> and enforce it, I can see us creating a repository PMC which does this
We already have that as a subgroup of Infrastructure. The
repository@apache.org list has existed for *years*.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Fri, 2008-10-03 at 12:31 -0400, Noel J. Bergman wrote:
>
> We don't have to. We can simply mandate that every ASF project sign their
> artifacts and charge the Maven PMC with enforcing it.
No. The Maven PMC is charged with developing software for the Apache
Maven project. If we really want to put a distribution policy in place
and enforce it, I can see us creating a repository PMC which does this
(and talk to Maven about the features that they would like to see or
(gasp!) implement them and contribute them back to Maven. I would see
such a PMC as part of or collaborating with Infrastructure.
Maven is a piece of software, not a distribution mechanism. They just
happen to build it because no one else did.
> And perhaps now you start to gain a glimer of the depth of the problem
> created by Maven's irresponsible, unconscionable, lackadaisical, attitude
> towards security, despite other repository exemplars (e.g., linux
> distributions), having had security in place for years. Yes, it may be a
Please stop it, Noel. This is not constructive.
Ciao
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Jason van Zyl <ja...@maven.org>.
On 3-Oct-08, at 12:31 PM, Noel J. Bergman wrote:
> Jason van Zyl wrote:
>
>> Noel J. Bergman wrote:
>>> We don't need for you to implement any "policy" other than the
>>> requirement for users to approve authorized signing keys. You
>>> simply need to implement artifact signing and mandatory
>>> authorization, which is why I've moved this to the thread Brett
>>> started for purposes of discussing signing.
>
>> You are not the Incubator PMC
>
> And where did I imply otherwise??
>
>> and what the Incubator says they require is far from clear.
>> Disclaimers,
>> notices, PGP keys. No one knows what anyone wants here. No one
>> can follow these discussions.
>
> That's rather over the top.
We're talking years here Noel. Point at anything that succinctly
states the policy. Doesn't exist. I think if you asked anyone right
now they would have no idea what the result is. We had a majority
vote, someone on the board said that's the way we should go, some
agree, some don't, then you step in and say that's not the way it is
because Greg said that's the way it is. It's not meant to be over the
top, just a statement of fact.
> The disclaimer and notice requirements are well
> documented and have been for a long time. The PGP key situation is
> under
> discussion, likely to be resolved by the Infrastructure Team, and
> will be an
> ASF-wide issue. The Incubator relationship is that the same mandatory
> requirement for security that needs to be imposed on Maven can also
> address
> the long-standing requirement that users be aware of and accepting
> that they
> are using Incubator artifacts.
You won't be imposing anything on Maven and what we do with central or
what security measures we do, or do not implement. Policy here is, of
course, of the IPMC. Turn on/off repositories as you see fit. It's got
nothing to do with the way Maven users access the central repository.
If you don't want to participate directly making artifacts available
then don't.
We're not fighting you, and technically we've made it easier for folks
to check if there are signatures but lots of projects don't and that's
not Maven's problem, it's not Ivy's problem, it's not BuildR's problem.
>
>
>> Oleg, who is responsible for implementing Mercury which has
>> full PGP support, has this functionality working on all branches of
>> Maven but the option to use it will be in the hands of the user. As
>> the quality and tools for supporting PGP get better, and more people
>> use them we will again take a look at the default behavior.
>
>>> Did you not see what just happened to Redhat with respect to
>>> Fedora? They take artifact security seriously. For a long time,
>>> it has appeared that Maven does not, but I am hopeful now that
>>> mandatory authorization will appear, so that I and others will not
>>> have to increase lobbying efforts to have the Maven repository
>>> closed, at least with respect to ASF projects.
>
>> How are you going to stop people from [creating their own artifacts
>> and
> repositories] Noel when its their right?
>
> We don't have to. We can simply mandate that every ASF project sign
> their
> artifacts and charge the Maven PMC with enforcing it.
The first part is already mandated, or I certainly thought it was. The
second part of that is not going to happen.
>
>
> And perhaps now you start to gain a glimer of the depth of the problem
> created by Maven's irresponsible, unconscionable, lackadaisical,
> attitude
> towards security, despite other repository exemplars (e.g., linux
> distributions), having had security in place for years. Yes, it may
> be a
> bit painful to make the change. On the other hand, imagine the fun
> when
> someone puts a nice bit of malware into the security-free zone known
> as the
> Maven repository. Not only do I agree with Henning's assessment, I
> think
> that network administrators should block the Maven repository at their
> firewalls.
Tell them that. See what they do.
>
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason van Zyl wrote:
> Noel J. Bergman wrote:
> > We don't need for you to implement any "policy" other than the
> > requirement for users to approve authorized signing keys. You
> > simply need to implement artifact signing and mandatory
> > authorization, which is why I've moved this to the thread Brett
> > started for purposes of discussing signing.
> You are not the Incubator PMC
And where did I imply otherwise??
> and what the Incubator says they require is far from clear. Disclaimers,
> notices, PGP keys. No one knows what anyone wants here. No one
> can follow these discussions.
That's rather over the top. The disclaimer and notice requirements are well
documented and have been for a long time. The PGP key situation is under
discussion, likely to be resolved by the Infrastructure Team, and will be an
ASF-wide issue. The Incubator relationship is that the same mandatory
requirement for security that needs to be imposed on Maven can also address
the long-standing requirement that users be aware of and accepting that they
are using Incubator artifacts.
> Oleg, who is responsible for implementing Mercury which has
> full PGP support, has this functionality working on all branches of
> Maven but the option to use it will be in the hands of the user. As
> the quality and tools for supporting PGP get better, and more people
> use them we will again take a look at the default behavior.
> > Did you not see what just happened to Redhat with respect to
> > Fedora? They take artifact security seriously. For a long time,
> > it has appeared that Maven does not, but I am hopeful now that
> > mandatory authorization will appear, so that I and others will not
> > have to increase lobbying efforts to have the Maven repository
> > closed, at least with respect to ASF projects.
> How are you going to stop people from [creating their own artifacts and
repositories] Noel when its their right?
We don't have to. We can simply mandate that every ASF project sign their
artifacts and charge the Maven PMC with enforcing it.
And perhaps now you start to gain a glimer of the depth of the problem
created by Maven's irresponsible, unconscionable, lackadaisical, attitude
towards security, despite other repository exemplars (e.g., linux
distributions), having had security in place for years. Yes, it may be a
bit painful to make the change. On the other hand, imagine the fun when
someone puts a nice bit of malware into the security-free zone known as the
Maven repository. Not only do I agree with Henning's assessment, I think
that network administrators should block the Maven repository at their
firewalls.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: status of PGP support in Maven
Posted by Jason van Zyl <ja...@maven.org>.
On 3-Oct-08, at 10:50 AM, Noel J. Bergman wrote:
> Moved to the thread it belongs in ...
>
> Jason van Zyl wrote:
>> Noel J. Bergman wrote:
>>> Emmanuel Lecharny wrote:
>>>> Better a bad decision than no decision, otherwise, soon, nobody
>>>> will
>>>> vote anymore...
>>> Not really. Consider that there appears to be a clear consensus
>>> that if Maven were to fix the download situation, requiring that
>>> users
>>> approve the user of Incubator artifacts, rather than transparently
>>> use
>>> them, many of the -1 would be +1.
>
>> That's unlikely to happen. We're not going to be implementing policy
>> enforcement for you.
>
> We don't need for you to implement any "policy" other than the
> requirement
> for users to approve authorized signing keys. You simply need to
> implement
> artifact signing and mandatory authorization, which is why I've
> moved this
> to the thread Brett started for purposes of discussing signing.
You are not the Incubator PMC, and what the Incubator says they
require is far from clear. Disclaimers, notices, PGP keys. No one
knows what anyone wants here. No one can follow these discussions.
There will be no mandatory authorization. That will not be turned on
by default in the foreseeable future. The tools will exist for people
to use as they see fit. It is more likely that people using repository
managers will enable this, but it won't be turned on in the Maven
client. Oleg, who is responsible for implementing Mercury which has
full PGP support, has this functionality working on all branches of
Maven but the option to use it will be in the hands of the user. As
the quality and tools for supporting PGP get better, and more people
use them we will again take a look at the default behavior
>
>
> Did you not see what just happened to Redhat with respect to
> Fedora? They
> take artifact security seriously. For a long time, it has appeared
> that
> Maven does not, but I am hopeful now that mandatory authorization will
> appear, so that I and others will not have to increase lobbying
> efforts to
> have the Maven repository closed, at least with respect to ASF
> projects.
Lobby away. Close the repository, then what's going to happen? Someone
checks out all the sources with a CI system, builds everything and
publishes them, then what are you going to do? Shut down anonymous SVN
access because people are doing what they can by rights of the
license? Track them down and tell them not to do it? Tell the Maven
PMC to intervene to stop people from making submissions via JIRA. Stop
the repositories that are already syncing Apache artifacts to central
or hosting their own repositories? How are you going to stop people
from doing this Noel when its their right? You going to lock down
everything to the point where no one wants to get involved?
>
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
re: status of PGP support in Maven
Posted by "Noel J. Bergman" <no...@devtech.com>.
Moved to the thread it belongs in ...
Jason van Zyl wrote:
> Noel J. Bergman wrote:
> > Emmanuel Lecharny wrote:
>>> Better a bad decision than no decision, otherwise, soon, nobody will
>>> vote anymore...
>> Not really. Consider that there appears to be a clear consensus
>> that if Maven were to fix the download situation, requiring that users
>> approve the user of Incubator artifacts, rather than transparently use
>> them, many of the -1 would be +1.
> That's unlikely to happen. We're not going to be implementing policy
> enforcement for you.
We don't need for you to implement any "policy" other than the requirement
for users to approve authorized signing keys. You simply need to implement
artifact signing and mandatory authorization, which is why I've moved this
to the thread Brett started for purposes of discussing signing.
Did you not see what just happened to Redhat with respect to Fedora? They
take artifact security seriously. For a long time, it has appeared that
Maven does not, but I am hopeful now that mandatory authorization will
appear, so that I and others will not have to increase lobbying efforts to
have the Maven repository closed, at least with respect to ASF projects.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Jason van Zyl <ja...@maven.org>.
On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote:
> Emmanuel Lecharny wrote:
>
>> Better a bad decision than no decision, otherwise, soon, nobody will
>> vote anymore...
>
> Not really. Consider that there appears to be a clear consensus
> that if
> Maven were to fix the download situation, requiring that users
> approve the
> user of Incubator artifacts, rather than transparently use them,
> many of
> the -1 would be +1.
>
That's unlikely to happen. We're not going to be implementing policy
enforcement for you.
Our opinion is forming in the Maven PMC that we will not enforce third
party policy but will adhere to the legal distribution rights set
forth by the license. All PMC members who have voiced an opinion thus
far have this opinion, but we are scheduling a call for next week and
we will have a decision and stated policy shortly. We will keep you
posted when we reach a decision.
> It appears that the Maven community is finally getting a clue, and
> we can
> hope for a resolution, perhaps 6 months out or less if they don't
> falter.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
Emmanuel Lecharny wrote:
> Better a bad decision than no decision, otherwise, soon, nobody will
> vote anymore...
Not really. Consider that there appears to be a clear consensus that if
Maven were to fix the download situation, requiring that users approve the
user of Incubator artifacts, rather than transparently use them, many of
the -1 would be +1.
It appears that the Maven community is finally getting a clue, and we can
hope for a resolution, perhaps 6 months out or less if they don't falter.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by Emmanuel Lecharny <el...@gmail.com>.
Niall Pemberton wrote:
>> This is a slight majority (of binding votes) for accepting the
>> proposed change, but given the clear lack of consensus and the
>> concerns voiced about that, I unfortunately need to conclude that this
>> issue should be tabled until better consensus is reached.
>>
>
> If this was a release vote then I could understand it - since people
> judge the importance of issues differently - and fixing the issues and
> moving on to a new release is often easier since it maintains
> consensus. On this issue though, its been well debated several times -
> it s clear that there won't be consensus in the near future - so why
> should the minority get their way when they lost the vote? If this
> vote doesn't pass then we need to re-write the rules to define how
> much of a majority overturns the status quo. Perhaps two thrids,
> perhaps no negative votes. If this policy isn't implemented, then I
> think all the people who voted +1 at least deserve a definition of how
> short we fell of passing this vote and what the bar is.
>
having voted -1 myself, and even if I still think that it's not a result
I like, I also think that we need to move on and consider the vote as
positive.
If we discover after a few months that it was a bad idea, then we can
vote again, and fix the problem.
Better a bad decision than no decision, otherwise, soon, nobody will
vote anymore...
And about the other concerns, we can also start some discussions and
vote, too.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Sep 24, 2008 at 2:40 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Please vote on accepting or rejecting this policy change!
>
> The vote ends with the following 15 +1, 12 -1, and one 0 binding votes.
>
> +1 Bertrand Delacretaz
> +1 Brett Porter
> +1 Bruce Snyder
> +1 Davanum Srinivas
> +1 Doug Cutting
> +1 Guillaume Nodet
> +1 James Strachan
> +1 Jason van Zyl
> +1 Jeffrey Genender
> +1 Jukka Zitting
> +1 Martin Dashorst
> +1 Niall Pemberton
> +1 Roland Weber
> +1 Upayavira
> +1 William Rowe
>
> 0 Thomas Fischer
>
> -1 Ant Elder
> -1 Craig Russell
> -1 Emmanuel Lecharny
> -1 Henning Schmiedehausen
> -1 Jim Jagielski
> -1 Justin Erenkrantz
> -1 Kevan Miller
> -1 Matt Hogstrom
> -1 Matthieu Riou
> -1 Noel J. Bergman
> -1 Paul Querna
> -1 Will Glass-Husain
>
> The following eight +1 and one -1 non-binding votes were also cast:
>
> +1 Assaf Arkin
> +1 Eelco Hillenius
> +1 Dan Diephouse
> +1 Daniel Kulp
> +1 Felix Meschberger
> +1 Les Hazlewood
> +1 Niklas Gustavsson
> +1 Stephen Duncan Jr
>
> -1 Sebastian Bazley
>
> This is a slight majority (of binding votes) for accepting the
> proposed change, but given the clear lack of consensus and the
> concerns voiced about that, I unfortunately need to conclude that this
> issue should be tabled until better consensus is reached.
If this was a release vote then I could understand it - since people
judge the importance of issues differently - and fixing the issues and
moving on to a new release is often easier since it maintains
consensus. On this issue though, its been well debated several times -
it s clear that there won't be consensus in the near future - so why
should the minority get their way when they lost the vote? If this
vote doesn't pass then we need to re-write the rules to define how
much of a majority overturns the status quo. Perhaps two thrids,
perhaps no negative votes. If this policy isn't implemented, then I
think all the people who voted +1 at least deserve a definition of how
short we fell of passing this vote and what the bar is.
Niall
> The main impression I got from the related discussion is that the main
> concern is not that much the security or transparency of the Maven
> repository but rather the status of incubating releases in general.
>
> Are incubating releases official releases of the ASF? Does the ASF
> "endorse" these releases, and what does that endorsement mean? How
> strong disclaimers are needed and what level of explicit
> acknowledgement from users is required? Until we have a clearer policy
> on what we actually require of incubating releases and their
> distribution, it seems premature to debate whether the Maven
> repository meets those requirements.
>
> So, before reopening this release distribution issue, I would expect
> us to clarify the policy on incubating releases.
>
> BR,
>
> Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org