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: Tue, 12 Apr 2022 21:54:46 +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: <20220412102001.6o7gh2xcnyb5a27o@altlinux.org> 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 17:54:53 -0000 Archived-At: List-Archive: List-Post: Здравствуйте! 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'ами, где не переписывается история, по крайней мере, между > мажорными версиями. > В каждый новый бранч (то есть в новую мажорную версию нового ядра) > предлагается заново слать свои патчсеты, а затем только обновления > (новые коммиты поверх уже принятого патчсета), А вот тут -- уже нет. Это гарантировано не работает. Поддерживать несколько веток (mainline и пару LTS) * несколько плат * несколько версий прошивок возможно только при явном разделении "здесь моё, а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос получившихся патчей на LTS ветки. К тому же цикл разработки (поддержки SoC/плат) зависит не только (и не столько) с циклом разработки ядра (mainline, LTS, "нашего"). А прежде всего от 1) Появления новых процессоров/плат 2) Появлением новых драйверов/фич (и их переносом из заведомо устаревшего ядра от производителя процессора/платы). 3) Обновлением прошивки (которые как правило ломают совместимость и требуют адаптации ядра). > а не пере-посылать новые версии своих патчсетов как промежуточные > версии при разработке. Это и есть "промежуточные версии при разработке". Которые пока не попали в mainline (а может и никогда не попадут). > хорошо относится к нашим ядрам как к стабильным и как к апстримным для > нас, а не как к экспериментальным для локальной разработки. А чем, собственно, mainline ядро отличается от "экспериментального для локальной разработки"? Вопрос со звёздочкой: то же самое для LTS ядер (у которых по два и более релиза в неделю случается). > Все это упростит поддержку и разработку ядер для всех, так как является > общепринятой практикой. Хорошо у вас там... Но в этой Вселенной "общепринятая практика" - rebase на ветку, которая указана в MAINTAINERS. Нет, мне это не нравится (равно как и stable-api-nonsense.rst), но "другого Linux у меня для вас нет". Всего доброго, Алексей