mirror of
https://github.com/veggiemonk/awesome-docker.git
synced 2026-03-09 15:32:11 -05:00
Travis build error in PR #433 #28
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/awesome-docker#28
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Sep 3, 2017).
As commented in the PR, we should decide
After the decision is made, I'll take the necessary step opening a new PR to fix this build error.
@gesellix commented on GitHub (Sep 3, 2017):
Having had a quick look into the README the project seems to be a nice idea.
There's already a new Docker Registry api v2 available, so I'm not sure whether current Docker clients would be compatible with Docket. I would suggest to remove it from the list. If we decide to keep it I would propose to have it under 'Registry'.
@ghost commented on GitHub (Sep 4, 2017):
Yes, it's a cool project unless it's kept updated. As I commented in the PR 433, the author didn't manage to do this leaving open issues/PRs.
Alternatively, we can list the project under the respective category and label it with the 💀 symbol. In our list we have quite a few project listed which are obsolete but still in use.
@veggiemonk @agebhar1 @Moshe-Immerman
What do you think?
@moshloop commented on GitHub (Sep 4, 2017):
I think 💀 is ok for awesome and stable projects, but once issues start appearing and go unresolved then It might be time to remove it from the list - But I don't see any reported issues and with 500+ stars I would assume if it wasn't working someone would pipe up. It uses fsouza/go-dockerclient in the background, which is regularly updated.
Seeing as it isn't meant to replace a registry but rather facilitate a faster deployment, I vote for leaving it in deployment and infrastructure.
@veggiemonk commented on GitHub (Sep 4, 2017):
I would be in favor of using 💀 for project that are awesome, just outdated. Leaving them into the section they are suppose to be in is better I think because nobody is going to check the "💀 section".
Removing a link is really for project that are completly irrelevant to Docker/containers or that are just not quality enough such as poor documentation/example, no real use case, and so on....
@gesellix commented on GitHub (Sep 4, 2017):
@Moshe-Immerman wrote:
Since the project calls itself a registry, I would still propose to list it under "Registries". Yet, we might consider to list all registries in the section "Deployment and Infrastructure". Registries don't exist for themselves, but usually serve as part of deployments, archive, infrastructure.
I would also be fine with keeping it listed as 💀.
@agebhar1 commented on GitHub (Sep 4, 2017):
Me too for using 💀. But I'm not sure which section fits better. On the one hand it's called »Registry« but from the
it might be also a good idea to list it under »Deployment and Infrastructure«. This is a nice example for the labels I mentioned some time ago which act as a filter. Unfortunately with raw markdown rendering it's not possible I think.
@ghost commented on GitHub (Sep 4, 2017):
Thanks for your feedbacks.
I think the project should be keep listed, because the main idea is as @veggiemonk stated to showcase awesome projects. If one project is obsolete, maybe another person can use it and develop it further. This is the power of the community here.
@gesellix commented on GitHub (Sep 4, 2017):
Thinking out loud: the issue that forces us to decide for one category is the failing check for duplicates. What about keeping the project on both categories, but only put the actual link in e.g. "Deployment & Infra", but replace the "Registry" link to be a cross link pointing to the entry at "Deployment & Infra"? We would need to find a convenient way of adding anchors for such cross links. I'm not sure if such a concept reduces maintainability. 🤔
@veggiemonk commented on GitHub (Sep 5, 2017):
As a default I would list it under Registries. I have a doubt anybody in a company is going to do peer to peer communication.... But I could be wrong.