incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <>
Subject RE: Convenience Binary Policy
Date Tue, 21 Oct 2014 04:09:23 GMT
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

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:
View raw message