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 > > >
