incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Do all releases need to go to /dist?
Date Fri, 21 Dec 2012 20:24:37 GMT
Given how the discussion on other closed lists is proceeding, as chair
of this committee, I feel compelled to contribute the following:

The current stated policy of the Foundation is that releases go onto
/dist. If you are using Maven tooling to make your releases, you
should first of all be sure to produce real, buildable, releases using
the profiles in the ASF POM, and secondly, you should copy those zip
files to /dist after a vote passes.

If this policy changes, I'll be quite sure to make this list aware of
it, if someone else doesn't beat me to it.

In short, I misjudged the historical context of this particular issue.

On Fri, Dec 21, 2012 at 2:28 PM, Mohammad Nour El-Din
<> wrote:
> Hi
>    I agree about how policy should change.
> But when it comes to apply on this case I believe we have to read the
> release rules carefully and we will see that we don't need policy change we
> just need to add more details and hence make it more clear
> The release rules assume you are release source code not just a pom file
> (s) which for sure people will not use it by downloading a dist from
> anywhere.
> They either will svn co the tag and build it locally or use the one
> deployed in Nexus
> It is just a different situation not an exception
> Christian and I already discussed that offline and kindly took the effort
> to bring it to the list :)
> Sent from my Samsung Galaxy S3
> Apologies for any typos
> On Dec 21, 2012 5:12 PM, "Benson Margulies" <> wrote:
>> My belief is that the policy changed a long time ago but was not
>> properly edited into the document. If I didn't believe that, I'd be
>> taking a different approach here. My secondary belief is that the
>> existing document is an ambiguous writing job, and I'm as entitled to
>> my opinion as to the actual intention as anyone else with rights to
>> edit it.
>> And, as such, I think that the right thing to do is to put up the
>> edits and see who complains.
>> I am perfectly happy to set the example of boldly editing documents to
>> state the policy as I understand it, and then inviting people to
>> comment. I am in part inspired by the other thread about the
>> uselessness of DRAFT and suchlike markings.
>> If you are so convinced that I am entirely changing, as opposed to
>> clarifying, a Foundation invariant, then you should say as much on the
>> thread over on infra. If you feel strongly enough, you should revert
>> my commit.
>> On Fri, Dec 21, 2012 at 10:16 AM, Daniel Shahaf <>
> wrote:
>> > Benson Margulies wrote on Fri, Dec 21, 2012 at 07:01:03 -0500:
>> >> On Fri, Dec 21, 2012 at 6:58 AM, Marcel Offermans
>> >> <> wrote:
>> >> > Well, I don't think it's fine. As long as our release policy states
> that all releases must be archived on /dist we should do exactly that. Or
> change the policy.
>> >>
>> >> Give me a URL where this policy is and I'll edit it.
>> >
>> > The way to change a policy is to obtain consensus on the new policy, not
>> > to edit the web page that documents the existing policy --- particularly
>> > when someone just expressed an opinion in favour of the documented
> policy.
>> >
>> > You're setting a good counter-example to podlings.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message