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
