To move this forward, I think one of two things needs to happen: 1. Move this guidance to the wiki. Seems that people gathered here believe that resolves the issue. Done.
2. Put disclaimers on the current downloads page. This may resolve the issue, but then we bring it up on the right mailing list for discussion. It may end up at #1, or may end in a tweak to the policy. I can drive either one. Votes on how to proceed? On Tue, Jul 14, 2015 at 7:39 PM, Sean Busbey <bus...@cloudera.com> wrote: > Point well taken. Allow me to walk back a little and move us in a more > productive direction. > > I can personally empathize with the desire to have nightly builds. I'm a > passionate advocate for tight feedback cycles between a project and its > downstream users. I am personally involved in several projects that would > benefit from nightly builds and would love to see change in this policy, if > only to get an example of an implementation that's not buried on a project > wiki. > > My interest here in Spark is two-fold. First, protecting the foundation via > its established policies. To this end I periodically look for projects that > show up as non-compliant. Second, it seems like the Spark community has some > friction with larger ASF processes and I'd like to smooth that out where I > can help do so. (I guess this is my way of saying that for better or worse > this isn't a drive by ;) ) > > One reason to throw in with general @ incubator thread is that there are > like-minded PPMCs and it is a known location for other PMCs to easily join > in. Since you are a PMC you'll have enough standing with legal-discuss to > not need someone else on your side of the request, but more PMCs helps to > show the demand. > > We could go directly to legal-discuss with just the question of labeling the > nightly section of our download page as "developer only." I'm skeptical that > this will be accepted given the tone of the guidance document. > > One possible compromise position is the one taken by Apache Open Office. > They have two download pages, one for thr general public and one for project > QA and localization volunteers. > > http://ooo-site.apache.org/download/devbuilds.html > > I didn't suggest this alternative earlier because I haven't verified yet > that it meets the standard of the guidance, and I am reasonably certain that > the dev wiki page does. > > How about we reach out to the OO PMC and see if they've proactively checked? > If not we can go as a group to legal-discuss. > > -- > Sean > > On Jul 14, 2015 12:28 PM, "Mark Hamstra" <m...@clearstorydata.com> wrote: >>> >>> 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. >> >> <whine>But they started it!</whine> >> >> A bit more seriously, my perspective is that the Spark community and >> development process works very well and quite smoothly. The only >> significant strains that I have witnessed during the time in which Spark has >> been Apache Spark have been when "ASF people" who otherwise have neither >> contributed to Spark development nor participated in the Spark community >> parachute in to tell us that we are doing things wrong and that we must >> change our practice in order to conform to their expectations of "The Apache >> Way". Sometimes those admonitions are based on actual Apache bylaws and/or >> legal requirements, and we need to take them seriously. Other times they >> have seemed more subjective and have felt more like meddling or stirring up >> trouble in the community and with a process that is actually working very >> well. >> >> 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
