Какой смысл в том, что NuGet от Microsoft, важный инструмент разработки платформы, не перестанет использовать технологию 35-летней давности, даже если это негативно сказывается на производительности разработчиков?

Почему об этой проблеме знают и откладывают на второй план с 2016 года, даже когда доступны простые решения?

Хорошо ли Microsoft управляет OSS? Во многих случаях кажется, что нет, по крайней мере, с точки зрения процесса. Это не голословное обвинение. Некоторые проекты явно работают хорошо. Однако, как ни странно, у многих проектов есть проблемы, которые никогда бы не возникли при лучшем управлении. Ниже приведен один пример того, что кажется ошибкой OSS, которая оказывает значительное влияние на разработчиков.

Прежде чем судить, давайте будем честными: за последние годы OSS все больше и больше взаимодействовала с Microsoft, что привело к некоторым проницательным стратегическим решениям и значительным инвестициям. Они заслуживают большой похвалы за то, что у них есть такие люди, как ScottGu и многие другие, которые могут видеть, как меняется мир, и эффективно адаптироваться. Многие крупные или старые компании никогда не смогут этого сделать. Кроме того, мы должны понимать разницу между управлением OSS и внутренней работой. В компании выполняется огромное количество программной инженерии мирового класса. Несмотря на это, описанная здесь проблема является реальной и вынужденной ошибкой управления, а также ошибкой отношений с разработчиками.

Какой смысл в том, что Microsoft NuGet, важный инструмент разработки платформ, не перестанет использовать технологию 35-летней давности, даже если это негативно сказывается на производительности разработчиков?

Почему об этой проблеме знают и откладывают на второй план с 2016 года, даже если доступны простые решения?

Может быть, вы думаете, конечно, есть недоразумение. Это не может быть так важно. В проектах есть тысячи ошибок, которые нужно отсортировать, и ни одна компания не может исправить их все. Проблемы должны быть приоритетными. Должно быть рациональное объяснение, не так ли?

Я бы не стал винить тебя за то, что ты так думаешь. На самом деле, я надеюсь, что я что-то упускаю. Любые исправления приветствуются. Но посмотрите, как это выглядит снаружи:

  • Менеджер пакетов NuGet от Microsoft не может обрабатывать пути длиной > 260 символов, как MS-DOS. Путь, включая имя файла, не может превышать это значение, однако это часто требуется в сценариях разработки. Проблема описана на GitHub как issue #3324.
  • NuGet — это важно. Это важно не только как часть цепочки инструментов, но и стратегически. То, как он объединяет и упрощает использование программных компонентов, сделало управление пакетами критически важным для роста любой экосистемы.
  • Другие популярные менеджеры пакетов, работающие в Windows, такие как NPM, не имеют этой ошибки или ограничения. Это технически не сложная задача.
  • Эта ошибка тратит время во многих отношениях. Например, некоторым командам приходится переделывать или реорганизовывать большие иерархии разработки. Помимо снижения производительности, это подверженная ошибкам операция, которая может легко вызвать неожиданные проблемы DevOps в несвязанных областях.
  • По иронии судьбы, основной причиной проблемы на самом деле был дизайн, над которым Пол Аллен (соучредитель Microsoft) помогал работать для имен файлов 8.3, для которого он написал код, связанный примерно 35 лет назад. Microsoft уже давно добавила альтернативные API и методы, которые NuGet мог бы легко использовать для решения проблемы, но решила этого не делать. Даже если решение проблемы связано с проблемами обратной совместимости, все равно нет причин, по которым нельзя было бы использовать переключатель, параметр или альтернативный исполняемый файл.
  • Является ли разработка F-word новым стилем программирования? Эта проблема недавно заставила разработчиков начать использовать слово F в комментариях к ошибкам. Немного легче понять ненормативную лексику, когда вы понимаете, что ошибка существует еще с 2016 года. Какой процент проблем в проектах Microsoft GitHub содержит слово F? Я предполагаю, что это небольшой процент, сигнал, что эта проблема не в хорошей ситуации.
  • Какой смысл в том, что ошибка с нулевыми отзывами об улучшении формулировки сообщения об ошибке (#6630) получает метку Priority:0 (более высокий приоритет), в то время как проблема NuGet (#3324) имеет 39 голосует без метки Priority:0, и действительно ли его приоритет снижен с течением времени?
  • Почему бы не предоставить хотя бы одно подробное обновление статуса? Грубый набросок плана по исправлению или контрольный этап (только оценка), когда ошибка может быть исправлена? Почему бы не сказать несколько слов, объясняющих, почему приоритет не выше? Может быть, есть причина, по которой переформулировка текста сообщений об ошибках имеет более высокий приоритет, кто знает? Коммуникация сама по себе является частью хорошего управления OSS. Отсутствие прозрачности и коммуникации сами по себе могут вызывать разочарование и лишить людей возможности планировать эффективные обходные пути решения проблемы.
  • Сообщество предложило помощь со всем необходимым. Почему бы не написать код, предоставить пулл-реквест, может быть, даже отладка или тестирование? Большинство команд разработчиков чертовски усердно работают, часто почти на пределе своих возможностей, и, возможно, это относится и к участвующим здесь разработчикам. Это заслуживает сочувствия, а не критики. Но как понять, что предложенная помощь не будет принята? Если это слишком перегружено даже для того, чтобы справиться с предложенной помощью, может быть, это можно просто подтвердить словами «спасибо, но нет»?

В любом случае, предлагаю повысить приоритет проблемы №3324 и предоставить небольшую информацию о ее статусе.

Если вы согласны, было бы здорово, если бы вы не возражали помочь привлечь внимание к проблеме:

  • Нажмите на социальную ссылку здесь, чтобы поделиться. Вы поможете повысить осведомленность Microsoft и/или разработчиков, которым небезразлична платформа разработки Microsoft и цепочка инструментов.
  • Проголосуйте за выпуск #3324 на GitHub здесь.
  • Напишите комментарий ниже. Если вы хотите написать свой собственный пост, дайте мне знать, и я проголосую и дам ссылку на вас.