From: Andrii Dobrovol`s`kii <dobr@iop.kiev.ua> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] майнтейнеры бывают разные *и это нормально* Date: Tue, 13 Jan 2009 14:49:12 +0200 Message-ID: <496C8DC8.2090204@iop.kiev.ua> (raw) In-Reply-To: <777d80610901121245i63355147s95da143045d7586c@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 4880 bytes --] Aleksey Novodvorsky пишет: > 12 января 2009 г. 18:46 пользователь Andrii Dobrovol`s`kii > <dobr@iop.kiev.ua> написал: >> Aleksey Novodvorsky пишет: >> Рискну встрять с таким большим опозданием (праздники...), т.к. не >> увидел дальше аналогичных комментариев, а считаю их существенными. >>> Я полагаю, что для любого менйтейнера необходимо по крайней мере: >>> 1. Уметь собрать пакет в соответствии с нашими policy, для чего часто >>> необходимы патчи. >> Часто, но не всегда (это уже отметили другие). Но, главное, хорошо >> чтоб эти патчи делал сам смотритель пакета, однако, не обязательно. >> Он может попросить о помощи окружающих и постепенно научится, если >> это будет достаточно часто необходимо. > > Он может попросить, но не всегда сможет найти желающих ему помочь. И > не потому, что люди вокруг злые, а потому, например, что им не нужен > и/или не нравится этот пакет. > Конечно. И вполне возможно, что этот пакет вообще больше никому не нужен. Ну так он и не появится... пока человек не научится. :) >>> 2. Уметь настраивать приложения своего пакета и положить настройки в пакет. >> Тоже нужно не всегда и может быть частично сделано кем-то ещё или с >> чьей-то помощью. Если это реально нужно. > > См. выше.. Снова согласен. Но, ведь настройку может выполнить тот кто им пользуется уже после установки. Автоматизация это хорошо но не необходимо. Ведь так? > >>> 3. Уметь исправить и дополнить перевод, отправить его в апстрим. >> И тут тоже можно обратиться к другим членам сообщества. Это и будет >> командная работа, ИМХО. > > Да. > >> И вполне возможно, что из таких мини-команд вырастет много хороших >> смотрителей-универсалов. А если и нет, не беда. Пакеты-то будут... > > Могут и не быть или быть неработающими. И уж почти наверняка -- > неподдерживаемыми. В результате будет видимость наличия пакета. Нужно > ли это? > Если человек собирает его для себя как он будет не работающим? Может первые пару попыток и будут проблемными, но потом работать оно будет. Так как нужно заинтересованным лицам. А механизм удаления неподдерживаемых пакетов уже вроде выработали. Станет таким -- будет удален. >>> То есть это уже не совсем админская работа, так как пакет делается не >>> только для себя. >> В описанном объеме это и правда уже не админская работа. Это >> требования к упаковщику универсалу способному работать без коллег и >> тяготеющему к собственно разработке. Иметь таких людей в команде >> очень хорошо. Надеяться, что все будут такими не стоит. Или команда >> окажется очень небольшой... > > Новый процесс приема в тим включает период обучения. Но вот для > того, чтобы войти в команду, нужна самостоятельность. > Да. Уже прочел. Это отлично. Вообще чтоб что-либо сделать нужно уметь работать самостоятельно. С этим никто не спорит. Я просто хочу напомнить, что требовать одинаковый уровень компетентности от смотрителя ядра и какого нибудь пакетика с игрой для секретарш не очень оправдано. Либо люди будут "надрываться" под тяжестью "воза" либо пакетная база сократится до базовой системы. Даже самый крутой специалист не будет тратить одинаковые усилия на поддержку каждого из 200 пакетов разной степени нужности/важности. Так зачем искусственно завышать "порог вхождения"? >>> Я полагаю, что 1 должно проверяться при приеме в тим. 2 есть обычная >>> админская работа. 3 -- не сложно, но надо этому учить. >>> Думаю, что человек, овладевший 1-3, весьма часто начинает и более >>> существенно дорабатывать пакет, все же общение здесь не проходит >>> даром. > > Согласен. Не нашел у нас заметных расхождений. :-) >> Человек отвечающий всем критериям начинает дорабатывать уже не пакет >> -- то что в него завернуто. Это отлично. Всегда ли обязательно? > > Возможно, стоит взять пакет попроще. Может быть, сразу и не будем > писать патчи. Но проерить присланный со стороны патч -- нужно? Нет вопросов. Я не агитирую доверять сборку пакетов из базовой системы тому кто даже не может проверить присланный патч. Но, если это какой-нибудь Xtetris а патч касается чисто упаковки и прислал его коллега универсал с заведомо более высоким уровнем квалификации, так ли уж важно может ли получатель его проверить без дополнительного обучения? Ведь всё не понятое можно переспросить... :) А стать универсалом можно только работая. Надеюсь, что идея с тренингом сработает как задуманно. Главное чтоб у учителей хватило сил и терпения. Я тоже не заметил значимых расхождений в наших позициях. :) -- Rgrds, Andriy ********************************************************************* email: dobr at iop dot kiev dot ua Kyiv, Ukraine Phone: (380-44) 525-7824 Department of Gas Electronics Fax: (380-44) 525-2329 Institute of Physics of NASU *********************dobrATjabber.iop.kiev.ua************************ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2009-01-13 12:49 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-10 3:45 [devel] perl packages Денис Смирнов 2008-12-16 7:19 ` Alexey Tourbin 2008-12-16 10:20 ` Michael Shigorin 2008-12-17 4:52 ` Alexey Tourbin 2008-12-17 6:44 ` Vitaly Lipatov 2008-12-29 9:27 ` Michael Shigorin 2008-12-18 11:24 ` Денис Смирнов 2008-12-18 11:54 ` Vladimir V. Kamarzin 2008-12-29 9:29 ` Michael Shigorin 2008-12-16 20:38 ` Vitaly Lipatov 2008-12-17 4:35 ` Alexey Tourbin 2008-12-17 6:44 ` Vitaly Lipatov 2008-12-17 7:11 ` Alexey Tourbin 2008-12-17 8:10 ` Igor Vlasenko 2008-12-17 19:53 ` [devel] perl packages [JT] Vitaly Lipatov 2008-12-21 12:31 ` Igor Vlasenko 2008-12-21 13:05 ` Vitaly Lipatov 2008-12-21 13:35 ` Igor Vlasenko 2008-12-21 13:41 ` Igor Vlasenko 2008-12-22 17:14 ` Slava Dubrovskiy 2008-12-17 20:00 ` [devel] perl packages Vitaly Lipatov 2008-12-29 9:21 ` [devel] майнтейнеры бывают разные *и это нормально* Michael Shigorin 2008-12-29 9:28 ` Led 2008-12-29 10:27 ` Michael Shigorin 2008-12-30 15:47 ` Alexey Tourbin 2008-12-30 15:53 ` Mikhail Gusarov 2008-12-30 15:53 ` Mikhail Gusarov 2008-12-30 16:34 ` Alexey Tourbin 2008-12-30 16:45 ` Mikhail Gusarov 2008-12-30 17:25 ` Alexey Tourbin 2008-12-30 17:38 ` Mikhail Gusarov 2008-12-31 20:44 ` Michael Shigorin 2008-12-31 4:30 ` [devel] [JT] " Alexey Morozov 2008-12-31 20:46 ` Michael Shigorin 2009-01-07 13:37 ` [devel] " Led 2009-01-07 13:38 ` Mikhail Gusarov 2008-12-31 20:39 ` Michael Shigorin 2009-01-01 0:13 ` Alexey Tourbin 2009-01-01 1:11 ` Денис Смирнов 2009-01-01 16:55 ` Michael Shigorin 2009-01-01 17:10 ` Aleksey Novodvorsky 2009-01-01 17:38 ` Michael Shigorin 2009-01-01 18:14 ` Denis Klimov 2009-01-02 11:52 ` Michael Shigorin 2009-01-07 14:13 ` Led 2009-01-07 14:24 ` Mikhail Gusarov 2009-01-07 18:54 ` Led 2009-01-07 19:37 ` Slava Semushin 2009-01-07 20:30 ` Michael Shigorin 2009-01-11 9:13 ` Stanislav Ievlev 2009-01-11 11:51 ` Mikhail Gusarov 2009-01-11 12:24 ` Ivan A. Melnikov 2009-01-02 11:51 ` Michael Shigorin 2009-01-12 15:46 ` Andrii Dobrovol`s`kii 2009-01-12 20:45 ` Aleksey Novodvorsky 2009-01-13 12:49 ` Andrii Dobrovol`s`kii [this message] 2009-01-13 13:56 ` Led 2009-01-13 15:38 ` Денис Смирнов 2009-01-13 16:03 ` Led 2009-01-13 16:08 ` Alexey I. Froloff 2009-01-13 16:10 ` Led 2009-01-14 6:32 ` Денис Смирнов 2009-01-13 16:36 ` Kirill A. Shutemov 2009-01-14 6:32 ` Денис Смирнов 2009-01-13 16:54 ` Andrii Dobrovol`s`kii 2009-01-01 17:20 ` Wartan Hachaturow 2009-01-07 14:15 ` Led 2008-12-29 9:17 ` [devel] perl packages Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=496C8DC8.2090204@iop.kiev.ua \ --to=dobr@iop.kiev.ua \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git