Re: [DISCUSS] Modify bylaws to allow speculative branches

[James Sirota <js...@apache.org>]

Hi Guys,

I would like to put this up for a vote.  We would modify the bylaws with the following:

Significant, pervasive features are often developed in a speculative branch of the repository. The PMC may grant commit rights on the branch to its consistent contributors, while the initiative is active. Branch committers are responsible for shepherding their feature into an active release and do not cast binding votes or vetoes in the project.  The branch committers are also responsible for filing Jiras related to the development and should associate branch commits to appropriate Jiras. The acceptance criteria and the review process for a branch commit would be relaxed, limited primarily to top-level conceptual review, until the branch is merged back into master.

Thanks,
James 



24.04.2017, 14:55, "James Sirota" <js...@apache.org>:
> The concrete example where this would be used is the Alerts UI branch that Raghu is currently working on:
> https://github.com/iraghumitra/metron-alerts
>
> It would require a lot of feedback from the community and would need to iterate rapidly. Branch review in this sense would mean that people take a top-level glance at the UI and provide feedback. A more formal review would happen prior to the branch being merged back into master.
>
> Thanks,
> James
>
> 24.04.2017, 09:17, "Justin Leet" <ju...@gmail.com>:
>>  I'd prefer to still keep "Review then Commit" but I'd be interested in
>>  lowering the review bar for it as long as the branch gets a solid final
>>  review before merge. I don't think a feature branch needs to be
>>  micromanaged, but people should still take a quick glance at the commits
>>  that come through. My stance on this may change if we find feature commits
>>  stagnating for periods of time.
>>
>>  Basically, what I'd be looking for out of a feature branch is something
>>  that's:
>>  * Implementing a feature too large or with too much experimentation for a
>>  single PR.
>>  * Is at least looked at semi-regularly to have the opportunity for the
>>  community to point out issues or scalability concerns without minor
>>  concerns being blockers to progress. Otherwise, it's no different from a
>>  giant PR that doesn't get examined until the PR is made.
>>  * Reviews should only very rarely be blockers to progress continuing along
>>  the branch. The branch shouldn't grind to a halt periodically or even
>>  significantly slow progress to cleanup syntax or similar things. The
>>  tradeoff for this is I'd expect refactoring in a lot of cases before it
>>  hits master to catch up on any of these things that we do care about, but
>>  that aren't as important while the branch gets built up initially.
>>  * Kept reasonably up to date with master. I really don't want a feature
>>  branch sitting out for three months without being synced and then suddenly
>>  everything explodes when we try to bring it back. It just causes all sorts
>>  of review and testing issues.
>>  * Ideally managed so that squashing multiple people's commits appropriately
>>  is not a horrible nightmare.
>>  * (Hopefully) able to be merged into master more smoothly as it's gotten
>>  the major concerns cleaned out along the way.
>>
>>  Ideally, we also use this sort of framework to avoid some of the large PRs
>>  we've seen around different features that felt very hard to get a grasp of
>>  and review.
>>
>>  I'm pretty ambivalent on branch committers, and I'd be curious to get some
>>  opinions (or possibly experiences if anyone has some) before I form a solid
>>  opinion.
>>
>>  On Mon, Apr 24, 2017 at 12:01 PM, Michael Miklavcic <
>>  michael.miklavcic@gmail.com> wrote:
>>
>>>   "Branch committers ... do not cast binding votes or vetoes in the project."
>>>   It sounds similar to what we do for other PRs except in this case it's 1..n
>>>   contributors instead of just one. The step for getting the feature branch
>>>   merged into trunk sounds reasonable and clear enough, but as Casey
>>>   mentioned I'm also curious what the commit/review lifecycle looks like
>>>   while the feature branch is active.
>>>
>>>   On Fri, Apr 21, 2017 at 4:00 PM, Casey Stella <ce...@gmail.com> wrote:
>>>
>>>   > So, what would that look like from a practical perspective?
>>>   > * I presume commits would still associate to a JIRA, right?
>>>   > * Are you proposing changing the strategy from Review then Commit to
>>>   Commit
>>>   > then Review for these branches?
>>>   >
>>>   > I know that we have some people who are active in the Hadoop project on
>>>   the
>>>   > PMC as mentors or are in more established projects with this kind of
>>>   thing,
>>>   > can you guys chime in about how that looks like and make some suggestions
>>>   > as to some gotchas?
>>>   >
>>>   > Casey
>>>   >
>>>   > On Fri, Apr 21, 2017 at 5:19 PM, James Sirota <js...@apache.org>
>>>   wrote:
>>>   >
>>>   > > Looking at Hadoop's bylaws
>>>   > >
>>>   > > https://hadoop.apache.org/bylaws.html
>>>   > >
>>>   > > They have this:
>>>   > >
>>>   > > Significant, pervasive features are often developed in a speculative
>>>   > > branch of the repository. The PMC may grant commit rights on the branch
>>>   > to
>>>   > > its consistent contributors, while the initiative is active. Branch
>>>   > > committers are responsible for shepherding their feature into an active
>>>   > > release and do not cast binding votes or vetoes in the project.
>>>   > >
>>>   > > I would like to have something similar in our bylaws where we can have
>>>   > > feature branches with their own set of committers. We may have
>>>   > > prototype-grade features that need to be rapidly evolved with the
>>>   > feedback
>>>   > > from the community. So we would need a lighter process to evolve these
>>>   > > features rapidly, while still keeping the community involved. A more
>>>   > > rigorous review process can then be applied when the feature is more
>>>   > mature
>>>   > > and is ready to be committed into master.
>>>   > >
>>>   > > What do you think?
>>>   > >
>>>   > > -------------------
>>>   > > Thank you,
>>>   > >
>>>   > > James Sirota
>>>   > > PPMC- Apache Metron (Incubating)
>>>   > > jsirota AT apache DOT org
>>>   > >
>>>   >
>
> -------------------
> Thank you,
>
> James Sirota
> PPMC- Apache Metron (Incubating)
> jsirota AT apache DOT org

------------------- 
Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org