You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Matt Foley <ma...@apache.org> on 2017/07/05 08:40:12 UTC
[Request for Consensus Approval] dev branch for Stellar additional
work
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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Matt Foley <ma...@apache.org>.
Okay, I’ll undertake to add to the committer’s guide before the first PR.
From: Otto Fowler <ot...@gmail.com>
Date: Wednesday, July 5, 2017 at 6:28 AM
To: "dev@metron.apache.org" <de...@metron.apache.org>, Matt Foley <ma...@apache.org>
Subject: Re: [Request for Consensus Approval] dev branch for Stellar additional work
Just want to say, we will need updated versions of the commuter’s guide for doing commits and reviews to branches like this.
The current scripts we use will need to be updated ( as we go ), the we should at least have a plan to provide these guides before the first pr.
On July 5, 2017 at 04:40:16, Matt Foley (mattf@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Otto Fowler <ot...@gmail.com>.
Just want to say, we will need updated versions of the commuter’s guide for
doing commits and reviews to branches like this.
The current scripts we use will need to be updated ( as we go ), the we
should at least have a plan to provide these guides before the first pr.
On July 5, 2017 at 04:40:16, Matt Foley (mattf@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Matt Foley <ma...@apache.org>.
Hey all, it appears that we’re not ready to do speculative branches yet, so I’ll proceed with the next chunk of Stellar separation work in my private branch, currently in https://github.com/mattf-horton/metron/tree/stellar-mod4
There is of course nothing “private” about it; anyone is most welcome to watch, make suggestions, and contribute PRs.
Thanks,
--Matt
On 7/5/17, 10:36 AM, "Otto Fowler" <ot...@gmail.com> wrote:
Yeah, this is part of why we need the guide
On July 5, 2017 at 09:23:03, Zeolla@GMail.com (zeolla@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Otto Fowler <ot...@gmail.com>.
Yeah, this is part of why we need the guide
On July 5, 2017 at 09:23:03, Zeolla@GMail.com (zeolla@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Matt Foley <mf...@hortonworks.com>.
And another way suggested by Jon’s statement, is to not squash the commit, but leave at least one of each committer’s contributions intact. That might not be too hard to add to the prepare-commit script, it’s just an invocation of interactive rebase/squash.
On 7/5/17, 10:32 AM, "Matt Foley" <mf...@hortonworks.com> wrote:
Jon, good point. I was thinking we would just use the commit message to share attribution.
It would be nicer to do something that would be picked up by github’s commit attribution, but unfortunately there is only one “author” field in a git commit metadata. There are discussions online about allowing multiple instances of that field, and the maintainers don’t seem willing to do so currently. There seems to be considerable support in the community for putting a LIST of authors in that single field; see:
https://stackoverflow.com/questions/7442112/attributing-a-single-commit-to-multiple-developers
and perhaps even this tool:
https://github.com/chrisk/git-pair
but it isn’t clear that github can correctly extract the email addresses in that case. Github uses the metadata emails to attribute authorship, see
https://help.github.com/articles/updating-commit-author-attribution-with-github-importer/
I’d be willing to experiment a little to see if github can pick up multiple emails, but I wouldn’t bet on it.
Another way to do it would be with trivial commits following the real commit, one per additional author besides the committer. This method would count commits correctly, but not LOC.
--Matt
On 7/5/17, 6:22 AM, "Zeolla@GMail.com" <ze...@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by Matt Foley <mf...@hortonworks.com>.
Jon, good point. I was thinking we would just use the commit message to share attribution.
It would be nicer to do something that would be picked up by github’s commit attribution, but unfortunately there is only one “author” field in a git commit metadata. There are discussions online about allowing multiple instances of that field, and the maintainers don’t seem willing to do so currently. There seems to be considerable support in the community for putting a LIST of authors in that single field; see:
https://stackoverflow.com/questions/7442112/attributing-a-single-commit-to-multiple-developers
and perhaps even this tool:
https://github.com/chrisk/git-pair
but it isn’t clear that github can correctly extract the email addresses in that case. Github uses the metadata emails to attribute authorship, see
https://help.github.com/articles/updating-commit-author-attribution-with-github-importer/
I’d be willing to experiment a little to see if github can pick up multiple emails, but I wouldn’t bet on it.
Another way to do it would be with trivial commits following the real commit, one per additional author besides the committer. This method would count commits correctly, but not LOC.
--Matt
On 7/5/17, 6:22 AM, "Zeolla@GMail.com" <ze...@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
Re: [Request for Consensus Approval] dev branch for Stellar
additional work
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
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