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.
Thanks, -Alex On 10/20/14, 9:09 PM, "Ross Gardler (MS OPEN TECH)" <ross.gard...@microsoft.com> 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). > >Ross > >-----Original Message----- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Monday, October 20, 2014 4:47 PM >To: general@incubator.apache.org >Subject: Re: Convenience Binary Policy > > > >On 10/20/14, 4:13 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote: > >>On Mon, Oct 20, 2014 at 3:08 PM, Alex Harui <aha...@adobe.com> 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 >>non-Apache >> >>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? > >-Alex > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
