大家好，
根据在TF SIG构建会议上的讨论，在这里提出这个问题。如果TensorFlow的问题追踪器能有更具体的标签，那么问题就可以根据一些特定的标准进行分类和浏览。对我们非常有帮助的一些标签示例：
- 针对Python层上的依赖问题的具体标签(依赖兼容性问题、底层/上层覆盖等)
- 针对软件层(Python库之外)的运行时/构建时环境问题的特定标签(Python解释器不兼容性、CUDA问题、glibc问题等)
- 针对硬件层的运行时/构建时环境问题的特定标签(GPU问题等)
我们希望消费带有标签的问题——在这方面的共同努力将对我们(Red Hat)为TensorFlow开源社区提供更好的环境非常有帮助。
提前感谢任何回复。
8条答案
按热度按时间hfsqlsce1#
感谢您将此问题添加为我们讨论的内容。您能否请审查现有的labels并给出一些具体的建议？例如，我们使用了一个通用的约定，通过语法：创建标签类别，并在我们的自动化过程中使用类别(如“cla”或“comp”)。
您是否建议我们在特定类别中添加新标签，例如“类型：python”或“类型：cuda”或其他内容？谢谢！
ax6ht2ek2#
@fridex 我不知道你是否对仅针对TF的这一套标签感兴趣，还是也对
strict ecosystem的TF+TF SIGs仓库感兴趣。如果情况是最后一个，我认为在TF+SIGs上使用一个通用的标签子集并同步可能是有用的，例如：
2guxujil3#
我们从Kubernetes生态系统中学习，了解如何为组织或个人仓库声明标签，甚至生成标签的markdown文档。参见$x_{1e0f1}x$
3b6akqbq4#
Kubernetes示例非常清晰，因为它们在仓库中也有"编排yaml"。
通常情况下，编排在TF CI基础设施中并不总是清晰的，所以有时候贡献会有点困难。
我支持任何透明的方法，其中贡献路径是清晰的
lqfhib0f5#
为了保持更新：我们将尝试为此范围一个标签提案，直到下一个SIG构建会议并更新此问题。非常感谢您在此方面的合作和对社区的开放意见。
6ljaweal6#
这个问题已经被自动标记为过时，因为它没有最近的活动。如果没有进一步的活动发生，它将被关闭。谢谢。
qv7cva1a7#
我们已经创建了一套标签，可以帮助我们消费问题：
env:runtime- 在运行时引发的问题env:buildtime- 在构建时引发的问题env:hardware- 由硬件和硬件配置引起的问题env:python-lib- TensorFlow依赖的特定Python包(例如numpy特定的问题)env:native-lib- 与原生依赖项(例如CUDA、cuDNN、glibc等)相关的特定问题env:cudnn,env:cuda- 与CUDA和cuDNN相关的特定问题这些只是提议的，可以根据您的喜好自由重命名(不确定前缀)。您可能已经在使用其中的一些 - 例如
type:build/install标签。如果它们与提议的标签匹配，我们可以重用现有的标签 - 只是为了确保我们可以将期望Map到这些标签。再次感谢您。请告知我们是否有需要澄清的地方或是否需要从我们这边提供额外的信息。
yks3o0rb8#
可能的原因是我们正在开发一个在云端运行的 Python resolver ,它可以根据预设规则解析应用程序依赖关系。解析器是 offered to the community 。有关特定于 TensorFlow 应用程序的解析规则，请参阅 example rules for TensorFlow 。解析器规则数据库(" prescriptions ")是公开的 - 我们希望根据提出的分类问题来增强它。如果 TensorFlow 出现问题，我们可以尝试配置解析器以解析应用程序依赖关系，这样用户就不会遇到已知的问题。following tutorial 介绍了解析器的某些安全方面。我们愿意共同努力。