Re: [devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov <sin@altlinux.org>]

пн, 6 дек. 2021 г. в 22:28, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Mon, 6 Dec 2021 03:22:24 +0400 Evgeny Sinelnikov wrote:
> > сб, 4 дек. 2021 г. в 03:45, Andrey Savchenko <bircoph@altlinux.org>:
> > > On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> > > >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > > > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> > >
> > > Вот эта головная боль тоже нежелательна. Потому что при отладке
> > > где-нибудь на другой железке или в инсталляторе пакет приходится
> > > часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> > > specsubst и разных kflavour.
> >
> > А разработка, в ином случае, вообще невозможна. Как взаимодействовать
> > с апстримом? Как взаимодействовать с теми, кто берёт апстримные
> > исходники? Ответ: "Пока никак". Вести две параллельных истории. Не
> > хотелось бы.
>
> Так держите своей веткой (или ветками) нужные патчи и применяйте их
> как к апстримному ядру, так и к нашим. Если патчи не зависят от
> остальных альтовых изменений, то накладывать будут на оба варианта
> без проблем, а если зависят, то придётся держать две версии — здесь
> как ни крути, но по другому не получится.

Задача стоит так:
- есть разработчик железа, который хочет получить ядро наиболее
близкое к нашему, чтобы вести в дальнейшем разработку;
- ему не нужны в исходниках релизные коммиты и мешают дополнительные
merge-коммиты;
- ему нужно чётко понимать чем наше ядро отличается от апстримного;
- ему требуется проверить сборку сначала у себя, со своим конфигом;
- ему нужно минимизировать свои коллизии и регрессии;
- ему нужно иметь возможность взять завтра обновлённый вариант наших
исходников для дальнейшей разработки.

> > > > В целом, этот подход ничего не ломает, но очень много позволяет:
> > > > - чётко отслеживать пачти;
> > > > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > > > одного большого "дифа", доступного только git в консоли, но и на
> > > > уровне полного списка патчей, доступного также через web-интерфейс в
> > > > соответствующей ветке;
> > >
> > > А вы точно работали с нашим ядром? Я регулярно переношу все наши
> > > патчи на e2k ядро (кроме патчей для других архитектур). Для этого
> > > используются ветка нужной версии из
> > > git.alt:/people/kernelbot/packages/kernel-image.git
> >
> > Конечно, работали. Давайте посмотрим на ветку ядра, которую удалось получить:
> > https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
> >
> > Где иначе и как ещё можно найти и увидеть полный список наших патчей
> > по-отдельности по сравнению с апстримом?
>
> Ну например вот так:
> $ git log --oneline --no-merges \
> v5.4.163..kernel-image-std-def-5.4.163-alt1 -- \
> . ':!/kernel-image.spec'
>
> Правки конфига тут тоже будут (и обычно это важно), если не нужны,
> то можно добавить ':!/config*'.
>
> Как показывает опыт, требование держать всю историю коммитов в git
> линейно в одной ветке обычно следует из недостаточности навыков
> работы с git.
>
> > > В общем-то, там все наши патчи легко видно по --first-parent;
> >
> > Давайте посмотрим как. Вот есть коллеги из компании разработчика
> > железа. Они хотя собрать ядро, как у нас, но они планируют апстримить
> > свои патчи. Куда из прикладывать с нашим ядром? В ветку, где куча
> > наших релизных коммитов? Зачем им это?
>
> Либо их патч не зависит от наших изменений и тогда без разницы куда
> прикладывать, либо зависит, и тогда им нужно будет два разных
> варианта держать: для ванильного ядра и для нашего. Метод ведения
> дерева git на это никак не влияет.
>
> Best regards,
> Andrew Savchenko
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)