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