Comments 47
Любопытно, упомянутый сайт soft.lissi.ru принципиально не использует HTTPS? Чтобы, например, проще было подменить ответ сервера при скачивании софта и прочего?
И вот если производители отечественных форков Linux доработали различные пакеты
А Вы не хотели бы внести указанные правки в LibreOffice самостоятельно? Достаточно отправить Code Contributor Statement, и разместить патч в геррит.
А разве я несамостоятельно разбираюсь в коде LibreOffice или GnuPG и предлагаю правки?
А чтоже делают наши производители "отечественных форков Linux" кроме капипаста? Сколько раз я им предлагал просто исправить ошибки (причем самые простые ), а в ответ ...
А за наводку Спасибо.
Насколько я знаю, предлагать правки в своём блоге или по почте чаще всего бессмысленно (хотя у некоторых проектов есть политика приёма патчей по почте). У проектов обычно есть своя политика приёма правок, и у многих это именно размещение патча в системе peer review. Поэтому как бы ни были хороши намерения, если не следовать установленным в проекте правилам, все полезные предложения могут оказаться потерянными в непредназначенном для этого канале.
Конечно вы правы. Но прояснить откуда и зачем появляются эти правки все же надо.
Да, а сами патчи отправить по назначению.
Конкретно в случае ЛО практика такова:
1. Создаётся багрепорт с описанием проблемы на английском языке («не работает подписание с использованием алгоритма такого-то; шаги для воспроизведения: 1, 2, 3...»).
2. Отправляется патч в геррит, commit message которого в первой строке имеет тег tdf#XXXX, где XXXX — номер багрепорта. Ну, и конечно, commit message будет содержать достаточный объём информации (при необходимости — хоть «войну и мир»).
Это позволяет привязать патч к объяснению «откуда и зачем», расширить обсуждение при необходимости (в баге или в геррите), и сохранить это обсуждение для «последующих поколений», которым понадобится контекст при будущих правках. Никакие нестандартные каналы не могут обеспечить такой преемственности.
1. Создаётся багрепорт с описанием проблемы на английском языке («не работает подписание с использованием алгоритма такого-то; шаги для воспроизведения: 1, 2, 3...»).
2. Отправляется патч в геррит, commit message которого в первой строке имеет тег tdf#XXXX, где XXXX — номер багрепорта. Ну, и конечно, commit message будет содержать достаточный объём информации (при необходимости — хоть «войну и мир»).
Это позволяет привязать патч к объяснению «откуда и зачем», расширить обсуждение при необходимости (в баге или в геррите), и сохранить это обсуждение для «последующих поколений», которым понадобится контекст при будущих правках. Никакие нестандартные каналы не могут обеспечить такой преемственности.
Не примут. В хедерах, которыми пользуется весь остальной мир, нету деклараций ГОСТовых констант, которые использует автор.
Последние скриншоты показывают проблемы со шрифтами. Во-первых, зачем шрифт с серифами (засечками) в интерфейсе? Серифы обычно используются на текстах для чтения, а не в навигации.
Второе: почему такое количество шрифтов? Разве один шрифт в разных начертаниях не был бы лучше?
… Всё даже страшнее, чем я думал. Одни и те же элементы управления могут показывать как штрифты с засечками, так и без. (кнопки «Отмена» и «завершаем», например).
Второе: почему такое количество шрифтов? Разве один шрифт в разных начертаниях не был бы лучше?
… Всё даже страшнее, чем я думал. Одни и те же элементы управления могут показывать как штрифты с засечками, так и без. (кнопки «Отмена» и «завершаем», например).
Интересно, что вы делаете switch по keyType и ваши правки не содержат деклараций gost3410Key сотоварищи. Значит эти декларации доступны в существующих хедерах? А для чего они там, если libnss из коробки не поддерживает ГОСТ? Вопрос из праздного любопытства.
А как собирались дистрибутивы утилиты guinss?
> /usr/lical
Чем-то напомнило:
Чем-то напомнило:
ains mein(inт argc char** argv)
{
kaut << "hilo word";
eksit(0;
]
Sign up to leave a comment.
Электронная подпись ГОСТ Р 34.10 документов формата PDF в офисном пакете LibreOffice