From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Wed, 13 Apr 2022 14:37:36 +0400 From: Alexey Sheplyakov To: ALT Linux Team development discussions Message-ID: References: <20220412102001.6o7gh2xcnyb5a27o@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] [ANNOUNCE] devel-kernel workflow X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 10:37:44 -0000 Archived-At: List-Archive: List-Post: Здравствуйте! On Tue, Apr 12, 2022 at 09:30:26PM +0300, Vladimir D. Seleznev wrote: > > До этого места предложения вполне разумные... > > > > > Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со > > > временем преобразованы -- каждое ядро будет иметь свой единый бранч с > > > merge commit'ами, где не переписывается история, по крайней мере, между > > > мажорными версиями. > > > В каждый новый бранч (то есть в новую мажорную версию нового ядра) > > > предлагается заново слать свои патчсеты, а затем только обновления > > > (новые коммиты поверх уже принятого патчсета), > > Я предлагаю ребейзить уже имеющиеся патчи на новую мажорную версию, и > сообщаться авторам если чистый ребейз не удался (и разрешение конфликтов > не тривиальное), чтобы они исправили проблемы и прислали новые версии > пачтей, а до того выпуск нового мажора приостановить хотя бы на некий > разумный тайм-аут. Возможно, стоит ребейзить ещё на RC мажора. > > > А вот тут -- уже нет. Это гарантировано не работает. Поддерживать > > несколько веток (mainline и пару LTS) * несколько плат * несколько > > версий прошивок возможно только при явном разделении "здесь моё, > > а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос > > получившихся патчей на LTS ветки. > > > > К тому же цикл разработки (поддержки SoC/плат) зависит не только > > (и не столько) с циклом разработки ядра (mainline, LTS, "нашего"). > > А прежде всего от > > 1) Появления новых процессоров/плат > > 2) Появлением новых драйверов/фич (и их переносом из заведомо > > устаревшего ядра от производителя процессора/платы). > > 3) Обновлением прошивки (которые как правило ломают совместимость > > и требуют адаптации ядра). > > > > > а не пере-посылать новые версии своих патчсетов как промежуточные > > > версии при разработке. > > > > Это и есть "промежуточные версии при разработке". Которые пока не попали > > в mainline (а может и никогда не попадут). > Не понятна ваша мысль. Их, мыслей, несколько. 1. mainline ядро само по себе - "промежуточная версия при разработке". 2. Поддержка нового процессора, новой платы, новой версии прошивки - это неизбежно "промежуточная версия при разработке". > Не все наши патчи попадут в мейнлайн, 3. Жизненный цикл устройств (процессоров/плат/периферии) никак не связан и не совпадает с циклом разработки ядер (mainline, lts). К моменту, когда наконец upstream согласится (или нет?) принять патчи, изделие уже снимут с производства (см. поддержка Mali T628 в ядре и Mesa). > я согласен с Виталием, что наши ядра для нас являются апстримом. А тут уже я не понимаю. Что значит "наши ядра для нас являются апстримом". Кто и что разрабатывает на основе наших ядер, и как им мешает rebase патчей для поддержки $YET_ANOTHER_ARM_SOC, $YET_ANOTHER_ARM_BOARD ?