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