Let me see if I can tie all of the responses back into one thread. Thanks Ross, for confirming that vote periods can be shorter. However, there still isn’t enough time to get through vote + mirror latency before Tuesday in San Francisco.
I think Ted just said I can update the binary package but I have to “label it according to what it is”. I think that implies that it cannot be the binary package for FlexJS 0.0.2, but why not? Is it because it isn’t a true result of running the build script? Or because I should tweak LICENSE and NOTICE in the binary package? Ted also said that I could post a new installer. If I post an installer that only offers to install this modified binary package, none of the installer code needs to change other than where it picks up the list of packages to offer. But that’s a source code change, so isn’t that like advertising a nightly/development build to the public? Or can you offer nightly binary packages, but not nightly source packages? Another option for a modified installer is one that codes around the SourceForge download problem. I’m investigating that now, but that will also be a source code change. Brane said that the Flex Community is used to voting on binary packages, but I don’t think that’s true. We’re just trying to find out if there really is any policy against modification of a binary package. I think our PMC is more concerned about making new visitors to Apache and Flex happy as long as we don’t break any rules. -Alex On 10/20/14, 10:01 PM, "Ross Gardler (MS OPEN TECH)" <ross.gard...@microsoft.com> wrote: > >Ok. Well remember that the release vote period is a guideline. If this is >such a trivial change maybe it would be acceptable to use a shorter vote >period. As long as you have three +1 (meaning three people have verified >the release) you would be good to go, without long debates about policy >and intent ;-) > >Having said that it's always good to clarify things. > >-----Original Message----- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Monday, October 20, 2014 9:41 PM >To: general@incubator.apache.org >Subject: Re: Convenience Binary Policy > >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 >?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB� >?�?[��X��ܚX�K??K[XZ[?�?�[�\�[?][��X��ܚX�P?[��X�]?܋�\?X�?K�ܙ�B��܈?Y??]?[ۘ[? >?��[X[�?�??K[XZ[?�?�[�\�[?Z?[???[��X�]?܋�\?X�?K�ܙ�B
