|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 19 Aug 2002 00:45:48
To : Alex Tomas
Subject : Re: снова о процессе р азработки ядра
--------------------------------------------------------------------------------
>>> Alex Tomas wrote:
VW>> Чего чего - в ветку уходить.
VW>> А потом, через месяц, с матом сливаться. Только не с HEAD а с
VW>> последним symbolic tag-ом багфикс релиза.
AT> так и делается. tagged branch. только вот ежедневные коммиты вовсе
AT> не обязаны быть работоспсобными. мы даже немного иначе делаем. делаем
AT> стабильную ветку из main. типа stable_4. в нее только bugfixes и ее
AT> даем клиентам, а разработку продолжаем в main
Ветка на bugfix, ветки на release engineering разной степени фиксированности
(только critical security fixes, или умеренный набор не меняющих основные
принципы, или большие изменения, но не совсем глобальные) - это понятно.
Тут шла речь немного не о том.
Разработку, которая идет в заранее плохо предсказуемом направлении и может
дать, например, катастрофическое падение производительности - плохо делать
на транке. Если потом придется откатываться - то придется откатывать все версии
прямо на транке - жутко неудобно. Поэтому берется для таких экспериментов
или отдельная ветка, или вообще отдельный репозиторий (как сейчас работают,
например, с FreeBSD5 - SMPng, KSE, TrustedBSD ведутся отдельно (причем
TrustedBSD в Perforce)) и по мере готовности этапов, при четкой уверенности
в успехе, коммитятся на транк. Это дает ряд проблем - например, нужно
оказывается закоммитить изменения на транке в рабочую ветку подпроекта,
убрать конфликты всех уровней и времен, прогнать тесты и только после этого
коммитить обратно в транк, получив уже изменения относительно свежего
состояния транка. Я наблюдал как ругался Элишер про этот процесс когда он
в 5.0-current коммитил KSE milestone 3 - забавное зрелище;))
Кроме freebsd'шников, так - с отдельными ветками для экспериментов - сейчас
работают, AFAIR, gcc'шники. С рабочих веток коммит на ствол и затем форк
релизной ветки.
А еще есть разумные методы временнЫх циклов. Hапример, по двухнедельным циклам.
В начале собираются все коммиты, потом тестят и фиксят. К концу должны снова
получить работающий продукт.
Про extreme programming молчу ;)
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: снова о процессе р азработки ядра