Sean B., Thank you for giving a thorough reply. I will work with Sean O. and see what we can change to make us more in line with the stated policy.
I did some research and it appears that some time between October [1] and December [2] 2006, this page was modified to include stricter policy surrounding nightly builds. Actually, the original version of the policy page encouraged projects to post nightly builds for the benefit of all developers, just as we have been doing. If you detect frustration from the Spark community, it's because this type of situation occurs with some regularity. In this case: (a) A policy exists from ~10 years ago, presumably because some project back then had problematic release management practices and so a "policy" needed to be created to solve a problem. (b) The policy is outdated now, and no one is 100% sure why it was created (likely many of the people are no longer involved in the ASF who helped craft it). (c) The steps for how to change it are unclear and there isn't clear ownership of the policy document. I think it's unavoidable given the decentralized organization structure of the ASF, but I just want to be up front about our perspective and why you might sense some frustration. [1] https://web.archive.org/web/20061020220358/http://www.apache.org/dev/release.html [2] https://web.archive.org/web/20061231050046/http://www.apache.org/dev/release.html - Patrick On Tue, Jul 14, 2015 at 10:09 AM, Sean Busbey <bus...@cloudera.com> wrote: > Responses inline, with some liberties on ordering. > > On Sun, Jul 12, 2015 at 10:32 PM, Patrick Wendell <pwend...@gmail.com> > wrote: >> >> 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: > > > >> >> - Who has the authority to change this document? > > > It's foundation level policy, so I'd presume the board needs to. Since it's > part of our legal position, it might be owned by the legal affairs > committee[1]. That would mean they could update it without a board > resolution. (legal-discuss@ could tell you for sure). > >> >> - What concrete steps can I take to change the policy? > > > The Legal Affairs Committee is reachable either through their mailing > list[2] or their issue tracker[3]. > > Please be sure to read the entire original document, it explains the > rationale that has gone into it. You'll need to address the matters raised > there. > > >> >> - You keep mentioning the incubator@ list, why is this the place for >> such policy to be discussed or decided on? > > > > It can't be decided on the general@incubator list, but there are already > several relevant parties discussing the matter there. You certainly don't > *need* to join that conversation, but the participants there have overlap > with the folks who can ultimately decide the issue. Thus, it may help avoid > having to repeat things. > > >> >> - What is the reasonable amount of time frame in which the policy >> change is likely to be decided? >> > > I am neither a participant on legal affairs nor the board, so I have no > idea. > >> >> 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 > > > > Please keep in mind that you are also "ASF people," as is the entire Spark > community (users and all)[4]. Phrasing things in terms of "us and them" by > drawing a distinction on "[they] get in a fight on our mailing list" is not > helpful. > > >> >> 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. >> > > Understanding and abiding by ASF legal obligations and policies is the job > of each project PMC as a part of their formation by the board[5]. If anyone > in your community has questions about what the project can or can not do > then it's the job of the PMC find out proactively (rather than take a "ask > for forgiveness" approach). Where the existing documentation is unclear or > where you think it might be out of date, you can often get guidance from > general@incubator (since it contains a large number of members and folks > from across foundation projects) or comdev[6] (since their charter includes > explaining ASF policy). If those resources prove insufficient matters can be > brought up with either legal-discuss@ or board@. > > If you find out of date documentation that is not ASF policy, you can have > it removed by notifying the appropriate group (i.e. legal-discuss, comdev, > or whomever is hosting it). > > > [1]: http://apache.org/legal/ > [2]: http://www.apache.org/foundation/mailinglists.html#foundation-legal > [3]: https://issues.apache.org/jira/browse/LEGAL/ > [4]: http://www.apache.org/foundation/how-it-works.html#roles > [5]: http://apache.org/foundation/how-it-works.html#pmc > [6]: https://community.apache.org/ > > -- > Sean --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
