From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FUZZY_XPILL, SPF_PASS autolearn=no version=3.2.5 X-Yandex-TimeMark: 1242993097 X-Yandex-Spam: 1 X-Yandex-Front: smtp20 X-BornDate: 976136400 X-Yandex-Karma: 0 X-Yandex-KarmaStatus: 0 X-MsgDayCount: 4 X-Comment: RFC 2476 MSA function at smtp20.yandex.ru logged sender identity as: shader Date: Fri, 22 May 2009 15:51:35 +0400 From: Alexey Novikov To: ALT Linux Sisyphus discussions Message-ID: <20090522115135.GB14805@localhost.localdomain> References: <200905211329.43208.cas@altlinux.ru> <200905211621.11566.dans@altlinux.ru> <20090522051558.GA8379@localhost.localdomain> <200905221354.02294.cas@altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200905221354.02294.cas@altlinux.ru> Subject: Re: [sisyphus] =?koi8-r?b?8NLFxMzP1sXOydEg0M8gxs/SzcnSz9fBzsnAIMLS?= =?koi8-r?b?wc7exco=?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 11:51:52 -0000 Archived-At: List-Archive: List-Post: On Fri, May 22, 2009 at 01:54:02PM +0400, Андрей Черепанов wrote: > 22 мая 2009, Alexey Novikov написал(а): > > On Thu, May 21, 2009 at 04:21:10PM +0300, Denis Pynkin wrote: > > > On 21 May 2009, Alexey Gladkov wrote: > > > > > Новой _платформы_, выпускаемой раз в 9 или 15 месяцев. > > > > > > > > О чём ты говоришь ?! > > > > Кому нужна новая платформа каждые 9 или 15 месяцев? > > > > Посмотри хотябы на RHEL. Он выходит редко, но длительность поддержки > > > > этой платформы очень долгая. И именно это нужно. Нужно чтобы платформа > > > > была и она поддерживалась долго... ну не хотят заказчики каждые 9 или > > > > 15 месяцев портироваться на новую платформу. > > > > > > это касается скорее только серверной платформы. Андрей, судя по всему, > > > ориентируется на десктопную. > > > > > > Не буду оригинальным: почему бы не воспользоваться позитивным примером > > > ubuntu - LTS дистрибутивы + "промежуточные" бранчи ? > > > > > > > > Добавлю и свои 5 копеек. Почему бы не воспользоваться модифицированной > > дебиановской схемой: > > 1. unstable (Sisyphus) - как есть на данный момент. > > 2. testing, в который попадают пакеты из Сизифа после обкатки и > > на котором смогут жить майнтейнеры и тестеры. Требуется > > гарантировать обновляемость до Сизифа. Требуются достаточно свежие > > версии apt+rpm, чтобы можно было запускать hasher с Сизифом. > > 3.1 LTS бранч, скорее серверный, с main+contrib, гарантируется > > обновляемость до testing из которого и могут в него попадать > > обновления. > > 3.2 десктопный бранч, также с main+contrib, также обновляемый до > > testing из которого в него попадают обновления. > > > > Сроки поддержки - ну например 3 года для LTS и год для > > десктопного. Обновляемость 3.X->3.Y не гарантируется, хотя и не > > отрицается сама возможность. > Да, схема нормальная. Теперь только нужно определиться когда у нас будет > готова пакетная база для LTS-бранчей. testing можно делать сразу, но он > протухнет в тот же день и потому дистрибутивы на нём делать не получится. Андрей, идея testing не в том, что он создается из Сизифа в какой-то момент, а в непрерывном его обновлении достаточно стабильными пакетами. Например в нем можно было бы не форсировать переход на новый xorg и т.д., а дождаться например когда основные вендоры обеспечат поддержку своего оборудования (знаю, с ATI случай клинический, поэтому это не про него, но все же). А то счас часто можно встретить ситуацию, когда майнтейнеры пакетов для Сизифа сами сидят на бранчах только потому, что их оборудование отказывается работать на текущем Сизифе. Что касается бранчей для дистрибутивов, то 1. Планируемые сроки должны быть известны заранее. 2. Если невозможно полностью исключить разломы в testing, то они должны быть достаточно краткосрочными. И чем ближе час Х, тем более строго должны проверяться пакеты в него попадающие. 3. Периодическое (раз в неделю/месяц) изготовление инсталлятора на базе testing, может даже 2 и более (десктоп/сервер и т.д.) Это даст возможность своевременного тестирования собственно инсталлятора и сократит срок между бранчеванием и выпуском. -- WBR, Alexey Novikov XMPP: alex-novikov@jabber.ru, shader@ya.ru