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 >
