Community: Separating proposals and architecture related items from community

[timothysc]

IMO proposals and architecture related items probably belong in their own repo now, this repo is starting to become overloaded.

/cc @jbeda @kubernetes/sig-architecture-bugs

[thockin]

+1 - I subscribed to this repo to keep track of KEPs but am overwhelmed by
everything else

On Mon, Aug 20, 2018 at 6:31 PM Timothy St. Clair [e-mail]
wrote:

IMO proposals and architecture related items probably belong in their own
repo now, this repo is starting to become overloaded.

/cc @jbeda https://github.com/jbeda @kubernetes/sig-architecture-bugs
https://github.com/orgs/kubernetes/teams/sig-architecture-bugs

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/community/issues/2565, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVKiuYn3hlIm3V563RzcN-Aa1eW8Eks5uS2L1gaJpZM4WE9Ry
.

[parispittman]

+1

[bgrant0607]

I'd want design-proposals and some docs that are currently in devel to move, as well.

Any move needs to preserve git history and leave behind forwarding links for a fair bit of time.

There's no way to move PR comments AFAIK.

[mdlinville]

You can copy and close an issue with Zenhub, which installs itself as a browser plugin and overlays some additional functionality into the Github UI. This is used in Docker and Moby repos, for instance, to move mis-filed issues to the correct repo. Of course, a PR is quite different as it actually represents a comparison between two Git objects. You probably just have to open a new PR in the new repo (which presumably has different history and file structure / locations), and link back to the original PR. It's difficult to understand how you'd automate or script this, even using Github APIs.

[justaugustus]

+1 -- I think this might be a good fit for https://github.com/kubernetes-sigs/architecture-tracking, as tracking for KEPs, API reviews, and conformance testing is already happening there.

/assign @jdumars

---

@mistyhacks -- w.r.t. Zenhub, I've used it in the past and dig it, but it requires write access across the kubernetes org, which we're not excited about.

rel:

• https://github.com/ZenHubIO/support/issues/910
• https://kubernetes.slack.com/archives/C1TU9EB9S/p1530651276000365

[justaugustus]

Alternatively, we could move the KEPs to k/features and maybe rename to k/keps.
A lot of the tracking work for enhancement delivery already lives in that repo.

[nikhita]

Federation was moved out from k/k to k/federation with all issue comments still intact. Example: https://github.com/kubernetes/kubernetes/issues/38893 and https://github.com/kubernetes/federation/issues/88.

I'm not sure if some custom tool was used for this or if this was done manually (I hope not because that would be such a huge task!). @irfanurrehman can you elaborate on what you used to make sure all comments migrate so cleanly? :)

[irfanurrehman]

@nikhita I used a hacky, custom version of https://github.com/IQAndreas/github-issues-import.
The not so nicely done hacky commits are available for reference at https://github.com/irfanurrehman/github-issues-import.

It worked as:

1. List commits with needed labels from src repo using ./list-sig-multicluster-only-issues.py --all.
2. Migrate issues using the actual script, for example: ./gh-issues-import.py --issues 25 26 29.

I remember facing some issues, and fixing some, and then further using some hard coded stuff specific to my job.
I recommend trying it out, one issue at a time first to see everything works fine before submitting the batch, given that its not really a maintained code.

[jdumars]

Big +1 on this. It's definitely time.

[justaugustus]

Adding myself to this as well.
/sig pm
/assign

[justaugustus]

@bgrant0607 -- in an attempt to level up my git-fu, I took a whack at moving keps/ and design-proposals/, while maintaining the history. PR is here: https://github.com/kubernetes/features/pull/613

If we're happy with moving them to k/features and renaming the repo to k/keps, then there are some additional things that would need to happen as well (not necessarily in perfect order)...

• announce the forthcoming change
• merge the k/features PR
• set up blockade to prevent pushes to either dir in k/community
• rename k/features to k/keps
• migrate KEP / design proposal PRs to k/keps
• create tombstones for files in both dirs in k/community
• fix KEP / proposal links in k/keps issues
• update docs in k/keps to clarify process
• figure out the best way to reconcile the multiple OWNERS files between the two repos

Additionally, you wanted to move some of the files in contributors/devel out. Any ones specifically? A lot of them seem like they'd be good additions to a developer's guide, while others might fit in a dir like k/community/architecture.

Let me know what you think! :)

[bgrant0607]

From a quick scan of devel, I'd move:

https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md
https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md (or at least parts of it)
https://github.com/kubernetes/community/blob/master/contributors/devel/arch-roadmap-1.png (which needs to be updated, but is what we have)
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md (ditto)
https://github.com/kubernetes/community/blob/master/contributors/devel/component-config-conventions.md
https://github.com/kubernetes/community/blob/master/contributors/devel/conformance-tests.md (or at least test requirements)
https://github.com/kubernetes/community/blob/master/contributors/devel/strategic-merge-patch.md

