Hey Sean B, Would you mind outlining for me how we go about changing this policy - I think it's outdated and doesn't make much sense. Ideally I'd like to propose a vote to modify the text slightly such that our current behavior is seen as complaint. Specifically:
- What concrete steps can I take to change the policy? - Who has the authority to change this document? - You keep mentioning the incubator@ list, why is this the place for such policy to be discussed or decided on? - What is the reasonable amount of time frame in which the policy change is likely to be decided? We've had a few times people from the various parts of the ASF come and say we are in violation of a policy. And sometimes other ASF people come and then get in a fight on our mailing list, and there is back and fourth, and it turns out there isn't so much a widely followed policy as a doc somewhere that is really old and not actually universally followed. It's difficult for us in such situations to now how to proceed and how much autonomy we as a PMC have to make decisions about our own project. - Patrick On Sun, Jul 12, 2015 at 7:52 PM, Sean Busbey <bus...@cloudera.com> wrote: > Please note that when the policy refers to "developers" it means the > developers of the project at hand, that is participants on the dev@spark > mailing list. > > As I stated in my original email, you're welcome to continue the discussion > on the policy including the definition of developers on general@incubator. > But please comply with foundation policy before seeking to have it changed. > > Just to set expectations, "this feature was specifically requested by > developers from other projects that integrate with Spark" sounds like > exactly the kind of thing the policy seeks to prevent. The standing guidance > is "release more often" if downstream projects need to integrate with > features faster. > > On Sun, Jul 12, 2015 at 4:26 PM, Patrick Wendell <pwend...@gmail.com> wrote: >> >> Thanks Sean O. I was thinking something like "NOTE: Nightly builds are >> meant for development and testing purposes. They do not go through >> Apache's release auditing process and are not official releases." >> >> - Patrick >> >> On Sun, Jul 12, 2015 at 3:39 PM, Sean Owen <so...@cloudera.com> wrote: >> > (This sounds pretty good to me. Mark it developers-only, not formally >> > tested by the community, etc.) >> > >> > On Sun, Jul 12, 2015 at 7:50 PM, Patrick Wendell <pwend...@gmail.com> >> > wrote: >> >> Hey Sean B., >> >> >> >> Thanks for bringing this to our attention. I think putting them on the >> >> developer wiki would substantially decrease visibility in a way that >> >> is not beneficial to the project - this feature was specifically >> >> requested by developers from other projects that integrate with Spark. >> >> >> >> If the concern underlying that policy is that snapshot builds could be >> >> misconstrued as formal releases, I think it would work to put a very >> >> clear disclaimer explaining the difference directly adjacent to the >> >> link. That's arguably more explicit than just moving the same text to >> >> a different page. >> >> >> >> The formal policy asks us not to include links "that encourage >> >> non-developers to download" the builds. Stating clearly that the >> >> audience for those links is developers, in my interpretation that >> >> would satisfy the letter and spirit of this policy. >> >> >> >> - Patrick >> >> > > > > > -- > Sean --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org