search

knative / community

Knative governance and community material.
https://knative.dev/community
Other
252 stars 233 forks source link

Rename knative-sandbox github org #169

Closed bsnchan closed 1 year ago

bsnchan commented 4 years ago

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

rhuss commented 4 years ago

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 knative-contrib or knative-extensions makes much sense.

However, we can also have multiple organisations reflecting the different purpose as mentioned above:

I could imagine, that knative-sandbox could be the incubation stage for knative-contrib & knative-extensions but I wouldn't enforce that (i.e. it should be possible to create are repo directly in knative-extensions or knative-contrib without going through knative-sandbox).

If 4 orgas are too much of an overhead I could imagine to skip knative-sandbox as experiments can happen elsewhere, too. Also knative-extensions could fold with knative-contrib if this is too much.

So, I can imagine kind of three setup for orgas in addition to knative:

OR:

and experimental projects life somewhere else (e.g. in personal accounts)

OR:

markusthoemmes commented 4 years ago

For the sake of completeness: knative-ecosystem and knative-community have been floating around too. I personally very much like the former as it draws a clear distinction to core while not being too fuzzed about the quality of stuff living in there.

rhuss commented 4 years ago

But isn't the "core" also part of the 'ecosystem' ?

tcnghia commented 4 years ago

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 https://github.com/knative/community/issues/169#issuecomment-652857795 that we should be mindful of even more orgs being created in the future when choosing a new name for knative-sandbox.

Throwing a few into the mix:

csantanapr commented 4 years ago

I gave this feedback on the google doc, but recording here my 2 cents.

I think knative-sandbox is fine any other meaning can be added to the description of the org. This org if it required to change the name then I propose knative-experimental or knative-playground

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 knative-extensions

For now, I would not have more orgs to keep things simple, just for now.

rhuss commented 4 years ago
  • knative-ext

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.

  • knative-eco

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").

  • knative-combine
  • knative-united

that doesn't wring any bell to me.

rhuss commented 4 years ago

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.

tcnghia commented 4 years ago

Friendly ping @pmorie

abrennan89 commented 2 years ago

+1 for knative-extensions

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.

cc @nainaz @lance

lance commented 2 years ago

@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

zroubalik commented 2 years ago

For me there is a slight difference between extensions and sandbox, so I'd prefer if we keep sandbox as it is. I agree that kn-plugin-func is a special case but as Lance pointed out, we are transitioning this repo already.

rhuss commented 2 years ago

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 ?

csantanapr commented 2 years ago

“-” 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?

rhuss commented 2 years ago

+1 for closing the issue

dprotaso commented 1 year ago

/unassign @pmorie

dprotaso commented 1 year ago

/assign @davidhadas

will reach out to productivity to figure out feasibility of this happening

krsna-m commented 1 year ago

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 sandbox being stable and mature and my suggestion is that those should be moved into knative. There are still other projects there that are not at that state and don't have the oversight or enforcement from Productivity (maybe TOC) and are more relaxed on their workflow ownership etc which I think should remain in sandbox. As far as the name sandbox/playground/whatever I have no opinion.

cardil commented 1 year ago

The original proposal's justification may still be valid: https://github.com/knative/community/issues/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 levels

The 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.: test-infra (or toolbox and infra), or pkg, or hack, or actions.

Rename knative-sandbox to something else

Such rename should probably don't indicate the maturity level. So, names like knative-contrib or knative-world are better, IMHO. That's if we like to depart from the concept of incubation of project into the Knative core.

Fold everything into knative

I feel the simplest thing would be to just fold both organizations into just knative. We will just mark all projects with proper maturity levels. Probably also adding some levels, like support level for things like knative/pkg, knative/hack, or knative/infra. Such a move will not affect the knative release, as there are already components on the release train that are from knative-sandbox. Also, the compliance tests or trademark should no longer rely on separation of knative/knative-sandbox, at least that's my understanding.

This solves the problem of bad reception by customers, of things that still live in incubation/sandbox, and being sold as GA at the same time. Furthermore, this allows far better discoverability of knative things, and simplifies maintenance.