cc @spiffxp

[timothysc]

Can we enqueue this for the @kubernetes/sig-architecture-feature-requests call this week to discuss?

[spiffxp]

Most of the docs @bgrant0607 lists above I wouldn't envision moving out of this repo. Aspirational docs, design proposals and roadmaps, yes, move to a keps/features repo.

Stated conventions developers should follow and reasons why, no, those should stay here IMO. Like @justaugustus said, those make more sense to me in a developers guide, which I would prefer to keep in close proximity to the contributor's guide.

@justaugustus you'll want to merge tombstones before you turn on blockade

We've been getting less traffic against design-proposals than we have historically, so it may be worth considering whether it's time to deprecate them, and move fully to KEPs. This seems like a good trigger for that conversation.

[justaugustus]

We've been getting less traffic against design-proposals than we have historically, so it may be worth considering whether it's time to deprecate them, and move fully to KEPs. This seems like a good trigger for that conversation.

@spiffxp -- this is exactly the effect I was hoping for.
(thanks for the tip on the tombstones!)

---

@timothysc -- I've put up an agenda item for the 9/6 SIG Arch meeting.

While I won't be able to attend most of the SIG Arch meetings for September, I intend to drive this with @jdumars, as it would fall under the scope of maturing the enhancement delivery process (an initiative the two of us are undertaking), which cross-cuts Arch, PgM, and PdM.

[mrbobbytables]

@justaugustus -- This issue came up up at this weeks contribex meeting with regard to the contributor site (site | project). KEPs are currently displayed there along with other content from the k/community repo after being converted to a hugo friendly format. When the KEPs do relocate, the site-generation script will need to be updated to pull the additional repo and do some minor conversion. This should not be difficult, but should be coordinated with the migration.

[bgrant0607]

@spiffxp On my proposed docs to move:

I agree that some contributor-focused docs on these topics need to land in the contributor doc site.

One problem right now is that most of our docs don't have a sense of who the audience is, so they mix many topics -- part design doc, part policy, part contributor instructions, part user documentation, etc. The API conventions is one example. We need user-facing docs on kubernetes.io to explain to operators and to client developers (2 audiences/personas) what common behaviors and patterns they can expect and rely on. We need a design doc (or multiple docs) to explain why things are the way they are. We need policy: MUST, SHOULD, MAY, NOT, etc. And we need a how-to guide. And a check list. And a linter. And probably other things.

If we leave these where they are for now, we should at least ensure that docs containing policy have proper OWNERS.

[justaugustus]

@bgrant0607 @jdumars -- I've created a KEP to capture the feedback provided here and across the last few SIG Architecture meetings about KEP process improvement: https://github.com/kubernetes/community/pull/2655
Open for comments!

To the devel docs discussion, I think we should drive that down as a separate effort, with Brian's suggestion of ensuring OWNERS are in place for all subdirectories being a good first step.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[justaugustus]

No you don't, @fejta-bot ...
/remove-lifecycle stale
/lifecycle frozen

[nikhita]

:wave: bump, what's still remaining here?

[parispittman]

fyi @gkarthiks has been working on cleaning up whats left of the design proposals folder and shepherding the creation of KEPs for those that need it, etc.

[gkarthiks]

yeah, so far have got 4 PR's moved/closed/concluded. Working with the rest of it. Will keep posted on the progress.

[mrbobbytables]

With it being a little over a month since the last ping -- I think we should set a cut off date 3/24 (the date of 1.18's release) for the remaining design proposal PRs, close them and move it over to k/enhancements for archival purposes.

@gkarthiks do you want to do 1 last ping with a note about the close date on those PRs?

[justaugustus]

/remove-sig pm
/area enhancements
/unassign @jdumars

[gkarthiks]

/assign @gkarthiks

[gkarthiks]

hi @mrbobbytables, I was OOO for last month. Just returned back; sorry I missed your cut-off date.

With the kind/design label there's only one MR and kinda active that is. Posted a comment in that. Can we re-consider the cut-off date again?

[gkarthiks]

@mrbobbytables we don't have any open MR's apart from the one which was with the design label but yo said not to worry about that (https://github.com/kubernetes/community/pull/4648#issuecomment-614617157). Should we close this issue then?

[mrbobbytables]

@gkarthiks Nope -- this should remain open for now until they're actually migrated out. We setup blockade to prevent any PRs from being merged that touch the design-proposal directory for the interim. 👍

[markyjackson-taulia]

/remove-lifecycle frozen

[gkarthiks]

@mrbobbytables I think all of those are moved or archived. I don't see any with kind/design here .

Do you want to close this?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[mrbobbytables]

/remove-lifecycle stale

I think the remaining item on this is for arch to do a review to see what items should be moved over to devel (e.g. resource-management) before we can migrate the rest to live with enhancements.

/assign @dims @johnbelamaric @derekwaynecarr

[dims]

@navidshaikh do you want to take this on and help with?