From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 7 Sep 2020 16:56:00 +0300 From: Michael Shigorin To: devel-distro@lists.altlinux.org Message-ID: <20200907135600.GB5319@imap.altlinux.org> References: <1cd8e7f9-4dc3-1eeb-268f-84c0d36a3204@ya.ru> <20200904204200.GC4418@imap.altlinux.org> <2720537.NgBsaNRSFp@zerg.malta.altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2720537.NgBsaNRSFp@zerg.malta.altlinux.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: [devel-distro] =?koi8-r?b?0MXSxdfPxNksINPQydPLySwgxs/Sy8kgKHdh?= =?koi8-r?b?czogy8/NzcnU2SDEzNEga3dvcmtzdGF0aW9uKQ==?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 13:56:01 -0000 Archived-At: List-Archive: On Mon, Sep 07, 2020 at 11:23:43AM +0300, Sergey V Turchin wrote: > > или -- как в данном разе -- подключать переводчиков и > > обеспечивать переводы вместо потери важной _целевой_ > > функциональности. > Ты в курсе прогресса работ в этом направлении. Потому вдвойне и удивился. :-) Хорошо же делают. А что когда-то отстаёт -- тут или работать с апстримами на этапе подготовки выпусков, или переводить (и тестировать да класть в дистрибутивы) только отобранные выпуски. Это чисто организационный вопрос, а с таким подходом можешь смело выкидывать из списков вообще всё. Проблем в переводах море ещё с тех пор, как до них дорвались убунтушники. > > 2 zerg: в таких случаях в m-p по задумке принято не калечить > > списки общего пользования, > У меня другое мнение: я их исправил. Обоснуй. Это я в т.ч. как майнтейнер и многолетний активный пользователь recoll спрашиваю. > > а или выделять нужную часть, > Мне неудобно городить своё отдельное дерево и отслеживать > изменения в тех местах, которые я копирую. Тогда учись договариваться, а не как с branding-xalt-kworkstation, который теперь в версиях системных компонент вроде xorg-server "красуется": "мне так удобно, а до вас всех мне дела нет" :-/ На сейчас предусмотрены варианты: 1) общих списков/фич, которые должны устраивать _всех_ пользователей данной ветки (и исправляться/улучшаться коллегиально); 2) частных реализаций (например, slinux), которые если применяются другими -- то на свой страх и риск. Конкретно в rescue+x11 изменений за всё время после создания был целый десяток, если что. И выделить rescue+x11+extra, а "себе" забирать булевым выражением $(call tags,rescue && x11 && !extra) вместо $(call tags,rescue x11) -- по-моему, не так уж и сложно, было бы желание. > Вся суть m-p и состоит в разобщении списков. От прошлого > проекта имени boyarsh@ он в основном только этим и > отличается(для мантейнера дистрибутива). Это его главный > недостаток, который следует исправить. Поясни, пожалуйста. А то начнёшь "исправлять" фундаментальное преимущество с точки зрения ~всех остальных майнтейнеров дистрибутивов, проще будет заново написать (кстати, если кто соберётся продумывать следующее поколение систем управления конфигурацией для сборки альтовых дистрибутивов -- пишите, были некоторые задумки и выводы). "Разобщение" -- это по сути тонкие блокировки; если предпочитаешь big kernel lock -- имей в виду, вообще не масштабируется. В пределе: если всю генерацию дистрибутива слить в один большой скрипт, любые два коммита на одно и то же состояние будут кандидатами на конфликт, в лучшем случае подходящими под автоматический merge. PS: смотрел выхлоп REPORT=1 при установленном graphviz? --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info