I'd like to see more discussion on the issues I raised. I don't think there was a response for why voting is limited to PMC members.
Tim was kind enough to reply with his rationale for a shepherd, but I don't think that it justifies failing proposals. I think it boiled down to "shepherds can be helpful", which isn't a good reason to require them in my opinion. Sam also had some good comments on this and I think that there's more to talk about. That said, I'd rather not have this proposal fail because we're tired of talking about it. If most people are okay with it as it stands and want a vote, I'm fine testing this out and fixing it later. rb On Fri, Feb 24, 2017 at 8:28 PM, Joseph Bradley <jos...@databricks.com> wrote: > The current draft LGTM. I agree some of the various concerns may need to > be addressed in the future, depending on how SPIPs progress in practice. > If others agree, let's put it to a vote and revisit the proposal in a few > months. > Joseph > > On Fri, Feb 24, 2017 at 5:35 AM, Cody Koeninger <c...@koeninger.org> > wrote: > >> It's been a week since any further discussion. >> >> Do PMC members think the current draft is OK to vote on? >> >> On Fri, Feb 17, 2017 at 10:41 PM, vaquar khan <vaquar.k...@gmail.com> >> wrote: >> > I like document and happy to see SPIP draft version however i feel >> shepherd >> > role is again hurdle in process improvement ,It's like everything >> depends >> > only on shepherd . >> > >> > Also want to add point that SPIP should be time bound with define SLA >> else >> > will defeats purpose. >> > >> > >> > Regards, >> > Vaquar khan >> > >> > On Thu, Feb 16, 2017 at 3:26 PM, Ryan Blue <rb...@netflix.com.invalid> >> > wrote: >> >> >> >> > [The shepherd] can advise on technical and procedural considerations >> for >> >> > people outside the community >> >> >> >> The sentiment is good, but this doesn't justify requiring a shepherd >> for a >> >> proposal. There are plenty of people that wouldn't need this, would get >> >> feedback during discussion, or would ask a committer or PMC member if >> it >> >> weren't a formal requirement. >> >> >> >> > if no one is willing to be a shepherd, the proposed idea is probably >> not >> >> > going to receive much traction in the first place. >> >> >> >> This also doesn't sound like a reason for needing a shepherd. Saying >> that >> >> a shepherd probably won't hurt the process doesn't give me an idea of >> why a >> >> shepherd should be required in the first place. >> >> >> >> What was the motivation for adding a shepherd originally? It may not be >> >> bad and it could be helpful, but neither of those makes me think that >> they >> >> should be required or else the proposal fails. >> >> >> >> rb >> >> >> >> On Thu, Feb 16, 2017 at 12:23 PM, Tim Hunter <timhun...@databricks.com >> > >> >> wrote: >> >>> >> >>> The doc looks good to me. >> >>> >> >>> Ryan, the role of the shepherd is to make sure that someone >> >>> knowledgeable with Spark processes is involved: this person can advise >> >>> on technical and procedural considerations for people outside the >> >>> community. Also, if no one is willing to be a shepherd, the proposed >> >>> idea is probably not going to receive much traction in the first >> >>> place. >> >>> >> >>> Tim >> >>> >> >>> On Thu, Feb 16, 2017 at 9:17 AM, Cody Koeninger <c...@koeninger.org> >> >>> wrote: >> >>> > Reynold, thanks, LGTM. >> >>> > >> >>> > Sean, great concerns. I agree that behavior is largely cultural and >> >>> > writing down a process won't necessarily solve any problems one way >> or >> >>> > the other. But one outwardly visible change I'm hoping for out of >> >>> > this a way for people who have a stake in Spark, but can't follow >> >>> > jiras closely, to go to the Spark website, see the list of proposed >> >>> > major changes, contribute discussion on issues that are relevant to >> >>> > their needs, and see a clear direction once a vote has passed. We >> >>> > don't have that now. >> >>> > >> >>> > Ryan, realistically speaking any PMC member can and will stop any >> >>> > changes they don't like anyway, so might as well be up front about >> the >> >>> > reality of the situation. >> >>> > >> >>> > On Thu, Feb 16, 2017 at 10:43 AM, Sean Owen <so...@cloudera.com> >> wrote: >> >>> >> The text seems fine to me. Really, this is not describing a >> >>> >> fundamentally >> >>> >> new process, which is good. We've always had JIRAs, we've always >> been >> >>> >> able >> >>> >> to call a VOTE for a big question. This just writes down a sensible >> >>> >> set of >> >>> >> guidelines for putting those two together when a major change is >> >>> >> proposed. I >> >>> >> look forward to turning some big JIRAs into a request for a SPIP. >> >>> >> >> >>> >> My only hesitation is that this seems to be perceived by some as a >> new >> >>> >> or >> >>> >> different thing, that is supposed to solve some problems that >> aren't >> >>> >> otherwise solvable. I see mentioned problems like: clear process >> for >> >>> >> managing work, public communication, more committers, some sort of >> >>> >> binding >> >>> >> outcome and deadline. >> >>> >> >> >>> >> If SPIP is supposed to be a way to make people design in public >> and a >> >>> >> way to >> >>> >> force attention to a particular change, then, this doesn't do that >> by >> >>> >> itself. Therefore I don't want to let a detailed discussion of SPIP >> >>> >> detract >> >>> >> from the discussion about doing what SPIP implies. It's just a >> process >> >>> >> document. >> >>> >> >> >>> >> Still, a fine step IMHO. >> >>> >> >> >>> >> On Thu, Feb 16, 2017 at 4:22 PM Reynold Xin <r...@databricks.com> >> >>> >> wrote: >> >>> >>> >> >>> >>> Updated. Any feedback from other community members? >> >>> >>> >> >>> >>> >> >>> >>> On Wed, Feb 15, 2017 at 2:53 AM, Cody Koeninger < >> c...@koeninger.org> >> >>> >>> wrote: >> >>> >>>> >> >>> >>>> Thanks for doing that. >> >>> >>>> >> >>> >>>> Given that there are at least 4 different Apache voting >> processes, >> >>> >>>> "typical Apache vote process" isn't meaningful to me. >> >>> >>>> >> >>> >>>> I think the intention is that in order to pass, it needs at >> least 3 >> >>> >>>> +1 >> >>> >>>> votes from PMC members *and no -1 votes from PMC members*. But >> the >> >>> >>>> document >> >>> >>>> doesn't explicitly say that second part. >> >>> >>>> >> >>> >>>> There's also no mention of the duration a vote should remain >> open. >> >>> >>>> There's a mention of a month for finding a shepherd, but that's >> >>> >>>> different. >> >>> >>>> >> >>> >>>> Other than that, LGTM. >> >>> >>>> >> >>> >>>> On Mon, Feb 13, 2017 at 9:02 AM, Reynold Xin < >> r...@databricks.com> >> >>> >>>> wrote: >> >>> >>>>> >> >>> >>>>> Here's a new draft that incorporated most of the feedback: >> >>> >>>>> >> >>> >>>>> https://docs.google.com/document/d/1-Zdi_W-wtuxS9hTK0P9qb2x- >> nRanvXmnZ7SUi4qMljg/edit# >> >>> >>>>> >> >>> >>>>> I added a specific role for SPIP Author and another one for SPIP >> >>> >>>>> Shepherd. >> >>> >>>>> >> >>> >>>>> On Sat, Feb 11, 2017 at 6:13 PM, Xiao Li <gatorsm...@gmail.com> >> >>> >>>>> wrote: >> >>> >>>>>> >> >>> >>>>>> During the summit, I also had a lot of discussions over similar >> >>> >>>>>> topics >> >>> >>>>>> with multiple Committers and active users. I heard many >> fantastic >> >>> >>>>>> ideas. I >> >>> >>>>>> believe Spark improvement proposals are good channels to >> collect >> >>> >>>>>> the >> >>> >>>>>> requirements/designs. >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> IMO, we also need to consider the priority when working on >> these >> >>> >>>>>> items. >> >>> >>>>>> Even if the proposal is accepted, it does not mean it will be >> >>> >>>>>> implemented >> >>> >>>>>> and merged immediately. It is not a FIFO queue. >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> Even if some PRs are merged, sometimes, we still have to revert >> >>> >>>>>> them >> >>> >>>>>> back, if the design and implementation are not reviewed >> carefully. >> >>> >>>>>> We have >> >>> >>>>>> to ensure our quality. Spark is not an application software. >> It is >> >>> >>>>>> an >> >>> >>>>>> infrastructure software that is being used by many many >> companies. >> >>> >>>>>> We have >> >>> >>>>>> to be very careful in the design and implementation, especially >> >>> >>>>>> adding/changing the external APIs. >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> When I developed the Mainframe infrastructure/middleware >> software >> >>> >>>>>> in >> >>> >>>>>> the past 6 years, I were involved in the discussions with >> >>> >>>>>> external/internal >> >>> >>>>>> customers. The to-do feature list was always above 100. >> Sometimes, >> >>> >>>>>> the >> >>> >>>>>> customers are feeling frustrated when we are unable to deliver >> >>> >>>>>> them on time >> >>> >>>>>> due to the resource limits and others. Even if they paid us >> >>> >>>>>> billions, we >> >>> >>>>>> still need to do it phase by phase or sometimes they have to >> >>> >>>>>> accept the >> >>> >>>>>> workarounds. That is the reality everyone has to face, I think. >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> Thanks, >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> Xiao Li >> >>> >>>>>>> >> >>> >>>>>>> >> >>> >> >> >>> > >> >>> > ------------------------------------------------------------ >> --------- >> >>> > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >> >>> > >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Ryan Blue >> >> Software Engineer >> >> Netflix >> > >> > >> > >> > >> > -- >> > Regards, >> > Vaquar Khan >> > +1 -224-436-0783 >> > >> > IT Architect / Lead Consultant >> > Greater Chicago >> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >> >> > > > -- > > Joseph Bradley > > Software Engineer - Machine Learning > > Databricks, Inc. > > [image: http://databricks.com] <http://databricks.com/> > -- Ryan Blue Software Engineer Netflix
