I'm not sure that we are agreeing that features don't have architectural changes. I'm saying that architectural shifts need to be brought out as part of a discuss thread so we have a clear mandate for the feature branch. Of course, once in the heat of battle, it's very possible that a new or unanticipated architectural change might need to be included. At that point, I would say that the mandate for the individual feature branch should be widened in light of the evidence via a discuss thread. I'm proposing the codification being a discuss thread with lazy consensus of the committers and community. Most of the discussions that I've seen has been healthy discussion that lead to compromise and we have some good examples of this already (e.g. pcap comes to mind most readily).
On Sat, Sep 29, 2018 at 9:16 AM Otto Fowler <ottobackwa...@gmail.com> 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 (justinjl...@gmail.com) > 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 (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 > > > > > > > > > > > > > > >
