-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend subproject and repo generation for generator app #2731
Conversation
674d3b2
to
d1ebb61
Compare
d1ebb61
to
cb9fb89
Compare
@timothysc -- Fixed up. |
I'd like an explicit thumbs up directionally from @spiffxp (as he placed the hold) before we move forward with any sort of lazy consensus. |
cb9fb89
to
9b9fcf7
Compare
9b9fcf7
to
13b53d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the whole I still feel like this doesn't provide much benefit for the additional complexity it introduces.
Also the Subproject.Chairs
change didn't show up in my files view during review, but I'm pretty opposed to that. My suggested Owners
compromise is what this should be instead.
@@ -109,6 +120,7 @@ type Group struct { | |||
Leadership LeadershipGroup `yaml:"leadership"` | |||
Meetings []Meeting | |||
Contact Contact | |||
Repos []Repo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm opposed to this:
- working groups don't own code
- sigs don't own code directly, they own subprojects that own code
// Subproject represents a specific subproject owned by the group | ||
type Subproject struct { | ||
Name string | ||
Description string | ||
Label string | ||
Chairs []Person | ||
Repos []Repo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm opposed to this. Take the existing owners list and convert it into repos or subdirs via a helper function for display if you want, but don't add the complexity here.
Owners []string | ||
Meetings []Meeting | ||
Contact *Contact |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with this.
// Subproject represents a specific subproject owned by the group | ||
type Subproject struct { | ||
Name string | ||
Description string | ||
Label string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this should be omitempty
// Subproject represents a specific subproject owned by the group | ||
type Subproject struct { | ||
Name string | ||
Description string | ||
Label string | ||
Repos []Repo | ||
Owners []string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here's an example of how you could add the human info, while preventing it from falling out of data with the OWNERS files:
- change this to
OwnersFiles []string
- add a field
Owners []Person
- update app/generator to verify that the people listed in
Owners
are actually present in theOwnersFiles
asapprovers
You have to do that third step though. If you don't, then you're left with two sources of truth as to who has the final say, and that's more confusing than the situation today.
Signed-off-by: Stephen Augustus <foo@agst.us>
13b53d8
to
7826d87
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justaugustus If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
For the record: this is currently blocked on Steering, since we need docs for what a subproject "lead" means and the processes around it before we can add fields for it in sigs.yaml. |
/close We will come back to this via https://github.com/kubernetes/community/issues/1673#issuecomment-484746226 |
@spiffxp: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Adds a
Repo
struct and additional fields to theSubproject
andGroup
structs of the generator app.This adds some granularity to allow you to define:
ChairsContacts...or decide to continue using the OWNERS files for subprojects. :)
I've created a gist that you can pull to test or view an example of the structure:
It also cleans up some syntax nits.
Fixes: #2619
Related: #1913
/kind feature
/sig contributor-experience
Signed-off-by: Stephen Augustus foo@agst.us