Pull to refresh
4
0
Михаил Каганский @mikekaganski

Software engineer

Send message

:-) К сожалению, такой документации нет. Ну, если не считать документацией код, README.MD в модулях и наш wiki.

Но можно задавать вопросы, связанные с разработкой, на нашем канале IRC #libreffice-dev

У меня стойкое ощущение, что "разбираясь" с проектом (не вполне понятно, что именно вложено в этот термин), Вы не разобрались, что документация про FCM (ссылку на которую Вы приложили, и по которой сразу можно прочесть "It assumes that you have read the chapter First Steps, and that you are able to connect to the office and load documents") - это документация для разработчика приложений для LibreOffice, и она не имеет ничего общего с описанием того, как LibreOffice устроен внутри - там описана архитектура UNO API.

План перехода на отечественное ПО, работает уже лет 6, и подразумевает не только платный софт а вообще ВСЕ ПО которое используется. И не важно что это опенсорс и его не надо покупать. Потому для госов и муниципалов можете вычеркнуть любой опенсорс если он вне реестра отечественного ПО

Обратите внимание, что реестр включает ПО, которое можно закупать, а не ПО, которое разрешается устанавливать и использовать в госструктурах. Это разные вещи. И СПО не запрещено к такому использованию. Нет лишь нормальных механизмов поддержки такого ПО силами сторонних компаний.

Типа «Роскосмос успешно про… все плоимеры?»
Именно. Даже забавно, что «как-то даже забыл, что при всех своих успехах ...» — то есть «я с таким уважением отношусь к этой компании, что для меня становится неожиданностью мысль о том, что они ещё чего-то не успели достичь» — может вызывать такие негативные эмоции у читающих. Люди забыли, кто такое удивляться?
Конкретно в случае ЛО практика такова:

1. Создаётся багрепорт с описанием проблемы на английском языке («не работает подписание с использованием алгоритма такого-то; шаги для воспроизведения: 1, 2, 3...»).
2. Отправляется патч в геррит, commit message которого в первой строке имеет тег tdf#XXXX, где XXXX — номер багрепорта. Ну, и конечно, commit message будет содержать достаточный объём информации (при необходимости — хоть «войну и мир»).

Это позволяет привязать патч к объяснению «откуда и зачем», расширить обсуждение при необходимости (в баге или в геррите), и сохранить это обсуждение для «последующих поколений», которым понадобится контекст при будущих правках. Никакие нестандартные каналы не могут обеспечить такой преемственности.
Насколько я знаю, предлагать правки в своём блоге или по почте чаще всего бессмысленно (хотя у некоторых проектов есть политика приёма патчей по почте). У проектов обычно есть своя политика приёма правок, и у многих это именно размещение патча в системе peer review. Поэтому как бы ни были хороши намерения, если не следовать установленным в проекте правилам, все полезные предложения могут оказаться потерянными в непредназначенном для этого канале.
И вот если производители отечественных форков Linux доработали различные пакеты


А Вы не хотели бы внести указанные правки в LibreOffice самостоятельно? Достаточно отправить Code Contributor Statement, и разместить патч в геррит.
Ну там много кто делает, и основную работу, как всегда — Caolan.

Information

Rating
5,694-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity