From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 12 Jan 2004 09:32:50 +0200 From: Michael Shigorin To: devel@altlinux.ru Message-ID: <20040112073250.GX24550@osdn.org.ua> Mail-Followup-To: devel@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZYOWEO2dMm2Af3e3" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [devel] [POLICY] synchro API changes in releases X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 07:32:53 -0000 Archived-At: List-Archive: List-Post: --ZYOWEO2dMm2Af3e3 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Здравствуйте. В процессе написания письма про alsa-utils-1.0.1 и sound-scripts написалось также следующее, и IMCO это повод для отдельной темы. Целью предложения является увеличение преемственности и поддерживаемости дистрибутивов, уменьшение затрат на решение вопросов несовместимости как при выпуске обновлений, так и при эксплуатации. --- (Глядя на общий баланс процесса тестирования/выпуска compact и версий ПО в нем (linux-2.4.22/glibc-2.2/oo-1.0.3/mozilla-1.4), я бы не гнался за alsa-1.0.1 и тем же xmms-1.2.8: без толку, а грабель огрести можно.) Но на будущее вопрос остается: ведь каждый такой форк по API -- это усложнение поддержки (добавление грани несовместимости), поэтому при удачном подходе к релиз-менеджменту и планированию выпусков _должно_ получаться: фиксировать в точке релиза максимально осмысленное количество изменений API в окрестности времени выпуска. Возможно, имеет смысл набросать нечто вроде таймлайна -- без тех time, которые не(точно)известны, но с теми точками несовместимости, которые _уже_ известны. Как-то glibc-2.3, alsa-1.0.x API, builds with linux-2.6 kernel headers by default?, etc. С тем, чтобы иметь возможность сводить переходные точки -- ведь на практике люди, отвечающие за такие системные сдвиги, обычно не одни и те же -- слишком тяжелые задачи. Из прошлых изменений схожего плана -- rpm3/4, kernel22/24, alsa05/09, initscripts/service. Т.е.: таким же API является базовая инфраструктура вроде стартовых скриптов, политики упаковки пакетов perl, а не только сугубо upstream API changes. --- Кто что скажет? --- пример Выпуски ALM2.0/ALJ2.0/Утёс-К достаточно совместимы, чтобы по ним выпускались общие updates. Понятно, что это снижает затраты на выпуск и применение таковых. Выпуски ALM2.2/ALJ2.2 различались по KDE (как минимум), что было нивелировано путем выпуска update к ALM2.2. Вариант, но не лучший. Выпуск ALJ2.1 оказался достаточно промежуточным (и "прилагающимся к журналу"), чтобы смысла организовывать его долгосрочную поддержку не было. [...] Сейчас выйдет Compact 2.3. Вопрос в том, насколько его удастся унифицировать по обновлениям с Junior 2.3, буде таковой действительно собирается; а также и с Master update, необходимость которого очевидна и вроде уже и не обсуждается (если он будет выпущен; до конца декабря '03 уже не случилось). Изучая ftp://updates.altlinux.ru, на сейчас могу только сделать вывод, что какие-либо обязательства по поддержке 2.3(beta) отсутствуют; следовательно, этот якорь не держит. --- вопрос Итак, какая версия libalsa должна быть в следующих выпусках? Меня как майнтейнера этот момент интересует крайне сильно -- от него зависит резервирование времени. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --ZYOWEO2dMm2Af3e3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAAk2ibsPDprYMm3IRAtD8AJ9d8fPVa1mAed0OyFz7Ql7c2bt0uQCgkUfd qb1mT4DCVcwjfTFm8Ha/0ZM= =GP2S -----END PGP SIGNATURE----- --ZYOWEO2dMm2Af3e3--