The downside might be the lower overall quota on various CI things like Github Actions.

My opinion: fold everything into just Knative.

lance commented 1 year ago

we have never graduated any of the projects from knative-sandbox into the knative org, right? It may be a special case, but functions moved from knative-sandbox/kn-plugin-func to knative/func.

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.

davidhadas commented 1 year ago

I believe what @cardil is saying is that we need to distinguish between Projects in Core and Projects in the Knative organization they do not need to be the same.

Not all projects in the Knative organization need to be considered as Core (and this is also true today as we already have auxiliary projects in Core). We could associate each project in Knative organization with a respective maturity level. We can also associate with each project a tag if it is in Core or not (or otherwise manage association with core).

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.

evankanderson commented 1 year ago

I believe that we have graduated kn-plugin-func from knative-sandbox to knative/func. I think we also did this with the operator repo back in the day.

The discussion at the time of establishing -sandbox was that we needed a place to enable experiments which weren't necessarily endorsed by the Knative community but allowed multi-company collaboration. There's a tension between the endorsement of the Knative community and the bar on creating a collaboration space.

At the TOC meeting, we discussed that it is desirable to have a knative-extensions org, either by rename or creating a third org. We don't know which option is least expensive, and would love some perspective from the productivity team on the costs of the two options.

krsna-m commented 1 year ago

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:

  1. Add a note to knative-sandbox telling people to check out the project's maturity level to discern if they think it is production ready or not.
    • Work involved: Add some documentation
    • CONS: @davidhadas pointed out just because you say something in the documentation that a sandbox project is mature does not mean people will see it as not sandbox and thus not prod ready.
  2. Graduate projects in question as exemplified by @evankanderson kn-plugin-func etc.
    • Work involved: Project owner needs to migrate their project
    • CONS: none that I see. Other than maybe projects that feel they want to not have the sandbox name but others don't feel it is quite ready to roll into knative org.
  3. Fold everything in to knative org with maturity tags as proposed by @cardil
    • Work involved: Project owners needs to migrate their projects (same as option 2 but on a larger scale) at this point I believe productivity would also be forced to get involved to help the transition so would be eating prod team + project owners time.
    • CONS: maturity levels might be ignored (not read) and people complain about knative being beta quality because they were running a low mature project. Bigger scale change.
  4. Create YAO (Yet Another Org) named X
    • Work involved: Productivity would have to add the new ORG into all the automation/infra and get it ready. The project owners would then need to move their projects into this new ORG as in option 2. Large move of many projects can be done, but productivity wouldn't really like to be sucked in. We have spent lots of work to get our infra gitops so people can make the PRs need and we will be happy to review and merge.
    • CONS: This puts a bit of upfront work from productivity to add another ORG. There are the general issues with another orgs, in the sense, github does not make it easy to move things around orgs etc. This also has the same burdens as option 2.
  5. Rename sandbox to X
    • Work involved: This would require productivity to do the same work as option 4, but now with lots of disruptions. This will cause interruptions and is the most disruptive. Even once the rename in github and in the infra is done there is still renaming that would have to be done in code and in prior releases etc. @cardil please chime in as well about the releases etc. that would be an issue.
    • CONS: seems the most disruptive and not advised.

@upodroid please chime in as well since you couldn't make it to our meeting where we discussed this.

davidhadas commented 1 year ago

@kvmware, Note that in order for a project to be transferred from one org to another as suggested by options 2, 3, and 4, we need to have the org admin performing the transfer. So at least this part needs to be done by one of the admins and not by the project team.

See github documentation,

psschwei commented 1 year ago

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 :wink: ) then it becomes a bit of toil.

evankanderson commented 1 year ago

Krsna suggested that we might be able to use an extension- prefix on all the components we're moving over from knative-sandbox and then move everything into the knative- org.

evankanderson commented 1 year ago

We also suggested that we could use the project description managed by Peribolos to record the maturity level as structured text.

