metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <ma...@apache.org>
Subject [Request for Consensus Approval] dev branch for Stellar additional work
Date Wed, 05 Jul 2017 08:40:12 GMT
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




Mime
View raw message