+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 (dev@metron.apache.org) 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 < michael.miklav...@gmail.com> 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 <justinjl...@gmail.com> > 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 <ceste...@gmail.com> > 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 <ceste...@gmail.com> > > 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 > > > > > > > > > >
