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

[Anton V. Boyarshinov]

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

Ответ содержится в письме, на которое ты отвечаешь (см ниже). Я не вижу
зачем этим разработчикам железа нужны все наши патчи, не связанные с
этим железом. И я не вижу зачем в дистрибутивном ядре патчи, имеющие
экспериментальный характер (а разработчику железа они могут быть нужны).

> > Либо их патч не зависит от наших изменений и тогда без разницы куда
> > прикладывать, либо зависит, и тогда им нужно будет два разных
> > варианта держать: для ванильного ядра и для нашего. Метод ведения
> > дерева git на это никак не влияет.