From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 12 Apr 2022 21:30:26 +0300 From: "Vladimir D. Seleznev" 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: Tue, 12 Apr 2022 18:30:24 -0000 Archived-At: List-Archive: List-Post: On Tue, Apr 12, 2022 at 09:54:46PM +0400, Alexey Sheplyakov wrote: > Здравствуйте! > > On Tue, Apr 12, 2022 at 01:20:01PM +0300, Vitaly Chikunov wrote: > > Так как Антон Бояршинов больше не сопровождает ядра (спасибо ему за > > проделанную работу), мы реформируем наш kernel workflow. Теперь патчи[1] > > и пулл реквесты[2] предлагается слать так же как они идут (и > > принимаются) в апстримные ядра - через список рассылки devel-kernel[3]. > > Просьба использовать тот же инструментарий как для отсылки в апстрим - > > format-patch, request-pull, send-email с правильно окормленными From, > > descriptions, tags и т.д. > > > > Дополнительно, просьба указывать в какое ядро предназначен патч (версия и > > бранч). Так же в случае заимствования патчей "из интернета" просьба > > ставить ссылку на источник в тег Link: перед своим Signed-off-by:. > > До этого места предложения вполне разумные... > > > Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со > > временем преобразованы -- каждое ядро будет иметь свой единый бранч с > > merge commit'ами, где не переписывается история, по крайней мере, между > > мажорными версиями. > > В каждый новый бранч (то есть в новую мажорную версию нового ядра) > > предлагается заново слать свои патчсеты, а затем только обновления > > (новые коммиты поверх уже принятого патчсета), Я предлагаю ребейзить уже имеющиеся патчи на новую мажорную версию, и сообщаться авторам если чистый ребейз не удался (и разрешение конфликтов не тривиальное), чтобы они исправили проблемы и прислали новые версии пачтей, а до того выпуск нового мажора приостановить хотя бы на некий разумный тайм-аут. Возможно, стоит ребейзить ещё на RC мажора. > А вот тут -- уже нет. Это гарантировано не работает. Поддерживать > несколько веток (mainline и пару LTS) * несколько плат * несколько > версий прошивок возможно только при явном разделении "здесь моё, > а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос > получившихся патчей на LTS ветки. > > К тому же цикл разработки (поддержки SoC/плат) зависит не только > (и не столько) с циклом разработки ядра (mainline, LTS, "нашего"). > А прежде всего от > 1) Появления новых процессоров/плат > 2) Появлением новых драйверов/фич (и их переносом из заведомо > устаревшего ядра от производителя процессора/платы). > 3) Обновлением прошивки (которые как правило ломают совместимость > и требуют адаптации ядра). > > > а не пере-посылать новые версии своих патчсетов как промежуточные > > версии при разработке. > > Это и есть "промежуточные версии при разработке". Которые пока не попали > в mainline (а может и никогда не попадут). Не понятна ваша мысль. Не все наши патчи попадут в мейнлайн, я согласен с Виталием, что наши ядра для нас являются апстримом. > > хорошо относится к нашим ядрам как к стабильным и как к апстримным для > > нас, а не как к экспериментальным для локальной разработки. > > А чем, собственно, mainline ядро отличается от "экспериментального для > локальной разработки"? Вопрос со звёздочкой: то же самое для LTS ядер > (у которых по два и более релиза в неделю случается). > > > Все это упростит поддержку и разработку ядер для всех, так как является > > общепринятой практикой. > > Хорошо у вас там... Но в этой Вселенной "общепринятая практика" - rebase > на ветку, которая указана в MAINTAINERS. Нет, мне это не нравится (равно > как и stable-api-nonsense.rst), но "другого Linux у меня для вас нет". > > Всего доброго, > Алексей -- WBR, Vladimir D. Seleznev