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