On Wed, May 11, 2011 at 01:16:11AM +0400, Vladimir Zhbanov wrote: > On Sat, May 07, 2011 at 08:51:15PM +0300, Alexander Reshetov wrote: > ... > > > "переходы" -- слишком общо, и не понятно о чём речь. Я бы сказал "замена > > > (замещение)", можно добавить "пакетов" (см. ниже). > > > И тут всё же, думается, "политика" (загрузки критических патчей не от > > > разработчика), а не "принцип". > > > > Да, "замещение пакетов" будет более понятно. > > 0-day NMU policy вообще лучше перевести. Но у меня, к сожалению, нет идей > > как > > это может выглядеть. > > NMU -- Non Maintainer Upload > > > > http://lists.debian.org/debian-project/2006/07/msg00231.html > Цитирую: > ========== > * Joerg Jaspert [Fri, 28 Jul 2006 22:23:34 +0200]: > > Привет. Я отвечаю здесь, так как кажется, что здесь появилась идея > 0-day, позже повторяемая везде по треду. > > > Просто измените NMU, чтоб они всегда были 0-day, для всех багов >=normal. > > Что означает > > - загрузка (upload) и в то же время письмо в BTS. > > Политика NMU определяется тремя переменными: (days_until_uploadable, > days_for_review, min_severity) [задержка перед загрузкой, время на > пересмотр, минимальная важность]. Таким образом, текущая политика для > багов RC (release candidate) -- (7, 0, serious), а та, что вы > предлагаете для этой "проблемы права собственности на пакет" -- > (X != 0, 0, normal). > > Лично я думаю, что если бы мы хотели, чтобы эксперимент был успешным, > нельзя начинать с такой слабой политики. Для не-RC багов, думаю, установка > (21, 7, normal)+(14, 7, important) будет весьма разумной. > > Уменьшение days_for_review > ------------------------ > > Я на самом деле думаю (как указал Simon), что требование для NMU diff > находиться несколько дней в BTS, прежде чем он будет перенесён в архив, > поможет обеспечить качество (QA -- Quality Assurance), так как здесь > есть пространство для экспертной оценки (сопровождающим, подписчиками > PTS [Package Tracking System] или другими лицами, интересующимися > конкретным багом и подписавшимися на него). > > По этой причине я не думаю, что вообще нужно уменьшать > "days_for_review", если только не ясно, что это на самом деле окупится. > А для не-RC багов я думаю, что неделя будет вполне нормально. > > Мысли о нашей современной политике NMU для RC > ------------------------------------- > > Когда вы делаете загрузку с задержкой, всегда есть возможность, что > сопровождающий произведёт загрузку сам, заставив вас чувствовать, что > ваши усилия если не полностью бесполезны, то некоторым образом > отвергнуты. Так, при days_for_review != 0 вы в конце концов загрузите с > помощью NMU только те баги, о которых вы на самом деле заботитесь, > которые вы так сильно хотите исправить, что неважно, откуда в конечном > счёте придёт исправление. IMHO, это хорошо, так как это значит, что они > будут подготовлены более тщательно. > > Но с другой стороны, многие баги для RC не настолько важны для нас > лично, сколько в том смысле, что они могут задержать релиз. Хотя, если > исправление одного из них потребует больших усилий, в большинстве > случаев этого не будет достаточно. > > Не знаю, было ли это исходной целью или нет, но если вы спросите меня, > это точно то, чем нас подкупает наличие days_for_review = 0 для багов > RC, то есть не столько получение более ранних исправлений в unstable и > таким образом и в testing, но стимулирующее действие, так как > загружающий получает немедленное вознаграждение, что приводит к большему > количеству загрузок. > > Надеюсь, когда выйдет Etch, мы посмотрим назад и подтвердим, что отказ > от таких усилий по экспертной оценке стоил того и что наличие такого > инструмента под названием 0-day NMUs на самом деле помогло процессу > выпуска релиза. > > Но важно никогда не забывать, что 0-day NMUs -- это что-то похожее на > управление машиной скорой помощи: у вас есть право ехать быстро, если > ситуация критическая и кого-то срочно надо доставить в больницу как > можно скорее, и живым. Если вы везёте не сильно раненого, или если вы > водитель-новичок, или идёт сумасшедший дождь, вы всё же имеете право > ехать быстро, но это может быть не самое лучшее, что можно предпринять > (что также известно как "никто не защитит вас от загрузки NMU в > DELAYED.) :) > ========== > > > В этом сообщении про эту политику рассказывается. > > Как я понял days_for_review должно теперь быть равно 0 для ошибок > > с приоритетом, не ниже min_severity. А вот чему это min_severity будет равно > > не ясно. Видимо хотят сделать days_for_review=0 для всех типов ошибок. > Имеется в виду релиз-кандидат (RC) > Выше сказано: "текущая политика для багов RC -- (7, 0, serious)". И, > мол, есть предложение по изменению (ещё для Etch). Но думаю в данном > контексте min_severity не играет роли. > > > Что относительно пакета подразумевается под review я не знаю. Видимо > peer code review -- экспертная оценка кода (из словаря). См. выше. > > > просмотр на правильность предлагаемого разработчиком патча. Тогда 0-day NMU > > будет означать, что исправление ошибок патчами, сделанные несопровождающими > > пакета должны быть сразу же применены. > > > > Может "политика нулевого дня для загрузки пакетов несопровождающими > > (0-day NMU policy)" ? > > > Может быть "политика нулевой задержки на пересмотр при загрузке патчей > не от сопровождающих пакета"? > Или "политика загрузки патчей не от сопровождающих без пересмотра > (или экспертной оценки)".
Спасибо, хорошие варианты. Как и перевод. Может есть желание непосредственно переводить DPN? ;-) "Полититика нулевой задержки на ревизию патчей (0-day NMU policy) от разработчиков, не являющихся сопровождающими пакета." Или даже лучше так: "Политика нулевой задержки на ревизию (0-day NMU policy) при загрузке пакета разработчиком, не являющимся его сопровождающим (Non Maintainer Upload)." Оставляю второй вариант. Если есть замечания -- пишите, изменю. > ... > > > "в kFreeBSD" > > > > Несмотря на то, что были достигнуты определённые успехи в избавлении от HAL > > (который всё ещё используется в xserver-xorg для kFreeBSD), Cyril > > Brulebois... > > > > Т.е. в <пакете> для <ядра/переноса>. > Да, не заметил xserver-xorg. > > > > > > # Other Release Goals > > > > <p> > > > > -Among other <a > > > > +На ряду с прочими <a > > > "Наряду" > > > > > > > href="http://lists.debian.org/debian-devel/2011/03/msg01136.html";>\ > > > > -release goal proposals</a> (such as read-only root file system and > > > > -C.UTF-8 provided by default), Roger Leigh started a <a > > > > +предложениями целей релиза</a> (таких как предоставление корневой > > > > файловой системы > > > "такими как" > > > и может быть "использование корневой файловой системы с правами только > > > на чтение и с локалью по умолчанию, установленной в C.UTF-8..."? > > > > > > > +только для чтения и C.UTF-8 по умолчанию), Roger Leigh начал <a > > > > href="http://lists.debian.org/debian-devel/2011/03/msg01118.html";>\ > > > > -discussion about supporting <code>/run</code> for > > > > <q>Wheezy</q></a>.</p> > > > > +обсуждение о поддержке <code>/run</code> в <q>Wheezy</q></a>.</p> > > > "инициировал обсуждение" (дискуссию) > > > и здесь я бы сказал "о поддержке каталога /run". > > > > "Среди других предложений для целей релиза (таких как использование корневой > > файловой системы с правами только на чтение и предоставление локали > > C.UTF-8)." > > > > Другими словами, предлагаю убрать "по умолчанию". > > И речь не про установить локаль по умолчанию в C.UTF-8, а про предоставление > > этой локали вообще (баг #609306): > > "I proposed that an additional > > C.UTF-8 locale shall be available on all Debian systems, to > > complement the default 7/8-bit C locale." > Тогда можно так и сказать: предоставление (по умолчанию) локали C.UTF-8 > наряду с С. Спасибо, так лучше. "Среди других предложений для целей релиза (таких как использование корневой файловой системы с правами только на чтение и предоставление по-умолчанию локали C.UTF-8 наряду с С)" > ... > > > > -an upgrade of the main archive machine (as well as backports and > > > > -security machines) to <q>Squeeze</q> was performed; > > > > +было проведено обновление главной машины архива (также как и машин > > > > backports и > > > > +security) до <q>Squeeze</q>; > > > версия дистрибутива главной машины архива (...) обновлена до Squeeze > > > или: программное обеспечение главной машины архива (...) обновлено до > > > Squeeze > > > > Ну, обычно говорят просто "обновил до <release name>". :/ > По мне, так это выражение режет слух (обновил машину до ...). Я чаще > слышу "обновил Debian до Squeeze". Просто когда их много добавляется и машина :) Точнее "обновил Debian до Squeeze" превращается в "обновил $hostname до Squeeze (i.e. $release)" Давайте тогда первый ваш вариант так: "было проведено обновление дистрибутива главной машины архива (..) до Squeeze" > ... > > > > </li> > > > > -<li>binary-all <code>dists</code> files were added</li> > > > > +<li>добавлены все доичные файлы <code>dists</code></li> > > > доичные -> двоичные > > > Но здесь "binary-all" переводиться не должно -- это каталог > > > (дистрибутив) с пакетами, общими для всех архитектур, как я понимаю, > > > есть ещё, например, binary-i386. Да и "dists" -- это каталог > > > дистрибутивов, в котором как раз "binary-all" и лежит. Файлов с таким > > > названием не знаю. > > > Таким образом: "добавлены файлы в binary-all в каталоге dists"?? > > > > Или: "добавлены не зависящие от архитектуры дистрибутивные файлы" > > "добавлены не зависящие от архитектуры файлы каталога dists" > Второй вариант ближе к первоисточнику. Думается "независящие" тут должно > быть вместе. Хм, тогда лучше независимые. В описании пакетов, кстати, так переведено (по крайней мере в одном). http://packages.debian.org/ru/sid/m68k/tellico-data "добавлены независимые от архитектуры файлы каталога dists" > ... > > > > +независимо друг от друга два человека обратились ко мне с вопросом, > > > > почему бы > > > > +вместо круговой замены главных страниц не показать одну и ту же > > > вместо замены главных страниц (выкинуть "круговой") > > > > "круговая замена" должна была конкретизировать способ замены, т.е. > > каждый с кем-то меняется (перетасовка). > Тогда может "вместо взаимной замены"? Да, вариант подходящий. "вместо взаимной замены главных страниц не показать одну и ту же..." > ... > > > > + Поздравления, и так держать! > > > Тут или "наши поздравления", или просто "поздравляем" > > > > Если бы просто поздравляем то было бы "Congratulations!". > > А тут "Congratulations, and keep up the good work!". > > Но если русский аналог не очень подобран, то выкину его. > Имелось в виду: > Поздравляем, и так держать! > Наши поздравления, и так держать! > Просто "Поздравления", по-моему, не говорят. Обычно указывают чьи. Извиняюсь, не так вас понял. Спасибо. "Поздравляем, и так держать!" Завтра повношу все правки и отправлю в репозиторий.
signature.asc
Description: Digital signature
