From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.2.4 Date: Fri, 1 Aug 2008 11:24:44 +0300 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20080801082444.GA10987@dad.imath.kiev.ua> References: <200807281521.03230.cas@altlinux.ru> <21bd5bb90807280440i7f558953lf849ca0f04a53fc7@mail.gmail.com> <20080728115733.GX6470@hell.fortress> <200807281819.02865.cas@altlinux.ru> <20080728143405.GZ6470@hell.fortress> <20080730104210.GK23830@osdn.org.ua> <4892C14E.7020703@solin.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4892C14E.7020703@solin.spb.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Received-SPF: pass (dad.imath.kiev.ua: domain of vlasenko@dad.imath.kiev.ua designates 127.0.0.1 as permitted sender) receiver=dad.imath.kiev.ua; client-ip=127.0.0.1; helo=dad.imath.kiev.ua; envelope-from=vlasenko@dad.imath.kiev.ua; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; Cc: =?utf-8?B?0JDQvdC00YDQtdC5INCn0LXRgNC10L/QsNC90L7Qsg==?= , Michael Shigorin Subject: Re: [devel] =?utf-8?b?0JrQvtC90YbQtdC/0YbQuNGPINC/0L7Qu9C40YLQuNC6?= =?utf-8?b?0Lgg0YDQsNC30YDQsNCx0L7RgtC60Lgg0LTQuNGB0YLRgNC40LHRg9GC?= =?utf-8?b?0LjQstC+0LIgQUxUIExpbnV4?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 08:24:51 -0000 Archived-At: List-Archive: List-Post: On Fri, Aug 01, 2008 at 11:54:54AM +0400, Aleksey Avdeev wrote: > При возможности ничего не ломающего обновления -- допускать. +1. Обобщая, предлагаю схему Миши Шигорина==debian, но в наших реалиях, как оно по сути и есть, только его нужно расставить по полочкам. И так, дистрибутив X.Y: к нему 3 репозитария: 1) updates/X.Y - это то, что хочет уважаемый Андрей Черепанов . После стабилизации для бранча выпускаются только обновления по безопасности. 2) branch/X.Y - это то, что хочет народ: > Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на то > есть веские причины типа серьёзных исправлений? При возможности ничего не ломающего обновления -- допускать. 3) backports/X.Y - место для потенциально ломающих обюновлений. При этом у меня есть RFC для следующего дополнения к backports полиси: ============== RFC ================== Пакеты в backports в силу своей потенциальной нестабильности должны быть атомарно изолированы. Т.е. при попадании в incoming backports пакет должен сначала собираться в окружении distro+branch, и только если попытка сборки не удалась, то в окружении distro+branch+backports. В спорных ситуациях бакпортер всегда явно может затребовать пакет из backports, явно указав foo >= ver. ===================================== Обоснование: чтобы при обновлении из backports один нестабильный пакет не тянул заведомо для него лишние другие нестабильные пакеты. Осталось только принять такое полиси и явно развести инкоминги для бранчей и updates (backports уже есть), чтобы легко было видно, куда эта сборка позиционируется. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine