incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Convenience Binary Policy
Date Tue, 21 Oct 2014 04:40:59 GMT
Sorry, my last response crossed paths with this.

We can and will make another release, but no, it was only 24 hours ago
that we realized we might get a bump in installs from the talk on Tuesday
and only 10 hours since I proved we could workaround the problem with a
change to the binary package.  No plan involving votes and mirrors would
fix the problem in time.  So I am looking for reasons why we can/can’t
update a binary package in less time than the whole vote + mirrors latency.


On 10/20/14, 9:09 PM, "Ross Gardler (MS OPEN TECH)"
<> wrote:

>Regardless of whether you can/can't do this (others are commentating, I
>won't add to that) - wouldn't it be easier to just build a release and
>call a vote. My guess is that you spent more than three days from
>identification of the problem to distribution and discussion here.
>Remember, if you take the time to make a release nobody can veto it
>(although if there are good community reasons to not release you'd be
>expected to honor that).
>-----Original Message-----
>From: Alex Harui []
>Sent: Monday, October 20, 2014 4:47 PM
>Subject: Re: Convenience Binary Policy
>On 10/20/14, 4:13 PM, "Ted Dunning" <> wrote:
>>On Mon, Oct 20, 2014 at 3:08 PM, Alex Harui <> wrote:
>>> I know we can’t go messing around with source packages without a
>>>vote, but  what about binary packages?  Is it against policy to do
>>>something like  this, and if so, can exceptions be made?
>>I may not have followed this quite correctly, here is what I understood
>>of the situation as you described it:
>>1) there is a bug in the FlexJS distro, considered low priority due to
>>sparse use
>>2) you needed a quickly corrected binary distribution
>>3) you created a correct distribution artifact and put it somewhere
>>4) you aren't claiming that the artifact you created is an Apache
>>release and you are pointing some workshop participants at your release.
>>I fail to see any problem whatsoever in what you did.  You used Apache
>>software to create a derived work which you are asking people to use in
>>an instructional setting.  As far as I can tell, the only claim you are
>>making is that your artifact is FlexJS with a fix that should be
>>incorporated upstream before long.
>>What's the problem?
>Well, the use of the Installer sort of implies that folks are getting the
>same binary kit that was on dist/mirrors.  So one of our PMC members is
>objecting to this plan, even though the net result of what ends up on the
>user’s disk is the same.  We won’t be pointing just the workshop
>participants at this modified binary, essentially everyone who uses the
>installer to install FlexJS 0.0.2 will get it.
>This may not be a fair analogy, but suppose you bundled an external jar
>in a binary distro and found out much later that the jar was corrupted
>and needed a quick fix.  Would you do what I just did and post a
>corrected binary somewhere outside Apache and then update your downloads
>page to point just the binary link there instead of the usual
>dist/mirrors?  For Flex, we don’t need to update our downloads page
>because the binary on dist/mirrors works if you unpack it yourself and
>run Ant, so the Installer makes it a bit different.  No flex.a.o page is
>going to point there, but the Installer app you downloaded from flex.a.o
>will point there.
>Maybe that’s a better question: are their policies about where and to
>what the binary links on a project’s download page can point?  Can it
>point outside the ASF to stuff that wasn’t generated at the same time as
>the source that was voted on?
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message