metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [Request for Consensus Approval] dev branch for Stellar additional work
Date Wed, 05 Jul 2017 13:22:48 GMT
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


On Wed, Jul 5, 2017 at 4:40 AM Matt Foley <> 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:
> 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
> --


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message