evankanderson commented 1 year ago

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.

evankanderson commented 1 year ago

(To be discussed again next week, with the additional naming prefix option considered.)

davidhadas commented 1 year ago

Hi, I introduced Guard today to Brandon Mitchell from Tag-Security.

You can guess what was one of his first questions: 

I see Guard is in Sandbox, when do you expect it to "graduate" in Knative terms?

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. Anything that will move us from keeping the extensions in an organization called "sandbox".

davidhadas commented 1 year ago

As can be seen at https://github.com/knative/community/issues/69, renaming this org was already done once. 6 months after it was done, people started pointing out that the name chosen was creating an issue. We are now 3 years later and still using the apparently not suitable name chosen 3.5 years ago.

If we were able to rename the org once, we can do it a second time. Yes, we can!

I would like to bring a resolution of renaming knative-sandbox to knative-extensions (the same way this community 3.5 years ago renamed knative-community to knative-sandbox)

dprotaso commented 1 year ago

Following up - I contacted GitHub about renaming and redirects this is what they said

the tl;dr is

Hi Dave,

Thanks for contacting GitHub Support! I'm so sorry for the delay in getting back to you - it's taken us longer than we would like to respond!

While it's not possible to park a username, you can get around this and do what you're hoping for. The best way to do this would be to:

Rename your org to knative-extensions Create a new org called knative-sandbox so no one else can claim it When you rename your org, this will create redirects for your repositories from knative-sandbox/repo to knative-extensions/repo. These redirects will last as long as your new org doesn't have any repositories with the same name.

If you want more information to know what gets redirected, I suggest giving this a read from our Docs.

It's also important to know that this won't redirect the main org profile such as github.com/orgs/knative-sandbox over to github.com/orgs/knative-extensions, so for that I suggest creating a profile README (if you don't have one already) and have it mention that you've moved.

We also recommend as a best practice to update your repo URLs everywhere rather than relying on redirects.

I hope this helps! If there's anything else I can do, give me a shout!

Take care,

Tim

krsna-m commented 1 year ago

As can be seen at #69, renaming this org was already done once. 6 months after it was done, people started pointing out that the name chosen was creating an issue. We are now 3 years later and still using the apparently not suitable name chosen 3.5 years ago.

If we were able to rename the org once, we can do it a second time. Yes, we can!

I would like to bring a resolution of renaming knative-sandbox to knative-extensions (the same way this community 3.5 years ago renamed knative-community to knative-sandbox)

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: We also recommend as a best practice to update your repo URLs everywhere rather than relying on redirects.

davidhadas commented 1 year ago

3.5 years is a long time and our infrastructure has changed dramatically since then.

I agree. And it should have been done 3 years ago, this would have made it much easier I am sure. The more we wait, it will not get easier though.

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. ...

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.

Please also pay attention to this line from github: We also recommend as a best practice to update your repo URLs everywhere rather than relying on redirects.

Obviously. That is a good recommendation that active repo owners should follow over time.

krsna-m commented 1 year ago

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.

Great! Please join in on the Productivity team meeting and I am sure one of us can help you out.

dprotaso commented 1 year ago

Looks like knative-extensions is parked by someone - did anyone here do that?

davidhadas commented 1 year ago

I have created PRs for all knative org repositories to replace knative-sandbox with knative-extension.

Knative-extension is unused.

dprotaso commented 1 year ago

@csantanapr parked it and a bunch of other ones - so we have knative-extensions

image (1)

davidhadas commented 1 year ago

I am not sure once it is parked if we can rename to it... Anyhow, we have invested a couple of hours to start the process of renaming to knative-extension which is not parked. So unless there is some issue with knative-extension, lets continue on that path.

csantanapr commented 1 year ago

I can delete the org knative-extensions and you can rename it to it if you want

krsna-m commented 1 year ago

@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?

psschwei commented 1 year ago

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

davidhadas commented 1 year ago

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

It is best if we use what we already started by renaming to knative-extension instead of knative-extensions, unless there is bias towards knative-extensions