[RESULT] [VOTE] Accept Taverna into the Apache Incubator
To: general@incubator.apache.org This VOTE passes with 13 +1 binding votes Suresh Marru Alan D. Cabrera jan I Ralph Goers Bertrand Delacretaz Andy Seaborne Suresh Srinivas Chris Mattmann Jean-Baptiste Onofré Jake Farrel Leif Hedstrom Jean-Louis Monteiro Roman Shaposhnik and no 0's or -1's I'll start the podling setup process. Thank you everyone. Andy On 16/10/14 16:54, Andy Seaborne wrote: Following the discussion earlier in the thread: https://www.mail-archive.com/general@incubator.apache.org/msg45241.html I would like to call a Vote for accepting Taverna as a new incubator project. The proposal is available at: https://wiki.apache.org/incubator/TavernaProposal Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC [ ] +1 accept Taverna in the Incubator [ ] ±0 [ ] -1 because... Only Votes from Incubator PMC members are binding, but everyone is welcome to contribute to the process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [VOTE] Accept Taverna into the Apache Incubator
On behalf of the Taverna community, thank you for all your support! On 20 October 2014 08:46, Andy Seaborne a...@apache.org wrote: To: general@incubator.apache.org This VOTE passes with 13 +1 binding votes Suresh Marru Alan D. Cabrera jan I Ralph Goers Bertrand Delacretaz Andy Seaborne Suresh Srinivas Chris Mattmann Jean-Baptiste Onofré Jake Farrel Leif Hedstrom Jean-Louis Monteiro Roman Shaposhnik and no 0's or -1's I'll start the podling setup process. Thank you everyone. Andy On 16/10/14 16:54, Andy Seaborne wrote: Following the discussion earlier in the thread: https://www.mail-archive.com/general@incubator.apache.org/msg45241.html I would like to call a Vote for accepting Taverna as a new incubator project. The proposal is available at: https://wiki.apache.org/incubator/TavernaProposal Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC [ ] +1 accept Taverna in the Incubator [ ] ±0 [ ] -1 because... Only Votes from Incubator PMC members are binding, but everyone is welcome to contribute to the process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Convenience Binary Policy
Hi, I’m wondering whether modifications to the set of bundled jars in a convenience binary package can be made after release without voting. And if not, I’m looking for any other quick-fix ideas for the following scenario. Flex has many different release packages. One is an SDK called FlexJS 0.0.2. Another is an Installer application. Most folks use the installer to download Flex binary packages, unpack them and execute a script in the package to download any dependencies. The FlexJS install script was working great until about two weeks ago, when the code the installer uses to fetch a jar from SourceForge stopped working. It wasn’t a major problem because FlexJS is in ‘alpha’ stage and only about 5 folks download it per day and they can go get the binary package and use Ant to run the script and it will succeed. However, last night, a community member realized that he was giving a talk on FlexJS on Tuesday morning which could cause a rise in the number of folks who would try to use the installer and subsequently fail. Any new vote plus mirror propagation time will not be in time for the talk. A workaround I tested was to add the jar from SourceForge to the binary package. No other files are touched, although I suppose I should update LICENSE and NOTICE. This works because the install script sees the jar and skips trying to download it. I can take this modified binary package, host it somewhere, change the installer’s config.xml that it fetches from flex.a.o so that it will pick up this package instead of the one on dist (actually, the mirrors) and the FlexJS 0.0.2 install will start working again. 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? Thanks, -Alex
Re: Convenience Binary Policy
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?
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
Re: Convenience Binary Policy
Hi, 3) you created a correct distribution artifact and put it somewhere non-Apache The modified binary has been placed in his Apache account [1] and AFAIK he wants to move it to the official a.o/dist release area without a vote or alternatively distribute it directly from there (to avoid waiting for the mirrors to catch up). It's currently been added to the installer as a dev only build (for testing purposes). By correct distribution it's a modified version of the existing 0.02 release binary. For someone to duplicate this they would have to unpack the existing binary, modify it by adding the Jberg jar and repackage it. No changes to the build process or source code, LICENSE, NOTICE etc have not been committed to the Apache Flex repository. 4) you aren't claiming that the artifact you created is an Apache release and you are pointing some workshop participants at your release. My understanding is Alex does want to use this as an official release and have the officially released Apache Flex installer download and install it. The new binary would be available to everyone / the general public and not just the people attending the talk. (I don't think it's a workshop). The currently nightly build doesn't have this issue it's only effects the previously officially released 0.01 and 0.02 versions of FlexJS which are publicly available via the installer and the Apache mirrors. I have already stated my view on the Flex dev list that we should follow the normal Apache vote and release cycle [3], but rather than repeat that here I think it boils down to just this: [2] Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. The Jberg jar is licensed under CPL so the binary would also would require a change to NOTICE to comply with Apache licensing policy. Thanks, Justin 1. http://people.apache.org/~aharui/FlexJS/binaries/0.0.2a/ 2. http://www.apache.org/dev/release.html#what 3. http://markmail.org/message/b2wbyo5yzbrb6f7d - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Convenience Binary Policy
On Mon, Oct 20, 2014 at 4:49 PM, Justin Mclean jus...@classsoftware.com wrote: 4) you aren't claiming that the artifact you created is an Apache release and you are pointing some workshop participants at your release. My understanding is Alex does want to use this as an official release and have the officially released Apache Flex installer download and install it. The new binary would be available to everyone / the general public and not just the people attending the talk. (I don't think it's a workshop). The currently nightly build doesn't have this issue it's only effects the previously officially released 0.01 and 0.02 versions of FlexJS which are publicly available via the installer and the Apache mirrors. No vote, not official. If he wants to build his own installer, fine. If it says it is downloading an Apache artifact, it should be voted.
Re: Convenience Binary Policy
On 10/20/14, 4:57 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Oct 20, 2014 at 4:49 PM, Justin Mclean jus...@classsoftware.com wrote: 4) you aren't claiming that the artifact you created is an Apache release and you are pointing some workshop participants at your release. My understanding is Alex does want to use this as an official release and have the officially released Apache Flex installer download and install it. We don’t have to do that. The bits on dist/mirrors can stay untouched, and the downloads page won’t change either. The main thing is whether the Installer app can point somewhere else. The new binary would be available to everyone / the general public and not just the people attending the talk. This is true. Anyone using the Installer would get the modified binary. No vote, not official. If he wants to build his own installer, fine. If it says it is downloading an Apache artifact, it should be voted. The Installer has a DropDown list of releases, such as “Apache Flex SDK 4.13.0” and “Apache FlexJS 0.0.2”. What if the entry that points to the modified package says “Apache FlexJS 0.0.2 (unofficial)” or “Unofficial Fix for Apache FlexJS 0.0.2”? But it would be the same Installer, not my own. Or does that get into the “promoting nightly builds” territory even though all the compiled code came from an official release? -Alex
Re: Convenience Binary Policy
On Mon, Oct 20, 2014 at 5:21 PM, Alex Harui aha...@adobe.com wrote: If he wants to build his own installer, fine. If it says it is downloading an Apache artifact, it should be voted. The Installer has a DropDown list of releases, such as “Apache Flex SDK 4.13.0” and “Apache FlexJS 0.0.2”. What if the entry that points to the modified package says “Apache FlexJS 0.0.2 (unofficial)” or “Unofficial Fix for Apache FlexJS 0.0.2”? But it would be the same Installer, not my own. Or does that get into the “promoting nightly builds” territory even though all the compiled code came from an official release? Why not just roll your own installer that has these additional options? Then this is the Acme Software Foundation installer and you can do what you like.
RE: Convenience Binary Policy
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
Re: Convenience Binary Policy
On 10/20/14, 5:54 PM, Ted Dunning ted.dunn...@gmail.com wrote: Why not just roll your own installer that has these additional options? Then this is the Acme Software Foundation installer and you can do what you like. I suppose we could, but it wouldn’t be easily found by folks who arrive at flex.a.o looking for FlexJS. They’ll probably end up using the current Installer and getting an error. I guess you are saying that there is no quick fix of a convenience binary. I guess I’ve been reading things like Marvin/Roy in this thread [1] that says that a binary package isn’t official which made me think we had more flexibility. Here’s the quote from Marvin quoting Roy: An official release by the Apache Software Foundation consists of source code which has been audited by a PMC. Of course it is not possible to audit an entire codebase at each release point, but we achieve that effective result through PMC monitoring of a commits list: if the last release was fully reviewed, each delta since then has also been reviewed, and we can demonstrate that the difference between the two releases is the sum of those deltas, then the current release has been reviewed. Binaries combine that carefully audited source code with an opaque build machine, and the result is not audit able. Releasing source is an act of the foundation. A binary package is an act of the individual who prepared it. The Foundation was not set up to take on the liability associated with binary releases: http://s.apache.org/roy-binary-deps-3 How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. And this from Bertrand [2] To clarify, the ASF only releases source code - votes on releases are not more about source, they are *only* about source. What is the piece I’m missing that says we have to vote to update the binary package? -Alex [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201410.mbox/%3cC AAS6=7hmpfr-matbeppepa0vybo6n35yfxkdttnqnmf+6_g...@mail.gmail.com%3e [2] http://mail-archives.apache.org/mod_mbox/incubator-general/201410.mbox/%3cC AEWfVJ=hfp_oc-byyokjm0opm5a_bxa4+yozdvfvrs3ufzy...@mail.gmail.com%3e
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
Re: Convenience Binary Policy
On 21.10.2014 06:34, Alex Harui wrote: What is the piece I’m missing that says we have to vote to update the binary package? Apparently the Flex community believes that convenience binaries need votes. They don't, but aside from that, if you guys are already voting on binary packages, it makes perfect sense to vote for your fixed version, if only to keep people happy. -- Brane P.S.: Why anyone would think voting on binaries makes any kind of sense around here is, of course, a different question. I can't even begin to count the number of times it's been pointed out that binaries are not Apache releases. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Convenience Binary Policy
On Mon, Oct 20, 2014 at 9:34 PM, Alex Harui aha...@adobe.com wrote: Then this is the Acme Software Foundation installer and you can do what you like. I suppose we could, but it wouldn’t be easily found by folks who arrive at flex.a.o looking for FlexJS. They’ll probably end up using the current Installer and getting an error. I think that the web site could quite reasonably say something like Here is a link to a temporary, unofficial installer that may fix a bug. It should still show the link to the official install as well, of course.
Re: Convenience Binary Policy
On Mon, Oct 20, 2014 at 9:40 PM, Alex Harui aha...@adobe.com wrote: So I am looking for reasons why we can/can’t update a binary package in less time than the whole vote + mirrors latency. I think you can. Just label it according to what it is. You can even link from the web site.
RE: Convenience Binary Policy
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
Re: Convenience Binary Policy
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
Re: Convenience Binary Policy
On Mon, Oct 20, 2014 at 9:45 PM, Branko Čibej br...@apache.org wrote: On 21.10.2014 06:34, Alex Harui wrote: What is the piece I’m missing that says we have to vote to update the binary package? Apparently the Flex community believes that convenience binaries need votes. They don't, but aside from that, if you guys are already voting on binary packages, it makes perfect sense to vote for your fixed version, if only to keep people happy. -- Brane P.S.: Why anyone would think voting on binaries makes any kind of sense around here is, of course, a different question. I can't even begin to count the number of times it's been pointed out that binaries are not Apache releases. And yet that issue keeps rearing its ugly head. Given the amount of traffic I've seen around clarifying some finer (and not so fine) points of release/licensing implication it is about time we start an FAQ on that. Me thinks at least. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
