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

[Anton V. Boyarshinov]

В Tue, 7 Dec 2021 02:58:42 +0400
Evgeny Sinelnikov <sin на altlinux.org> пишет:

> пн, 6 дек. 2021 г. в 19:53, Dmitry V. Levin <ldv на altlinux.org>:
> >
> > On Mon, Dec 06, 2021 at 06:26:08PM +0300, Anton V. Boyarshinov wrote:  
> > > В Mon, 6 Dec 2021 18:02:15 +0300, Dmitry V. Levin пишет:
> > >  
> > > > > > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > > > > > одновременно без специальных усилий.  
> > > > >
> > > > > На мой взгляд, эти специальные услилия должны состоять в то, что должен
> > > > > быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> > > > > должны вливаться эти изменения.  
> > > >
> > > > Да, конечно.  А разве это сейчас не так?  
> > >
> > > На мой взгляд, это именно так  
> >
> > Тогда в чём, собственно, проблема?  
> 
> Проблема в том, как минимум, что это не документировано и неочевидно.

Я пока так и не понял зачем разработчикам железа все наши feat- и fix-
если им надо взаимодействовать с одной единственной веткой --
железно-специфичной.

> 
> Если у нас есть upstream каждой alt-специфичной части ядра, то как его найти?
> Может быть тогда сделать соответствующие gear-rules с этими merge-commit'ами?
Кому надо? Зачем надо?


> Как отслеживать какие fix'ы и features, которые приложены?

git log --merges --grep=fix- --grep=feat- --author=altlinux

> 
> На деле же проблема в том, что у нас общий апстрим ядра для множества
> разработчиков. Нужно подумать как нам вести разработку так, чтобы:

Проблема в том, что дистрибутивное ядро рассматривается как upstream. А
это не так.

> - это работа была взаимно удобна;
> - позволяла в таком режиме вести разработку, чтобы схема сборки была прозрачна;
> - позволяла при накатывании патчей сторонними разработчиками (в том
> числе и нам самим в какой-то момент времени) не сталкиваться с
> неопределенностью о том, поверх какого когда наиболее близкого к
> нашему ядру стоит вести разработку;
> - не отворачивала от нас разработчиков за счёт степени компетенции в
> git, которую мы сами от себя почему-то не требуем для сборки
> собственных ядер, и делаем как нам удобно.
> 
> 
> 
> 
> --
> Sin (Sinelnikov Evgeny)
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel