-
Notifications
You must be signed in to change notification settings - Fork 236
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
Rename knative-sandbox github org #169
Comments
I'm plus 👍 for using another name as sandbox as the name is really associated as being kind of a playground. If there is supposed to be only one single organisation, then I think something generic like However, we can also have multiple organisations reflecting the different purpose as mentioned above:
I could imagine, that If 4 orgas are too much of an overhead I could imagine to skip So, I can imagine kind of three setup for orgas in addition to
OR:
and experimental projects life somewhere else (e.g. in personal accounts) OR:
|
For the sake of completeness: |
But isn't the "core" also part of the 'ecosystem' ? |
Now that we moved most repositories, I think it is time to refocus on this conversation. If anyone has more suggestions, please speak out, and may be we will start voting / deciding next week? @rhuss raised a good point in #169 (comment) that we should be mindful of even more orgs being created in the future when choosing a new name for Throwing a few into the mix:
|
I gave this feedback on the google doc, but recording here my 2 cents. I think I think we need a place for proper extensions/plugins to keep the core smaller and leaner, same way we have Linux core/kernel and then we have modules/extension/modules. So I propose For now, I would not have more orgs to keep things simple, just for now. |
Sounds good to me, but as you don't callout organisation names not that much like repository names, I wonder whether an abbreviation is needed here.
Beside the same argument as above, I don't think "ecosystem" really hit the nail, as the "core" ( repo 'knative') IS also part of the 'ecosystem', so that name doesn't really indicates that it is an addition and complementary to the core ("knative").
that doesn't wring any bell to me. |
I'm totally fine with having three repositories:
As mentioned above, I think even the first level (the 'sandbox') part could be skipped in the beginning, as experimentation can happen elsewhere, too (e.g. in personal projects). So not whether the benefits (higher visibility) out-rule the extra efforts needed to maintain such an organization. |
Friendly ping @pmorie |
+1 for Can we get this resolved soon? What is blocking the conversation? I think it's important to decide this soon with things like Functions becoming part of "core" Knative but still living in the "sandbox" - it's going to cause more work long term to update any docs etc that are created for this if the repo is renamed later. |
@abrennan89 thanks for reviving this. We do have plans to move knative-sandbox/kn-plugin-func to the knative org. But this is a lot of work and may take some time. I am also open to discussing a name change for knative-sandbox that leaves functions in without indicating that it's somehow experimental. /cc @knative/technical-oversight-committee |
For me there is a slight difference between |
I feel that while it might make sense to rename the org, it will cause a lot (really a lot) of work as the organization's name shines through in so many places. We might not even be aware of (CI jobs, brew downloads, ...) The question is, is this worth the effort, or are the more important tasks to tackle first ? |
“-” 1 to rename knative-sandbox “+” 1 to create a new org like knative-extensions Things that would go into extensions are repositories we'll maintained by working group members and approved by TOC My two cents are the effort is not worth based on active contributors doing infrastructure/productivity tasks, but like any task it can go the back of backlog of productive working group with the slim chance of some hero picking up the job soon. This issue was opened because of kn function plugin, but this repository will be moved to main/core knative GitHub org, then should we close this issue? |
+1 for closing the issue |
/unassign @pmorie |
/assign @davidhadas will reach out to productivity to figure out feasibility of this happening |
We had a few suggestions from people in Productivity which I will allow @upodroid and @cardil to add their own opinions here to be properly captured. My 2cents was that I agree with one of the points @davidhadas mentioned about some projecting in |
The original proposal's justification may still be valid: #23. However, we have never graduated any of the projects from knative-sandbox into the knative org, right? The MATURITY-LEVELS.md describes the process, and we have badges in repos that show their maturity levels. This issue should be addressed. I see a couple of options we have: Re-evaluate maturity levelsThe first option would be to re-evaluate the maturity level of projects in knative-sandbox. It doesn't make much sense to have components being offered to customers as GA, which aren't graduated to knative org. We have things like that, for example: https://github.com/knative-sandbox/eventing-kafka-broker and https://docs.openshift.com/container-platform/4.12/serverless/serverless-release-notes.html#new-features-1.25.0_serverless-release-notes. On the other hand, we got things that can't be considered stable and live happily in knative org, for ex.: Rename knative-sandbox to something elseSuch rename should probably don't indicate the maturity level. So, names like Fold everything into
|
Personally, my feeling is that re-evaluating maturity levels is the lowest hanging fruit and least disruptive to existing repos, and would favor that approach. I don't feel as though the repository name (knative-sandbox/eventing-kafka-broker) means as much as clearly stated maturity levels for all repositories across both orgs. |
I believe what @cardil is saying is that we need to distinguish between Not all projects in the This seems indeed like the lowest hanging fruit which will allow projects to escape being associated with a "Sandbox". I am less sure about moving ALL sandbox projects to Knative as it may include projects that are no longer supported etc. Maybe it is also good to keep Sandbox around for an easier path to new projects and tryouts... But that is also something to consider if it will simplify maintenance. |
I believe that we have graduated The discussion at the time of establishing At the TOC meeting, we discussed that it is desirable to have a |
Summarizing what we discussed at productivity WG meeting and my opinions interleaved in. From an expense perspective the options that I understand so far are thus from least to most expensive:
@upodroid please chime in as well since you couldn't make it to our meeting where we discussed this. |
@kvmware, See github documentation, |
My worry in changing the existing setup is that if we break something for end users we might actually end doing the opposite of what we want, causing folks to think the sandbox/extensions ARE unstable. Something else worth considering in any change to the existing setup is how this might impact the development process. For example, would contributors need to create new forks, update git remotes, etc.? True, it's not significant work for one repo, but if you have lots of sandbox forks (as some folks may 😉 ) then it becomes a bit of toil. |
Krsna suggested that we might be able to use an |
We also need a plan and execution order for any plan that we do decide to execute. Our overall goal should be to reach a point where the ongoing maintenance is less than or equal to our current effort, and not to overload productivity with work that primarily benefits repo owners. |
(To be discussed again next week, with the additional naming prefix option considered.) |
Hi, You can guess what was one of his first questions:
Having Guard or any other Knative tool that community members are encouraged to use in a "sandbox" entice such members to assume that Knative is not ready for production - surely when Knative will be ready for production, all essential parts that they are interested in and planning to use - will no longer be in a sandbox. This is just common sense - is it not? I am sure we are not getting points in the community for this confusing naming when we call extensions a "sandbox". We need to go ahead with any of the solutions discussed. |
As can be seen at #69, renaming this org was already done once. If we were able to rename the org once, we can do it a second time. I would like to bring a resolution of renaming |
Following up - I contacted GitHub about renaming and redirects this is what they said the tl;dr is
|
3.5 years is a long time and our infrastructure has changed dramatically since then. You could run through our whole infra and ensure all will work as expected and have a PR open to repoint the infra to the new name in all the places it needs to be done test-infra, knobots, etc. That would give us (Productivity) a better sense of what is involved, and more importantly, the commitment of those who are eager for the rename. As, per the suggestion above about moving projects that want to and want to put in the work to knative with an extension prefix would still be our advice. As a rename would force all projects to be part of this name change which might not be as animate as others. We would not like to see those folk's workflow interrupted and us (Productivity) put on high alert putting out the fires. Please also pay attention to this line from github: |
I agree. And it should have been done 3 years ago, this would have made it much easier I am sure.
I am up for the task, I hope to find a volunteer from Productivity to answer some Qs I have which will make this much more manageable.
Obviously. That is a good recommendation that active repo owners should follow over time. |
Great! Please join in on the Productivity team meeting and I am sure one of us can help you out. |
Looks like |
I have created PRs for all knative org repositories to replace Knative-extension is unused. |
@csantanapr parked it and a bunch of other ones - so we have |
I am not sure once it is parked if we can rename to it... |
I can delete the org knative-extensions and you can rename it to it if you want |
@csantanapr Please do. Also, if you could A) schedule time with us (@upodroid and I) to rename or B) make us org admins so we can do the rename and if need be revert. We (productivity) have discussed this a bit more and we can give the rename a try and see if the redirects magically work as people think they will and if so then @davidhadas and others can start the process of making this change permanent by pointing things at the new org. Or if the rename and redirects don't work as expected we can always rename it back to sandbox and the infra should handle. This experiment will hopefully please those who have faith in the redirects at the expense of a bit of down time for the reorg rename process. Hopefully that will be copacetic with everyone? |
+1 from me |
+1 It is best if we use what we already started by renaming to |
Historical context: #69
Based off of the Functions WG retro, the
knative-sandbox
name is confusing as it contains stable code. We currently have 3 use cases:Some ideas from the conversation:
Please add your ideas/proposals in this issue
The text was updated successfully, but these errors were encountered: