Yeah, this is part of why we need the guide

On July 5, 2017 at 09:23:03, zeo...@gmail.com (zeo...@gmail.com) wrote:

That all sounds pretty reasonable to me. My biggest concern would be
attribution during step 5 - we would need to make sure it isn't squash
merged like we typically do (assuming we do properly squash merge into
the speculative
branch). Not a big issue though, I guess, just need to make sure it isn't
overlooked.

Jon

On Wed, Jul 5, 2017 at 4:40 AM Matt Foley <ma...@apache.org> wrote:

> Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
> remaining work to separate out Stellar functionality as an independent
> module. A couple people have suggested that this further development
> should be done in a Metron “dev branch”, where:
> a) changes are more visible than in a single person’s private development
> branch, and
> b) work can proceed for several days or a couple weeks on a branch that
> the collaborators may choose to keep stable for the duration (ie, without
> constantly updating to master).
>
> This concept was discussed as a “speculative branch” in this email
thread:
>
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
> but I don’t see that we ever actually changed our bylaws to mention it.
>
> Nevertheless, it falls within the purview of the PMC to create new
> branches in our code tree, and I request PMC members to give me a lazy
> consensus vote to do so. Please +1 this email if you agree.
>
> The proposed rules of engagement are (drawn from issues raised in that
> email thread):
> 1. Commits to this branch to have the same rules as to master: Jira, PR,
> and at least one +1 from a knowledgeable reviewer, and no -1’s.
> 2. +1 reviews may come from any participating contributor, not only
> current committers. But commits still have to be made by a committer, so
> we don’t have to create new auth infra for this branch.
> 3. The branch should be updated from master at least every second week,
or
> more frequently. This may be adjusted to avoid disruption of work in
> progress.
> 4. PR’s to master will be posted for review as soon as self-consistent
> chunks of useful functionality are done. The collaborators will define
> those chunks, but a rough goal is every two weeks. The goal is to avoid
> mega-patches to review.
> 5. PR’s to master will be posted by a single developer from their home
> github repo, not directly from the speculative branch, so that
> collaborative work can proceed on the speculative branch.
> 6. The PR’s will be credited equally to all collaborators active during
> that “chunk” of work.
> 7. PR’s to master have to be reviewed and agreed to as though they were
> new patches. (The fact they were previously accepted into the speculative
> branch is at most a recommendation, not an a priori decision to let them
> into master.) The usual rules apply. While collaborators will likely want
> to +1 such PRs, sufficient time must be provided for other community
> members to review and raise issues.
>
> Thanks,
> --Matt
>
>
>
> --

Jon

Reply via email to