What do you think would strike the right balance, ideally? On Sat, Sep 29, 2018, 7:16 AM Otto Fowler <[email protected]> wrote:
> This is all well and good for feature branches, but does nothing for Simon > and the type of work he attempted. > If we agree that features do not have architectural changes, then we also > need to codify how we handle that level of change, assuming > anyone is optimistic enough to attempt such a thing in the future as an > individual, non-hw contributor. > > > > > On September 28, 2018 at 16:58:04, Justin Leet ([email protected]) > wrote: > > +1 to both points. > > I'm in favor of keeping architectural changes limited in a feature branch. > Architectural challenges beyond the scope of the branch should be brought > back to the community for any necessary discussion. > > I don't think we've ever formalized what exactly closes out a feature > branch in terms of consensus. Typically we've been getting a few +1's and > calling it a day. It's probably worth it to formalize it while we're > already in the bylaws, assuming there's consensus on changing them. > > In terms of wording, maybe something like the following (but better): > > Feature Branch > Large feature changes may be made in a speculative feature branch. A > DISCUSS thread should be started on the primary project development mailing > list ([email protected]) to propose the feature and outline minimum > architectural changes. Architectural changes are limited based on the > discuss thread unless further discussion occurs. To close the feature > branch, start a DISCUSS thread to outline branch state and solicit overall > feedback and requests. The branch can be committed after <whatever we > codify as feature branch consensus>. > > On Fri, Sep 28, 2018 at 2:26 PM Michael Miklavcic < > [email protected]> wrote: > > > +1 to those 2 bullet points Casey. And thanks Justin for adding the Jira > > for fixing the website. > > > > I can think of 2 good examples to borrow from recently that were > submitted > > by community contributors. Shane Ardell brought up a discussion about > > migrating from Protractor to Cypress, and Tamas Fodor brought up a > > discussion about migrating from momentjs to date-fns. This greases the > > skids by engaging community members and explaining the scope of proposed > > changes. As always, committers are able to -1 something at any time, so I > > would imagine that any contributor would be well advised to get as much > buy > > in as possible prior to any large undertaking. And I would expect those > > PR's to reference the original DISCUSS threads when they come to > fruition. > > > > Another example comes to mind from Ryan M with his PCAP feature branch. > It > > was a lot of work, but Ryan put out a DISCUSS thread back in, I think it > > was May, outlining the intent for the FB. Subsequently, he followed up at > > the end with an accounting of all the requests from the original DISCUSS > > and any deviations from that along the way, and provided a clear > > explanation of what was in, what wasn't, what should be followed up with, > > and why. In fact, at one point I think there were some library changes > that > > we saw as orthogonal to the intent of the FB and suggested they be made > > outside of the FB. Imho, this FB worked out well, though take this with a > > grain of salt as I may be biased because I was also involved with a > number > > of PRs. > > > > I think Nick Allen also put together a good archetype for a FB with his > > recent work on the batch profiler. I see a couple introductory DISCUSS > > threads about the FB along with some back and forth around introducing > > Spark into the stack. He also followed up at the end to make sure there > > wasn't anything further the community wanted before he pushed to have the > > branch merged into master. > > > > *TL;DR* - We've learned a lot since the earlier days of the project, and > > our subsequent feature branches have gotten much better. We should take > the > > lessons learned along the way and formalize them as Casey is recommending > > in our bylaws. I'll be following up with more specific thoughts on > > language. > > > > Best, > > Mike > > > > > > On Fri, Sep 28, 2018 at 10:13 AM Justin Leet <[email protected]> > > wrote: > > > > > Ticket created: https://issues.apache.org/jira/browse/METRON-1799 > > > > > > I think that whole '/develop' is orphaned and can be dropped. > > > > > > On Fri, Sep 28, 2018 at 12:12 PM Casey Stella <[email protected]> > > wrote: > > > > > > > I just noticed this, but googling "metron bylaws" yields > > > > http://metron.apache.org/develop/bylaws.html which is not our > bylaws. > > > Our > > > > bylaws are on > > > > > > https://cwiki.apache.org/confluence/display/METRON/Apache+Metron+Bylaws > > > > > > > > We should fix that. > > > > > > > > On Fri, Sep 28, 2018 at 12:02 PM Casey Stella <[email protected]> > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > Given discussions about the current high-profile feature branch > (Knox > > > > > SSO), I thought it might be appropriate to have a conversation > about > > > what > > > > > constitutes a feature branch and get some of this encoded in the > > > > community > > > > > guidelines. > > > > > > > > > > Specifically, there was the request made that we split up the Knox > > SSO > > > > > feature branch due to the current implementation including a > > distinct, > > > > new > > > > > architectural change (specifically, in my mind, the migration from > > > > > expressjs to Spring Boot + Zuul). In that discussion, I made the > > > > assertion > > > > > that "for my mind a feature branch should involve the minimum > > > > > architectural change to accomplish a given feature." (I apologize > for > > > > > quoting myself here ;) . I realize, however, that we have not > encoded > > > > > this in our bylaws and I might not be speaking with the authority > of > > > the > > > > > community at my back. > > > > > > > > > > Ultimately, I feel very sad that we didn't get around to clarifying > > > this > > > > > and we're in a situation where, had we made this clarification > > earlier, > > > > > we'd not be in a situation where a contributor has to make a major > > > > > refactoring to a substantial feature. To that end, I think we > should > > > > > hammer this out once and for all so it's clear. > > > > > > > > > > So, I'd like to separate out this discussion here. My justification > > > for > > > > > my belief (beyond that I think it's the correct thing to do) was > the > > > > > precedent set with 777, admittedly pre-feature branches, wherein we > > > > > requested a series of splits to get to smaller units of > functionality > > > and > > > > > isolate large architectural changes. I think that it is good > > practice > > > to > > > > > isolate major feature changes to separate feature branches to > ensure > > > that > > > > > we get sufficient discussion around each of those changes. To that > > > end, > > > > > I'd like some language encoded into the bylaws describing this. > > > > > > > > > > So, I'm opening up the discussion. Most specifically what I'd like > > to > > > > > know is: > > > > > > > > > > - What do you think about the idea that feature branches should > > > > > contain the minimal architectural changes to accomplish a feature > > > > (unless > > > > > the full scope of architectural changes are mentioned in the > > discuss > > > > thread > > > > > about the feature)? > > > > > - If you agree (or disagree), do you think a change to the bylaws > > is > > > > > merited to encode this policy? If you do think so, then what > > > wording > > > > would > > > > > you suggest? > > > > > > > > > > > > > > > Hopefully that all makes sense. > > > > > > > > > > Casey > > > > > > > > > > > > > > >
