Re: [RFR] wml://News/weekly/2011/06/index.wml

[Vladimir Zhbanov <vzhbanov@gmail.com>]

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)" ?
>  
Может быть "политика нулевой задержки на пересмотр при загрузке патчей
не от сопровождающих пакета"?
Или "политика загрузки патчей не от сопровождающих без пересмотра
(или экспертной оценки)".

...
> > "в 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
наряду с С.

...
> > > -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".

...
> > >  </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"
Второй вариант ближе к первоисточнику. Думается "независящие" тут должно
быть вместе.

...
> > > +независимо друг от друга два человека обратились ко мне с вопросом, почему бы
> > > +вместо круговой замены главных страниц не показать одну и ту же
> > вместо замены главных страниц (выкинуть "круговой")
> 
> "круговая замена" должна была конкретизировать способ замены, т.е.
> каждый с кем-то меняется (перетасовка).
Тогда может "вместо взаимной замены"?

...
> > > +	Поздравления, и так держать!
> > Тут или "наши поздравления", или просто "поздравляем"
> 
> Если бы просто поздравляем то было бы "Congratulations!".
> А тут "Congratulations, and keep up the good work!".
> Но если русский аналог не очень подобран, то выкину его.
Имелось в виду:
	Поздравляем, и так держать!
	Наши поздравления, и так держать!
Просто "Поздравления", по-моему, не говорят. Обычно указывают чьи.

-- 
VZh