[devel] perl packages

[devel] perl packages

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

В каком состоянии у нас сейчас вообще упаковка перловых модулей?

А именно:
- какие есть живые инструменты отслеживания что "этот модуль стух"?
- в каком состоянии сейчас cpan2rpm (в курсе ли он про свежие изменения
  при упаковки перловых модулей)?

Собственно к чему я -- с учетом имеющегося инструментария у нас в общем-то
возможно в полностью автоматическом режиме больше половины CPAN опакетить.
И мне кажется что сделать это с точки зрения perl-программиста было бы
крайней полезно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Wed, Dec 10, 2008 at 06:45:55AM +0300, Денис Смирнов wrote:
> В каком состоянии у нас сейчас вообще упаковка перловых модулей?
> 
> А именно:
> - какие есть живые инструменты отслеживания что "этот модуль стух"?

Здесь не должно быть специальных инструментов.
Если пакет "работет для тебя", то он работает.
Обновление не должно быть строго предписанным (кроме CVE-XXX-YYY).

> - в каком состоянии сейчас cpan2rpm (в курсе ли он про свежие изменения
>   при упаковки перловых модулей)?

Не следует использовать cpan2rpm.

> Собственно к чему я -- с учетом имеющегося инструментария у нас в общем-то
> возможно в полностью автоматическом режиме больше половины CPAN опакетить.
> И мне кажется что сделать это с точки зрения perl-программиста было бы
> крайней полезно.

Грубо говоря, не следует автоматически обновлять пакеты до новых версий.
Нужно прочитать changelog, просмотреть исходники (хотя бы по диагонали),
попробовать что-нибудь запустить и т.п.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

On Tue, Dec 16, 2008 at 10:19:56AM +0300, Alexey Tourbin wrote:
> > - в каком состоянии сейчас cpan2rpm (в курсе ли он про свежие
> > изменения при упаковки перловых модулей)?
> Не следует использовать cpan2rpm.

1) почему, или "вообще"?
2) а cpan2spec?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: cpan2spec --]
[-- Type: text/plain, Size: 3706 bytes --]

#!/usr/bin/perl
# $Id$

use Switch;
use Cwd qw(realpath);
use ExtUtils::MakeMaker;
use File::Find qw(find);
use File::Temp qw(tempdir);
use sigtrap qw(die normal-signals);
use strict;

my %spec = (
	Name => 'perl-%dist',
	Release => 'alt1',
	License => 'GPL or Artistic',
	Group => 'Development/Perl',
	URL => '%CPAN %dist',
	Source => '%dist-%version.tar.bz2',
	BuildArch => 'noarch',
	prep => '%setup -q -n %dist-%version',
	build => '%perl_vendor_build',
	install => '%perl_vendor_install',
);

my @order = (
# name, type, optional
	[qw[ dist macro ]],
	[qw[ Name tag ]],
	[qw[ Version tag ]],
	[qw[ Release tag ]],
	[qw[ ]],
	[qw[ Summary tag ]],
	[qw[ License tag ]],
	[qw[ Group tag ]],
	[qw[ ]],
	[qw[ URL tag ]],
	[qw[ Source tag ]],
	[qw[ ]],
	[qw[ BuildArch tag 1 ]],
	[qw[ ]],
	[qw[ description section ]],
	[qw[ ]],
	[qw[ prep section ]],
	[qw[ ]],
	[qw[ build section ]],
	[qw[ ]],
	[qw[ install section ]],
	[qw[ ]],
	[qw[ files section ]],
);

@ARGV == 1 or print STDERR <<EOF and exit(1);
Usage:
1) go get your module at http://search.cpan.org/
2) zme <module>.tar.gz
3) $0 <module>.tar.*z* > ~/RPM/SOURES/perl-<module>.spec
4) vim ~/RPM/SOURES/perl-<module>.spec
5) buildreq ~/RPM/SOURES/perl-<module>.spec
6) add_changelog -e 'initial revision' ~/RPM/SOURES/perl-<module>.spec
7) rpm -ba ~/RPM/SOURES/perl-<module>.spec
EOF

{
	my $tarball = realpath $ARGV[0];
	my $dir = tempdir "cpan2spec.XXXXXXXXXX", TMPDIR => 1, CLEANUP => 1;
	chdir $dir;
	my $z	=	$tarball =~ /\.tar.bz2$/	&&	'j'
		||	$tarball =~ /\.tar.gz$/		&&	'z'
		||	do {	my $exhort = q(shpx gneonyy);
				$exhort =~ tr/A-Za-z/N-ZA-Mn-za-m/;
				die "$exhort $tarball\n";
			};
	system "tar", "xf$z", $tarball;
	chdir <*>;

	my $makefile;
	system $^X, qw(-pi -e s/\bexit\b/return/g Makefile.PL);
	*ExtUtils::MakeMaker::WriteMakefile = 
		sub { $makefile = { @_ }; bless $makefile, 'MM' }
		and do './Makefile.PL';
	$$makefile{DISTNAME} ||= $$makefile{NAME} and $$makefile{DISTNAME} =~ s/::/-/g;
	$spec{dist} ||= $$makefile{DISTNAME};

	find { wanted => sub { $$makefile{VERSION_FROM} ||= $_ if /\.pm$/ } 
		=> no_chdir => 1 } => ".";
		
	$spec{Version} ||= $$makefile{VERSION} ||
		$makefile->parse_version($$makefile{VERSION_FROM});
	$spec{Summary} ||= $$makefile{ABSTRACT}	|| 
		$makefile->parse_abstract($$makefile{ABSTRACT_FROM} || $$makefile{VERSION_FROM});
	$spec{Summary} ||= do {
		open my $fh, ($$makefile{ABSTRACT_FROM} || $$makefile{VERSION_FROM});
		my @lines = <$fh>;
		shift @lines while grep { /^=head1\s+name/i } @lines;
		shift @lines; local $_ = shift @lines;
		s/^[\w:-]+\s+[^\w\s]+\s+//;
		$_;
	};
	$spec{description} ||= do {
		open my $fh, ($$makefile{ABSTRACT_FROM} || $$makefile{VERSION_FROM});
		my @lines = <$fh>;
		shift @lines while grep { /^=head1\s+descr/i } @lines;
		shift @lines; local $_ = shift @lines;
		for my $line (@lines) {
			last unless $line =~ /\S/;
			$_ .= $line;
		}
		$_;
	};
	
	my $xs;
	find sub { ++$xs if /\.(xs|c)$/ } => ".";
	delete $spec{BuildArch} if $xs;
	
	my @doc = (<README*>, <Change*>);
	$spec{files} .= "\%doc @doc\n" if @doc;
	
	my %glob;
	find sub { /\.pm$/ and do {
			open my $fh, $_; 
			map { /^package\s+(\w+)/ && ++$glob{$1} } <$fh>; 
		}} => ".";
	foreach my $glob (sort keys %glob) {
		$spec{files} .= $xs
		? "\%perl_vendor_archlib/$glob*\n\%perl_vendor_autolib/$glob*\n"
		: "\%perl_vendor_privlib/$glob*\n";
		$spec{files} .= "\%perl_vendor_man3dir/$glob*\n";
	}
}

for (@order) {
	print "\n" and next unless @$_;
	next if not $spec{$$_[0]} and $$_[2];
	switch ($$_[1]) {
		case 'macro'	{ print "\%define $$_[0] " }
		case 'tag'	{ print "$$_[0]: " }
		case 'section'	{ print "\%$$_[0]\n" }
		else 		{ die "$$_[1] \n" }
	}
	print $spec{$$_[0]} . "\n";
}

Re: [devel] perl packages

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Tue, Dec 16, 2008 at 12:20:40PM +0200, Michael Shigorin wrote:
> On Tue, Dec 16, 2008 at 10:19:56AM +0300, Alexey Tourbin wrote:
> > > - в каком состоянии сейчас cpan2rpm (в курсе ли он про свежие
> > > изменения при упаковки перловых модулей)?
> > Не следует использовать cpan2rpm.
> 
> 1) почему, или "вообще"?

Не следует собирать пакеты автоматически, вообще.
(См. тж. соседний ответ.)

> 2) а cpan2spec?

Если только как заготовка для начального spec-файла.

Сборка перловых пакетов хорошо автоматизирована, но простота
может быть обманчивой.

Например, в перловых пакетах на CPAN могут использоваться схемы
версионирования, плохо совместимые с rpm (на CPAN используется
"десятичная точка", а в rpm используются "целочисленные сегменты").

Пример: Виталий Липатов автоматически обновил пакет perl-Devel-StackTrace
с версии 1.18 до версии 1.1901.  Новая версия на CPAN -- 1.20.  Теперь,
чтобы обновить пакет ещё раз, в пакет придётся добавлять Serial.  Вряд
ли cpan2rpm добавит Serial автоматически (а также добавление Serial
можно рассматривать как недостаток сам по себе).  Или же, можно
надеяться, что следующей версией будет 1.2001 (на что рассчитывать,
конечно же, не следует).

На самом деле следовало бы выставлять версию не 1.1901, а 1.19_01
или 1.19.01.  Такие версии хорошо обновляются до 1.20.  Но надо было
смотреть и думать, а если пакет собран неглядя, то никакого спроса нет.
Все претензии к скрипту cpan2rpm.  А это получается профанация всей
нашей работы как явления вообще.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Vitaly Lipatov]

On 17 декабря 2008, Alexey Tourbin wrote:
...
> Сборка перловых пакетов хорошо автоматизирована, но простота
> может быть обманчивой.
>
> Например, в перловых пакетах на CPAN могут использоваться
> схемы версионирования, плохо совместимые с rpm (на CPAN
> используется "десятичная точка", а в rpm используются
> "целочисленные сегменты").
Это же ещё надо знать. А если знаешь, придумать схему
_автоматического_ согласования схемы нумерации, раз уж она 
определена с обоих сторон.

> Пример: Виталий Липатов автоматически обновил пакет
> perl-Devel-StackTrace с версии 1.18 до версии 1.1901.  Новая
> версия на CPAN -- 1.20.  Теперь, чтобы обновить пакет ещё раз,
> в пакет придётся добавлять Serial.  Вряд ли cpan2rpm добавит
Да, не повезло. Но величина трагедии в данном случае измеряется 
не самим проступком, а используемостью пакета. Если никто не 
заметит, так и проблемы нет.
...
> На самом деле следовало бы выставлять версию не 1.1901, а
> 1.19_01 или 1.19.01.  Такие версии хорошо обновляются до 1.20.
>  Но надо было смотреть и думать, а если пакет собран неглядя,
> то никакого спроса нет. Все претензии к скрипту cpan2rpm.  А
Я хотел бы уточнить, что cpan2rpm тут ни при чём, поскольку он 
действительно делает лишь начальный спек (обычно собирающийся, 
впрочем), но в дальнейшем обновлении никак не участвует.

> это получается профанация всей нашей работы как явления
> вообще.
А наша работа и есть переливание из пустого в порожнее. 
Распарываем кафтан и шьём сюртук, потом и его распарываем, и так 
по кругу.
Ручная работа всех мантейнеров мира могла бы быть вынесена на 
более верхний уровень. Приспосабливание к условиям конкретного 
репозитория должно быть автоматической задачей, при наличии 
исходников, в которых соблюдаются определённые правила, которые 
не меняются с каждой версией.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] perl packages

[Michael Shigorin]

On Wed, Dec 17, 2008 at 07:52:15AM +0300, Alexey Tourbin wrote:
> На самом деле следовало бы выставлять версию не 1.1901, а
> 1.19_01 или 1.19.01.  Такие версии хорошо обновляются до 1.20.

Может, нормализовать на четыре и всё?  Или это как минимум
сломает зависимости вида ">= 1.20"?

> Но надо было смотреть и думать, а если пакет собран неглядя,
> то никакого спроса нет.  Все претензии к скрипту cpan2rpm.

Скрипт не подписывал.

> А это получается профанация всей нашей работы как явления
> вообще.

Ой, я тебя умоляю.  Мне с людьми работы хватает по самое
не балуйся, а ты ещё призываешь полуддитствовать вволю.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] perl packages

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

On Tue, Dec 16, 2008 at 12:20:40PM +0200, Michael Shigorin wrote:

MS> 2) а cpan2spec?

А этот скриптик откуда?

P.S. Вот думаю не пора ли писать cpan2gear ;)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Vladimir V. Kamarzin]

>>>>> On 18 Dec 2008 at 16:24 "m" == mithraen  writes:

m> P.S. Вот думаю не пора ли писать cpan2gear ;)

Обязательно пора.

-- 
vvk

Re: [devel] perl packages

[Michael Shigorin]

On Thu, Dec 18, 2008 at 02:24:14PM +0300, Денис Смирнов wrote:
> MS> 2) а cpan2spec?
> А этот скриптик откуда?

Из тум^W~/bin, разумеется :]

http://lists.altlinux.org/pipermail/devel/2004-April/022488.html

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] perl packages

[Vitaly Lipatov]

On 16 декабря 2008, Alexey Tourbin wrote:
> > - в каком состоянии сейчас cpan2rpm (в курсе ли он про
> > свежие изменения при упаковки перловых модулей)?
>
> Не следует использовать cpan2rpm.
Высокомерно.
Я так не считаю.



-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] perl packages

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Tue, Dec 16, 2008 at 11:38:37PM +0300, Vitaly Lipatov wrote:
> On 16 декабря 2008, Alexey Tourbin wrote:
> > > - в каком состоянии сейчас cpan2rpm (в курсе ли он про
> > > свежие изменения при упаковки перловых модулей)?
> >
> > Не следует использовать cpan2rpm.
> Высокомерно.
> Я так не считаю.

Я имел в виду, что не следует автоматически собирать пакеты (вообще).
Если бы стояла задача автоматически импортировать исходники в пакеты
(а заодно можно было бы импортировать, например, и патчи из федоры),
тогда можно было бы решать именно эту задачу (более или менее усшено),
а мейнтейнеров разогнать метлой.

Но задача так не стоит.  Задача более сложная, и она включает в себя
повышение квалификации мейнтейнеров.  Человек-скрипт, если он выполняет
только рутинные действия, -- это никуда не годится, и в этом нет
никакого смысла.  Так что, хотя автоматическое обновление пакетов
отчасти и возможно, эту возможность не следует широко использовать.
Она профанирует весь процесс.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Vitaly Lipatov]

On 17 декабря 2008, Alexey Tourbin wrote:
> On Tue, Dec 16, 2008 at 11:38:37PM +0300, Vitaly Lipatov wrote:
> > On 16 декабря 2008, Alexey Tourbin wrote:
> > > > - в каком состоянии сейчас cpan2rpm (в курсе ли он про
> > > > свежие изменения при упаковки перловых модулей)?
> > >
> > > Не следует использовать cpan2rpm.
> >
> > Высокомерно.
> > Я так не считаю.
>
> Я имел в виду, что не следует автоматически собирать пакеты
> (вообще). Если бы стояла задача автоматически импортировать
> исходники в пакеты (а заодно можно было бы импортировать,
> например, и патчи из федоры), тогда можно было бы решать
> именно эту задачу (более или менее усшено), а мейнтейнеров
> разогнать метлой.
>
> Но задача так не стоит.  Задача более сложная, и она включает
Мне кажется, задача-идеал состоит как раз в том, чтобы пакеты 
собирались самостоятельно. Понятно, что она упирается в качество 
мейнстрима, на что мы не можем сильно влиять.

> в себя повышение квалификации мейнтейнеров.  Человек-скрипт,
> если он выполняет только рутинные действия, -- это никуда не
> годится, и в этом нет никакого смысла.  Так что, хотя
Получается - ручная сборка, ради повышения квалификации? Немного 
странно.

> автоматическое обновление пакетов отчасти и возможно, эту
> возможность не следует широко использовать. Она профанирует
> весь процесс.
Безусловно, собрать пакет автоматом, и не глядя надеяться, что он 
будет работать - это наивно. Я и сам был бы рад, если бы Сизиф 
поддерживался в актуальном состоянии тысячью-двумя мантейнерами.

Но я вижу кухню сборки пакетов в том, что пакеты собираются на 
конвейере, а люди ходят рядом, и иногда связывают порванные 
нитки и поправляют катушки. А освободившееся время тратят на 
дальнейшую автоматизацию процесса.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] perl packages

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

On Wed, Dec 17, 2008 at 09:44:51AM +0300, Vitaly Lipatov wrote:
> > Я имел в виду, что не следует автоматически собирать пакеты
> > (вообще). Если бы стояла задача автоматически импортировать
> > исходники в пакеты (а заодно можно было бы импортировать,
> > например, и патчи из федоры), тогда можно было бы решать
> > именно эту задачу (более или менее усшено), а мейнтейнеров
> > разогнать метлой.
> >
> > Но задача так не стоит.  Задача более сложная, и она включает
> Мне кажется, задача-идеал состоит как раз в том, чтобы пакеты 
> собирались самостоятельно. Понятно, что она упирается в качество 
> мейнстрима, на что мы не можем сильно влиять.

Нельзя недооценивать, сразу с двух сторон.  Если идеальная задача
сводится к автоматическому импортировнию новых версий, то Алексей
Турбин может написать очень умный скрипт, а мейнтейнеров придётся
разогнать метлой.

Немного утрируя, имеем дилемму: либо умный скрипт, и мейнтейнеры
не нужны; либо умный скрипт не нужен, а нужна вера в людей, что они
способны сделать что-то достаточно умное и нетривиальное.

В первом случае на выходе (по части технологии) имеем репликацию федоры.
Во втором случае имеем задаток для community разработчиков.

> > в себя повышение квалификации мейнтейнеров.  Человек-скрипт,
> > если он выполняет только рутинные действия, -- это никуда не
> > годится, и в этом нет никакого смысла.  Так что, хотя
> Получается - ручная сборка, ради повышения квалификации? Немного 
> странно.

Нужны мейнтейнеры, которые хоть немного разбираются в коде.  С которых
можно хоть что-то спросить, даже если они ошибаются.

> > автоматическое обновление пакетов отчасти и возможно, эту
> > возможность не следует широко использовать. Она профанирует
> > весь процесс.
> Безусловно, собрать пакет автоматом, и не глядя надеяться, что он 
> будет работать - это наивно. Я и сам был бы рад, если бы Сизиф 
> поддерживался в актуальном состоянии тысячью-двумя мантейнерами.
> 
> Но я вижу кухню сборки пакетов в том, что пакеты собираются на 
> конвейере, а люди ходят рядом, и иногда связывают порванные 
> нитки и поправляют катушки. А освободившееся время тратят на 
> дальнейшую автоматизацию процесса.

Есть два аспекта нашей работы: технологический и когнитивный.
Технологический означает что пакеты в репозитарии поддерживаются на
неплохом уровне.  Когнитивный означает "Intel Inside - Idiot Outside".

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl packages

[Igor Vlasenko]

On Wed, Dec 17, 2008 at 10:11:49AM +0300, Alexey Tourbin wrote:
> On Wed, Dec 17, 2008 at 09:44:51AM +0300, Vitaly Lipatov wrote:
> > > Я имел в виду, что не следует автоматически собирать пакеты
> > > (вообще). Если бы стояла задача автоматически импортировать
> > > исходники в пакеты (а заодно можно было бы импортировать,
> > > например, и патчи из федоры), тогда можно было бы решать
> > > именно эту задачу (более или менее усшено), а мейнтейнеров
> > > разогнать метлой.
> > >
> > > Но задача так не стоит.  Задача более сложная, и она включает
> > Мне кажется, задача-идеал состоит как раз в том, чтобы пакеты 
> > собирались самостоятельно. Понятно, что она упирается в качество 
> > мейнстрима, на что мы не можем сильно влиять.
> 
> > Но я вижу кухню сборки пакетов в том, что пакеты собираются на 
> > конвейере, а люди ходят рядом, и иногда связывают порванные 
> > нитки и поправляют катушки. А освободившееся время тратят на 
> > дальнейшую автоматизацию процесса.

> Немного утрируя, имеем дилемму: либо умный скрипт, и мейнтейнеры
> не нужны; либо умный скрипт не нужен, а нужна вера в людей, что они
> способны сделать что-то достаточно умное и нетривиальное.

Я упомянутые подходы реализовал на практике, поэтому
могу сказать из реальной жизни. Там дилемма: "либо умный скрипт, 
и мейнтейнеры не нужны; либо умный скрипт не нужен, а нужна вера в людей"
просто не возникает. Нет такой диллемы.

Есть диллема - делать руками механические однообразные повторяющиеся 
действия или написать для их автоматизации скрипт.

Скрипты нужны для разгрузки мейнтейнера от __тупых__ задач.
Умные задачи на мейнтейнере висят и будут висеть, никуда 
они не денутся :) Искусственный интеллект не создан :(

Тупые задачи терпимы, когда их мало (либо майнтайнеров очень
много, и удельная доля тупых задач на майнтайнера низка).

Приведу пример. Пусть, например, в идеале на 600 java пакетов в
сизифе было бы 200-300 мейнтейнеров. Собравшись на свою
ежегодную конференцию, они бы дружно решили, что пора 
переезжать на java 5. Вернувшись домой, каждый на досуге 
взял бы 2-4 своих пакета и внес тривиальные изменения в спек.

А вот что в реальной жизни.
Тихо сам с собою я провел беседу и решил переезжать на java 5.
Теперь надо взять 300-400 пакетов, и для начала сделать следующее:

- установить srpm.
- поправить спек {
	- изменить BuildRequires на java5
	- добавить к вызовам ant -source 1.4, -target 1.4
	- добавить к вызовам maven -source 1.4, -target 1.4
	- увеличить Release:
	- добавить %changelog "собрано под java5"
  }
- собрать полученный srpm.

Вручную эта операция займет 3-5 минут.
На 300-400 пакетах это 25 рабочих часов.
Не вижу смысла сидеть три дня и три ночи делать мартышкин труд,
если робот поправит все эти 300-400 пакетов за те же 3-5 мин.

Далее самое интересное. Все ли из этих 300-400 пакетов
пересобрутся в hasher? Ответ - не все.

Здесь и проявляется принципиальная необходимость 
майнтайнерства. В семье из 300 пакетов не без 5% уродов,
с которыми надо будет весьма нетривиально бороться.
Никакой скрипт там не поможет :)
 
-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] perl packages [JT]

[Vitaly Lipatov]

On 17 декабря 2008, Igor Vlasenko wrote:
> On Wed, Dec 17, 2008 at 10:11:49AM +0300, Alexey Tourbin wrote:
> > On Wed, Dec 17, 2008 at 09:44:51AM +0300, Vitaly Lipatov 
wrote:
> > > > Я имел в виду, что не следует автоматически собирать
> > > > пакеты (вообще). Если бы стояла задача автоматически
> > > > импортировать исходники в пакеты (а заодно можно было бы
> > > > импортировать, например, и патчи из федоры), тогда можно
> > > > было бы решать именно эту задачу (более или менее
> > > > усшено), а мейнтейнеров разогнать метлой.
> > > >
> > > > Но задача так не стоит.  Задача более сложная, и она
> > > > включает
> > >
> > > Мне кажется, задача-идеал состоит как раз в том, чтобы
> > > пакеты собирались самостоятельно. Понятно, что она
> > > упирается в качество мейнстрима, на что мы не можем сильно
> > > влиять.
> > >
> > > Но я вижу кухню сборки пакетов в том, что пакеты
> > > собираются на конвейере, а люди ходят рядом, и иногда
> > > связывают порванные нитки и поправляют катушки. А
> > > освободившееся время тратят на дальнейшую автоматизацию
> > > процесса.
> >
> > Немного утрируя, имеем дилемму: либо умный скрипт, и
> > мейнтейнеры не нужны; либо умный скрипт не нужен, а нужна
> > вера в людей, что они способны сделать что-то достаточно
> > умное и нетривиальное.
>
> Я упомянутые подходы реализовал на практике, поэтому
> могу сказать из реальной жизни. Там дилемма: "либо умный
> скрипт, и мейнтейнеры не нужны; либо умный скрипт не нужен, а
> нужна вера в людей" просто не возникает. Нет такой диллемы.
>
> Есть диллема - делать руками механические однообразные
> повторяющиеся действия или написать для их автоматизации
> скрипт.
>
> Скрипты нужны для разгрузки мейнтейнера от __тупых__ задач.
> Умные задачи на мейнтейнере висят и будут висеть, никуда
> они не денутся :) Искусственный интеллект не создан :(
>
> Тупые задачи терпимы, когда их мало (либо майнтайнеров очень
> много, и удельная доля тупых задач на майнтайнера низка).
Соглаcен с Игорем по его выводам.

...

> 	- изменить BuildRequires на java5
> 	- добавить к вызовам ant -source 1.4, -target 1.4
> 	- добавить к вызовам maven -source 1.4, -target 1.4
Я вот считаю, что необходимость этих изменений - в неправильно 
оформленном спеке. Такие вещи должны быть заменены макросами, 
определёнными для текущей версии окружения.
А так это всё равно что в каждом пакете указывать gcc4.1, а  
потом автоматом это всё перезаписывать на gcc4.3 :)


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] perl packages [JT]

[Igor Vlasenko]

On Wed, Dec 17, 2008 at 10:53:21PM +0300, Vitaly Lipatov wrote:
> > 	- изменить BuildRequires на java5
> > 	- добавить к вызовам ant -source 1.4, -target 1.4
> > 	- добавить к вызовам maven -source 1.4, -target 1.4
> Я вот считаю, что необходимость этих изменений - в неправильно 
> оформленном спеке. Такие вещи должны быть заменены макросами, 
> определёнными для текущей версии окружения.
> А так это всё равно что в каждом пакете указывать gcc4.1, а  
> потом автоматом это всё перезаписывать на gcc4.3 :)

Этот пример не из реальной жизни :) Он специально упрощен,
для наглядности тезиса.

Что касается ant, это хороший вопрос. 
Он уже не раз задавался,
и хотелось бы на него ответить с занесением в FAQ.

Q: будут ли еще какие-либо макросы для сборки с помощью 
ant, кроме %ant ?

A: Нет, к сожалению, универсальные макросы для %ant 
не возможны по самой природе ant.
файлы build.xml по своей природе подобны
самописанным Makefile.
По той же причине для make не существует универсальных
макросов, кроме %make.

Хорошей иллюстрацией к сказанному служат наши макросы
%make_install, %makeinstall_std... итд.

Эти макросы возможны потому, что большинство пакетов
собирается autotools. Поэтому у них Makefile генерированы,
а у генерированных Makefile, в отличие от самописанных 
Makefile, соблюдаются определенные соглашения, 
что и позволяет создавать дополнительные макросы.
Эти дополнительные макросы с самописанной системой сборки
работать не будут. Другое дело, что для С в большинстве своем
самописанные системы сборки вымерли :)

файлы build.xml у нас в основном не генерируются,
и соблюдения каких-либо доп. соглашений от них ожидать нельзя.



-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] perl packages [JT]

[Vitaly Lipatov]

On 21 декабря 2008, Igor Vlasenko wrote:
> On Wed, Dec 17, 2008 at 10:53:21PM +0300, Vitaly Lipatov wrote:
> > > 	- изменить BuildRequires на java5
> > > 	- добавить к вызовам ant -source 1.4, -target 1.4
> > > 	- добавить к вызовам maven -source 1.4, -target 1.4
...
> A: Нет, к сожалению, универсальные макросы для %ant
> не возможны по самой природе ant.
> файлы build.xml по своей природе подобны
> самописанным Makefile.
...
> файлы build.xml у нас в основном не генерируются,
> и соблюдения каких-либо доп. соглашений от них ожидать нельзя.
Я правильно понимаю, что упомянутые параметры
-source 1.4, -target 1.4
действительны только для конкретного build.xml в одном из 
пакетов?

-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] perl packages [JT]

[Igor Vlasenko]

On Sun, Dec 21, 2008 at 04:05:37PM +0300, Vitaly Lipatov wrote:
> > > > 	- изменить BuildRequires на java5
> > > > 	- добавить к вызовам ant -source 1.4, -target 1.4
> > > > 	- добавить к вызовам maven -source 1.4, -target 1.4
> ...
> > A: Нет, к сожалению, универсальные макросы для %ant
> > не возможны по самой природе ant.
> > файлы build.xml по своей природе подобны
> > самописанным Makefile.
> ...
> > файлы build.xml у нас в основном не генерируются,
> > и соблюдения каких-либо доп. соглашений от них ожидать нельзя.
> Я правильно понимаю, что упомянутые параметры
> -source 1.4, -target 1.4
> действительны только для конкретного build.xml в одном из 
> пакетов?

Не совсем. Конкретно -Dant.build.javac.source=1.4 -Dant.build.javac.target=1.4
суть общие параметры ant, но в одни пакеты 
их ставить можно, в другие нужно, в третьи нелья.
И не только макрос, но и даже робот не разберется
без бутылки смазки :)

Пример 1.

В build.xml уже руками прописан, например, -target 1.3.
Если извне написать -source 1.4, -target 1.4,
то получится -source 1.4 -target 1.3 (нехороший ант проигнорирует
общую опцию при наличии частной) что некорректно и javac не запустится.

Ничего извне писать тоже нельзя, так как под java5 не проходит генерация
javadoc. Выход - написать -source 1.3, -target 1.3.

Пример 2.
Пакет требует java >=5 для сборки.
Очевидно (но не макросу), что -source 1.4, -target 1.4
писать нельзя.

Пример 3.
Пакет не собирался под java5.
Добавили -Dant.build.javac.source=1.4 -Dant.build.javac.target=1.4
и он собрался :)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] perl packages [JT]

[Igor Vlasenko]

On Sun, Dec 21, 2008 at 02:31:07PM +0200, Igor Vlasenko wrote:
> 
> Q: будут ли еще какие-либо макросы для сборки с помощью 
> ant, кроме %ant ?
> 
> A: Нет, к сожалению, универсальные макросы для %ant 
> не возможны по самой природе ant.
> файлы build.xml по своей природе подобны
> самописанным Makefile.

Зато написание макросов для maven2 - вещь осмысленная
и благодарная :)
Так что там макросы будут :)

Путь к ним проходит через 2 этапа
1) обновить maven2 до 2.0.7
2) написать HOWTO по сборке с помощью maven2.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] perl packages [JT]

[Slava Dubrovskiy]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

Igor Vlasenko пишет:
> Зато написание макросов для maven2 - вещь осмысленная
> и благодарная :)
> Так что там макросы будут :)
>
> Путь к ним проходит через 2 этапа
> 1) обновить maven2 до 2.0.7
> 2) написать HOWTO по сборке с помощью maven2.
>   
Мне пока проще получается таскать весь репозитарий в src. Слишком мало у
нас нужных плагинов.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3262 bytes --]

Re: [devel] perl packages

[Vitaly Lipatov]

On 17 декабря 2008, Alexey Tourbin wrote:
...
> Нельзя недооценивать, сразу с двух сторон.  Если идеальная
> задача сводится к автоматическому импортировнию новых версий,
> то Алексей Турбин может написать очень умный скрипт, а
> мейнтейнеров придётся разогнать метлой.
Ну если бы Алексей Турбин захотел, он бы давно написал.
Поскольку скрипта нет, приходится действовать самостоятельно.

> Немного утрируя, имеем дилемму: либо умный скрипт, и
> мейнтейнеры не нужны; либо умный скрипт не нужен, а нужна вера
> в людей, что они способны сделать что-то достаточно умное и
> нетривиальное.
>
> В первом случае на выходе (по части технологии) имеем
> репликацию федоры. Во втором случае имеем задаток для
> community разработчиков.
Согласен. Никто не оспаривает полезность мантейнерства для 
саморазвития. Я даже согласен, когда вы привлечёте ещё 200 
мантейнеров, отдать каждому по пакету, для освоения перла и 
починки внутрипакетных тестов.

...
> > Получается - ручная сборка, ради повышения квалификации?
> > Немного странно.
>
> Нужны мейнтейнеры, которые хоть немного разбираются в коде.  С
> которых можно хоть что-то спросить, даже если они ошибаются.
Эти два требования не противоречат друг другу.
Я вот немного разбираюсь, но к сожалению, только немного, потому 
как практики мало.
И спросить с меня тоже можно.

...
> > Но я вижу кухню сборки пакетов в том, что пакеты собираются
> > на конвейере, а люди ходят рядом, и иногда связывают
> > порванные нитки и поправляют катушки. А освободившееся время
> > тратят на дальнейшую автоматизацию процесса.
>
> Есть два аспекта нашей работы: технологический и когнитивный.
> Технологический означает что пакеты в репозитарии
> поддерживаются на неплохом уровне.  Когнитивный означает
> "Intel Inside - Idiot Outside".
Я не знаю что такое "когнитивный", но честно говоря, меня мало 
волнует нетехническая сторона Сизифа. Этим занимаются другие 
люди. А мне и моим сотрудникам нужно решать конкретные задачи, а 
не ждать у моря счастья, когда же мантейнера озарит, и он 
пересоберёт пакет perl-Config-General.

Алексей, ещё раз повторюсь, что согласен с Вами по обсуждаемой 
теме, в том числе требованием определенной степени внимания 
мантейнера к собираемому им пакету.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

[devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Wed, Dec 17, 2008 at 10:11:49AM +0300, Alexey Tourbin wrote:
> Нужны мейнтейнеры, которые хоть немного разбираются в коде.

Лёш, просьба не забывать про майнтейнеров, которым надо, 
чтоб работало.  Перепаковщиков тарболов.  Из админов.

Вряд ли стоит делать ту же глупость, что и иные говорящие
"инженеры не нужны" учёные.

И да, мне уже поднадоело повторять это.

-- 
перепаковщик тарболов вульгарис

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Monday, 29 December 2008 11:21:26 Michael Shigorin wrote:
> On Wed, Dec 17, 2008 at 10:11:49AM +0300, Alexey Tourbin wrote:
> > Нужны мейнтейнеры, которые хоть немного разбираются в коде.
>
> Лёш, просьба не забывать про майнтейнеров, которым надо,
> чтоб работало.  Перепаковщиков тарболов.  Из админов.

А также не надо забывать про тех, которым надо "чтоб работало" не только у 
тех, кто "перепаковывает из тарболов".

>
> Вряд ли стоит делать ту же глупость, что и иные говорящие
> "инженеры не нужны" учёные.
>
> И да, мне уже поднадоело повторять это.



-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Mon, Dec 29, 2008 at 11:28:08AM +0200, Led wrote:
> > > Нужны мейнтейнеры, которые хоть немного разбираются в коде.
> > Лёш, просьба не забывать про майнтейнеров, которым надо,
> > чтоб работало.  Перепаковщиков тарболов.  Из админов.
> А также не надо забывать про тех, которым надо "чтоб работало"
> не только у тех, кто "перепаковывает из тарболов".

Ты знал :)  Для этого и помогает работать вместе, а не по углам.
И обмениваться опытом.  Для чего, в свою очередь, требуется
умение общаться.

А оно берётся из желания общаться, умения услышать, терпения.

В частности, разработчикам может быть удобнее общаться напрямую
с апстримом вообще.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

On Mon, Dec 29, 2008 at 11:21:26AM +0200, Michael Shigorin wrote:
> On Wed, Dec 17, 2008 at 10:11:49AM +0300, Alexey Tourbin wrote:
> > Нужны мейнтейнеры, которые хоть немного разбираются в коде.
> 
> Лёш, просьба не забывать про майнтейнеров, которым надо, 
> чтоб работало.  Перепаковщиков тарболов.  Из админов.
> 
> Вряд ли стоит делать ту же глупость, что и иные говорящие
> "инженеры не нужны" учёные.

Это было бы так, если бы у нас была "Рудора".  Тогда можно было
бы надеяться, что пакеты будут просто работать, поскольку работа
базируется на чужом репозитарии.

Но у нас-то это декларируется как самостоятельная разработка, люди
надувают щеки, речь идёт чуть ли не там о какой-то национальной
операционной системе.  И, между прочем, о поддержке.  А оказывается,
что это люди всего лишь перепаковывают тарболлы.  Much ado about nothing.
Не все, конечно.

Кстати, сравнение с Федорой может быть обманчивым.  В Федоре много
людей-апстримов, то есть Редхат ведёт стратегическую разработку на другом,
более серьезном уровне.  Сборка пакетов и поддержка репозитария Федоры --
это у них лишь верхняя часть айсберга.  Например, вся библиотека GIO
(удаленный доступ к файлам для стека GNOME библиотек) была
разрабатывалась редхатом сразу в апстриме.  Глядя же на изменения
пакетов в Федоре, легко обмануться и подумать, что Редахт тоже
перепаковывает тарболлы.  Примерно как и мы.

Короче, перепаковка тарболлов -- это карго-культ разработки.
Нормально это или нет, я не знаю, но чего здесь нет, так это
собственно разработки.

У нас нет глубокой подводной части айсберга, как у Редхата, то есть
у нас мало стратегической разработки на уровне апстримов.  Думаю однако
что камень нужно двигать именно в ту сторону (а не только заниматься
вылизыванием пакетов на уровне перепаковки).  Переход на сборку из gear
в какой-то степени может этому способствовать.

> И да, мне уже поднадоело повторять это.

Мне кажется, что ты сдвигаешь понятия (проводя аналогию между учеными
и инженерами).  Ученые тут должны заниматься языками программирования,
типа haskell, там deforestation, преобразования кода, сохраняющие
эквивалентность.  Ученым есть чем заняться помимо существующего кода.
С большим прибором.  А разбираться в коде это всё-таки компетенция инженеров.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Twas brillig at 18:47:22 30.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> У нас нет глубокой подводной части айсберга, как у Редхата, то есть
 AT> у нас мало стратегической разработки на уровне апстримов.  Думаю
 AT> однако что камень нужно двигать именно в ту сторону (а не только
 AT> заниматься вылизыванием пакетов на уровне перепаковки).

А зачем связывать две вещи: пакетирование и upstream-разработку? Их
можно и нужно явно декларировать как отдельные деятельности.

Впрочем, upstream-разработка в альте тоже есть, только она почему-то
таковой не считается: альтовый вариант RPM и всю git-related машинерию
по пакетированию вполне можно считать upstream'ом. То, что большая часть
альтовой upstream-разработки относится к пакетированию, может сбивать с
толку, но только на первый взгляд.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

Twas brillig at 21:53:04 30.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> как отдельные деятельности.

... в рамках одного проекта.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

On Tue, Dec 30, 2008 at 09:53:04PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 18:47:22 30.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> У нас нет глубокой подводной части айсберга, как у Редхата, то есть
>  AT> у нас мало стратегической разработки на уровне апстримов.  Думаю
>  AT> однако что камень нужно двигать именно в ту сторону (а не только
>  AT> заниматься вылизыванием пакетов на уровне перепаковки).
> 
> А зачем связывать две вещи: пакетирование и upstream-разработку? Их
> можно и нужно явно декларировать как отдельные деятельности.

Да, тут по сути есть симбиоз между сбркой пакетов и более серьезной
разработкой.  Это наши исторические предпосылки.  Проект Sisyphus
начинался как доработка Mandrakde, а потом перерос во что-то более
самостоятельное.

Нужно ли связывать сборку пакетов и разработку кода, или нет?
Может, лучше эти функции чётко разделить?  Я считаю, что нет.
Участие в проекте Sisyphus можно рассматривать как инвестиции в себя
(правда, с очень непонятным исходном, который не следовало бы переводить
на деньги).  Мейнтейнер должен разобраться в коде, если ему это
интересно.  А если ему это не интересно, то кому это интересно?

> Впрочем, upstream-разработка в альте тоже есть, только она почему-то
> таковой не считается: альтовый вариант RPM и всю git-related машинерию
> по пакетированию вполне можно считать upstream'ом. То, что большая часть
> альтовой upstream-разработки относится к пакетированию, может сбивать с
> толку, но только на первый взгляд.

Оставим пока RPM в покое.  И ещё alterator оставим в покое.  Что это
значит?  Самостоятельные разработки конечно есть, но они скорее
перефирийные, а не стратегические.  Запаковка rpm-пакетов, настройка
системы -- это такое самообслуживание.  Надо что-то делать с тем, что
мы тут сами напридумали.  Что-то делается.

С другой стороны, надо смотреть наш вклад, грубо говоря, неспецифический
для нас, а полезный для всех остальных (но и, конечно, для нас тоже).
Это я называю "стратегической разработкой", как некий показатель успеха
вообще, а не в частности.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

Twas brillig at 19:34:17 30.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Нужно ли связывать сборку пакетов и разработку кода, или нет?
 AT> Может, лучше эти функции чётко разделить?  Я считаю, что нет.

Я говорил про деятельности. Один и тот же человек вполне может
заниматься и тем, и другим, но для всех будет лучше, если он будет
отдавать себе отчёт, чем он занимается, иначе возникает конфуз:
прикрываясь именем проекта и пакетированием, мейнтейнер, по сути, ведёт
форк проекта, и под именем upstream'а складывает в дистрибутив нечто
совершенно иное.

Если деятельности разделять, то такой путаницы нет: либо есть тщательно
упакованный upstream-проект, интегрированный с местными особенностями,
либо есть явный форк, и в дистрибутив/репозиторий упаковывается форк.

Выяснение же извне, лежит ли в пакете форк или не форк, в каждом
конкретном случае является трудоёмким и поэтому развешивать правильные
ярлычки - обязанность (и моральное обязательство по отношению к
апстриму) мейнтейнеров.

 AT> Мейнтейнер должен разобраться в коде, если ему это интересно.  А
 AT> если ему это не интересно, то кому это интересно?

Не, с этим никто не спорит. Стоит лишь прояснить, что мейнтейнерство -
это деятельность, и человек, являющийся мейнтейнером, может заниматься и
upstream-разработкой, но мейнтейнерством это называть уже не стоит.

 AT> С другой стороны, надо смотреть наш вклад, грубо говоря,
 AT> неспецифический для нас, а полезный для всех остальных (но и,
 AT> конечно, для нас тоже).  Это я называю "стратегической
 AT> разработкой", как некий показатель успеха вообще, а не в частности.

Ты упускаешь одну категорию "всех остальных" - остальные разработчики
дистрибутивов. Как для этой категории уже имеющиеся наработки Сизифа
могут быть востребованы.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

On Tue, Dec 30, 2008 at 10:45:42PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 19:34:17 30.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Нужно ли связывать сборку пакетов и разработку кода, или нет?
>  AT> Может, лучше эти функции чётко разделить?  Я считаю, что нет.
> 
> Я говорил про деятельности. Один и тот же человек вполне может
> заниматься и тем, и другим, но для всех будет лучше, если он будет
> отдавать себе отчёт, чем он занимается, иначе возникает конфуз:
> прикрываясь именем проекта и пакетированием, мейнтейнер, по сути, ведёт
> форк проекта, и под именем upstream'а складывает в дистрибутив нечто
> совершенно иное.

Давайте оставим в покое RPM (если это имеется в виду).
Он сейчас работает в некоторых отношениях очень хорошо.
А в других отношениях нет кворума понимания, что с ним надо делать.

> Если деятельности разделять, то такой путаницы нет: либо есть тщательно
> упакованный upstream-проект, интегрированный с местными особенностями,
> либо есть явный форк, и в дистрибутив/репозиторий упаковывается форк.
> 
> Выяснение же извне, лежит ли в пакете форк или не форк, в каждом
> конкретном случае является трудоёмким и поэтому развешивать правильные
> ярлычки - обязанность (и моральное обязательство по отношению к
> апстриму) мейнтейнеров.

Мы рискуем погрязнуть в передрягах, до которых никому кроме нас дела нет.
Вроде русские собаки грызутся, а людям смешно.

>  AT> Мейнтейнер должен разобраться в коде, если ему это интересно.  А
>  AT> если ему это не интересно, то кому это интересно?
> 
> Не, с этим никто не спорит. Стоит лишь прояснить, что мейнтейнерство -
> это деятельность, и человек, являющийся мейнтейнером, может заниматься и
> upstream-разработкой, но мейнтейнерством это называть уже не стоит.

Человек есть нечто, что должно превзойти.  Люди развиваются, они
проходят путь от поверхностного ознакомления к более глубокому пониманию,
это нормальный ницшеанский взгляд.  Хороший мейнтейнер может стать
upstream-разработчиком.

>  AT> С другой стороны, надо смотреть наш вклад, грубо говоря,
>  AT> неспецифический для нас, а полезный для всех остальных (но и,
>  AT> конечно, для нас тоже).  Это я называю "стратегической
>  AT> разработкой", как некий показатель успеха вообще, а не в частности.
> 
> Ты упускаешь одну категорию "всех остальных" - остальные разработчики
> дистрибутивов. Как для этой категории уже имеющиеся наработки Сизифа
> могут быть востребованы.

Апстримам от нас ничего на нужно.
И это очень хорошо.  Это сейчас не время для надувания щёк.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Twas brillig at 20:25:08 30.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Давайте оставим в покое RPM (если это имеется в виду).

Нет, я не про RPM. Я про призыв "давайте разбираться, исправлять и
улучшать" вообще. Если не сопровождать это жирным предупреждением "и
делать это через коммуникацию с апстримом", то, воспринятый всерьёз,
такой призыв неизбежно ведёт к скрытому форку.

Если альт - не апстрим, конечно (кажется, такое когда-то было с wdm?)

 >> Ты упускаешь одну категорию "всех остальных" - остальные
 >> разработчики дистрибутивов. Как для этой категории уже имеющиеся
 >> наработки Сизифа могут быть востребованы.

 AT> Апстримам от нас ничего на нужно.  И это очень хорошо.  Это сейчас
 AT> не время для надувания щёк.

Не совсем понимаю, про что это.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Tue, Dec 30, 2008 at 08:25:08PM +0300, Alexey Tourbin wrote:
> Человек есть нечто, что должно превзойти.  Люди развиваются,
> они проходят путь от поверхностного ознакомления к более
> глубокому пониманию, это нормальный ницшеанский взгляд.

Ницше помер довольно неприятным образом, что обычно характеризует
не-ориентиры.

> Хороший мейнтейнер может стать upstream-разработчиком.

Да он может им и быть, только хороший админ может стать
не менее хорошим майнтейнером поверх уже хорошего апстрима.

> Апстримам от нас ничего на нужно.

Прям так всем оптом?  Мне вот на последнюю пачку патчей
(в том числе и тривиальных, типа ++-ных фиксов для gcc43) 
потихоньку накапало ответов "спасибо, приложено".

Не то чтобы это было _нужно_, но оказывается полезно.
Мы можем не только у себя молча чинить, а и людям помогать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] майнтейнеры бывают разные *и это нормально*

[Alexey Morozov]

On Tuesday 30 December 2008 21:53:04 Mikhail Gusarov wrote:
> Впрочем, upstream-разработка в альте тоже есть, только она почему-то
> таковой не считается: альтовый вариант RPM и всю git-related машинерию
> по пакетированию вполне можно считать upstream'ом.
Есть только одна проблема со всем этим: отсутствие чего-то действительно 
важного (например, желания, хотя вероятно, не только желания) делать эти 
разработки апстримом, двигать их, как апстрим. В результате, мы имеем кучу 
наработок, потенциально интересных всему линуксовому сообществу, но по факту 
нишевых и совершенно неизвестных никому, кроме узкого круга посвящённых. А 
остальные вендоры, тем временем, тоже решают с разной степенью успеха 
аналогичные задачи, и, если честно, их решения, просто в силу масштаба, 
оказываются более жизнеспособными (заметь, я не сказал "совершенными" или 
даже "технологически более удачными").

Отсюда есть, пожалуй, только один более-менее приемлемый выход, на мой взгляд: 
организация и всяческая популяризация [англоязычного] "форума вендоров". 
Никаких нафиг "стандартизаций", все эти "юнайтедлинукзы" и прочие выкидыши 
маркетологов заранее обречены, а вот по преимуществу инженерный форум с четко 
выделенными подсекциями и опубликованными и документированными решениями 
четко сформулированных задач может и сработать. Типа, www.freedistro.org, 
гы-гы. Я, конечно, понимаю, NIH синдром у нас развит необычайно, но вдруг 
получится :) Одним из ключевым факторов успеха, насколько я понимаю, здесь 
будут личные знакомства персон, отвечающих за то или иное направление в 
дистрибутиве.

> То, что большая часть альтовой upstream-разработки относится к
> пакетированию, может сбивать с толку, но только на первый взгляд.
Ну, нет, не только :-) Есть еще, насколько я понимаю, сильно ненулевая работа 
по предоставлению "решений", проблема только в том, что дождаться "следующей 
версии" какого-либо специализированного решения подчас оказывается не просто.

С уважением,
Алексей Морозов

Re: [devel] [JT] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Wed, Dec 31, 2008 at 10:30:04AM +0600, Alexey Morozov wrote:
> > Впрочем, upstream-разработка в альте тоже есть, только она
> > почему-то таковой не считается: альтовый вариант RPM и всю
> > git-related машинерию по пакетированию вполне можно считать
> > upstream'ом.
> Есть только одна проблема со всем этим: отсутствие чего-то
> действительно важного (например, желания, хотя вероятно, не
> только желания) делать эти разработки апстримом, двигать их,
> как апстрим. В результате, мы имеем кучу наработок,
> потенциально интересных всему линуксовому сообществу, но по
> факту нишевых и совершенно неизвестных никому, кроме узкого
> круга посвящённых.

Да; это вопрос PR.

> Отсюда есть, пожалуй, только один более-менее приемлемый выход,
> на мой взгляд: организация и всяческая популяризация
> [англоязычного] "форума вендоров". 

Не хочешь в xvendor@ сходить? ;-)  Толку скорее всего получится
как обычно, но откуда ж масло будет, если не барахтаться...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Tuesday, 30 December 2008 17:53:04 Mikhail Gusarov wrote:
> Twas brillig at 18:47:22 30.12.2008 UTC+03 when at@altlinux.ru did gyre and
> gimble:
>
>  AT> У нас нет глубокой подводной части айсберга, как у Редхата, то есть
>  AT> у нас мало стратегической разработки на уровне апстримов.  Думаю
>  AT> однако что камень нужно двигать именно в ту сторону (а не только
>  AT> заниматься вылизыванием пакетов на уровне перепаковки).
>
> А зачем связывать две вещи: пакетирование и upstream-разработку? Их
> можно и нужно явно декларировать как отдельные деятельности.
>
> Впрочем, upstream-разработка в альте тоже есть, только она почему-то
> таковой не считается: альтовый вариант RPM

Обычно это называют сепаратизмом. Но, иногда, этот "неудобный" термин 
подменяют (как в случае с ALT-RPM).

> и всю git-related машинерию 
> по пакетированию вполне можно считать upstream'ом. То, что большая часть
> альтовой upstream-разработки относится к пакетированию, может сбивать с
> толку, но только на первый взгляд.



-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]


Twas brillig at 15:37:25 07.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Впрочем, upstream-разработка в альте тоже есть, только она почему-то
 >> таковой не считается: альтовый вариант RPM

 L> Обычно это называют сепаратизмом. Но, иногда, этот "неудобный"
 L> термин подменяют (как в случае с ALT-RPM).

У RPM долго отсутствовал апстрим как таковой, так что теперь можно
говорить о "семействе пакетных менеджеров RPM", с десятком
представителей этого семейства.

В случае же наличия вменяемого апстрима это и вправду называется
сепаратизмом.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Tue, Dec 30, 2008 at 06:47:22PM +0300, Alexey Tourbin wrote:
> Но у нас-то это декларируется как самостоятельная разработка,
> люди надувают щеки, речь идёт чуть ли не там о какой-то
> национальной операционной системе.  И, между прочем, о
> поддержке.  А оказывается, что это люди всего лишь
> перепаковывают тарболлы.  Much ado about nothing.

Гораздо хуже: они всего лишь циферки с места на место
перекладывают.  И воображают, что жутко заняты. :)

> Не все, конечно.

Ну так и не надо проблемы "не всех" переносить на всех.

> У нас нет глубокой подводной части айсберга, как у Редхата, то
> есть у нас мало стратегической разработки на уровне апстримов.
> Думаю однако что камень нужно двигать именно в ту сторону (а не
> только заниматься вылизыванием пакетов на уровне перепаковки).

Вот именно.  Ты же машешь флагом в строго противоположную
сторону, а я ума не приложу, какой в том смысл.

Хорошо бы нам порой устраивать забрасывание апстримов патчами
(не забывая о том, что это не только время на подготовку и
отправку, а ещё потенциально изрядно возни по объяснению --
но зато меньше мороки на сопровождение в дальнейшем).

> > И да, мне уже поднадоело повторять это.
> Мне кажется, что ты сдвигаешь понятия (проводя аналогию между
> учеными и инженерами).  Ученые тут должны заниматься языками
> программирования, типа haskell, там deforestation,
> преобразования кода, сохраняющие эквивалентность.
> Ученым есть чем заняться помимо существующего кода.  С большим
> прибором.  А разбираться в коде это всё-таки компетенция
> инженеров.

Это ещё этажом выше, можно и продолжить -- "учёные должны
заниматься архитектурами и методологиями" ;-)

Смысл сравнения -- в том, что одним "потому что мысль",
а другие толстые.  При этом право на такой выбор и на
существование имеют и те, и другие.

Код -- не самоцель, думается.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]

On Wed, Dec 31, 2008 at 10:39:20PM +0200, Michael Shigorin wrote:
> On Tue, Dec 30, 2008 at 06:47:22PM +0300, Alexey Tourbin wrote:
> > Но у нас-то это декларируется как самостоятельная разработка,
> > люди надувают щеки, речь идёт чуть ли не там о какой-то
> > национальной операционной системе.  И, между прочем, о
> > поддержке.  А оказывается, что это люди всего лишь
> > перепаковывают тарболлы.  Much ado about nothing.
> 
> Гораздо хуже: они всего лишь циферки с места на место
> перекладывают.  И воображают, что жутко заняты. :)
> 
> > Не все, конечно.
> 
> Ну так и не надо проблемы "не всех" переносить на всех.

So, what's the problem?  Проблема, будто бы, в том, что мы хотим
взвалить на себя самостоятельную разработку.  А это оказывается тяжело
и неинтересно, а легко и интересно чтобы всё само работало.   А мы
значит такие барчуки сидим и переправляем цифирки на новые апстримовские
версии.

Куда ведёт этот бизнес перепаковки тарболлов?
Иногда кажется что "починить пакет" это помогает.
Но на самом деле это никуда не ведёт.

> > У нас нет глубокой подводной части айсберга, как у Редхата, то
> > есть у нас мало стратегической разработки на уровне апстримов.
> > Думаю однако что камень нужно двигать именно в ту сторону (а не
> > только заниматься вылизыванием пакетов на уровне перепаковки).
> 
> Вот именно.  Ты же машешь флагом в строго противоположную
> сторону, а я ума не приложу, какой в том смысл.

В принципе всё в наших руках.  Мы можем что-то делать, или хотя
бы что-то декларировать.  Например, мы можем декларировать
самостоятельную разработку, или же мы можем декларировать перепаковку
тарболлов.  В этом смысле нет пространства для спора.  Как скажем так
и будет.

Мне хотелось бы декларировать самостоятельную разработку, подключать
умных людей, которые разбираются в коде, которые способны исправлять
код.  Какая тут может быть альтернатива?  Люди, которые скачивают
тарболлы.  Абсолютно честно, никакого мошенничества.  Вчера скачал
сегодня залил.

> Хорошо бы нам порой устраивать забрасывание апстримов патчами
> (не забывая о том, что это не только время на подготовку и
> отправку, а ещё потенциально изрядно возни по объяснению --
> но зато меньше мороки на сопровождение в дальнейшем).
> 
> > > И да, мне уже поднадоело повторять это.
> > Мне кажется, что ты сдвигаешь понятия (проводя аналогию между
> > учеными и инженерами).  Ученые тут должны заниматься языками
> > программирования, типа haskell, там deforestation,
> > преобразования кода, сохраняющие эквивалентность.
> > Ученым есть чем заняться помимо существующего кода.  С большим
> > прибором.  А разбираться в коде это всё-таки компетенция
> > инженеров.
> 
> Это ещё этажом выше, можно и продолжить -- "учёные должны
> заниматься архитектурами и методологиями" ;-)

Твоя аналогия плоха тем, что ты хочешь исключить рациональную
деятельность, потому что она слишком сложная.  Надо в чем-то
разбираться, а мы не разбираемся.  Тогда надо отнести эту деятельность
к катеории "ученых".  Мол там есть какой-то загон в чем-то разбираться,
а мы не дураки, мы катаемся задарма.

> Смысл сравнения -- в том, что одним "потому что мысль",
> а другие толстые.  При этом право на такой выбор и на
> существование имеют и те, и другие.
> 
> Код -- не самоцель, думается.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Thu, Jan 01, 2009 at 03:13:11AM +0300, Алексей Турбин wrote:

AT> Куда ведёт этот бизнес перепаковки тарболлов?
AT> Иногда кажется что "починить пакет" это помогает.
AT> Но на самом деле это никуда не ведёт.

Открою страшную тайну. Только никому не говори.

Вообще-то программирование -- не нужно. Это не цель, а одно из
многих-многих средств достичь требуемого результата.

У меня есть _задача_, и мне надо ее решить. И мне, в общем-то, все равно
-- будет ли она решена даже с помощью компьютера, а не печатной машинки и
деревянных счет.

Меня интересует только количество ресурсов которые нужно затратить чтобы
получить нужный результат.

И меня лично мало волнует квалификация мантейнера. Мне нужны работающие
пакеты. А требовать чтобы в team были только хакеры -- глупо. Просто те
пакеты которые требуют сопровождения хакером -- должны сопровождаться
хакером. 

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Thu, Jan 01, 2009 at 03:13:11AM +0300, Alexey Tourbin wrote:
> > > Не все, конечно.
> > Ну так и не надо проблемы "не всех" переносить на всех.
> So, what's the problem?

(in a voice of an authentic Shrek, green one)
I ain't got no problems!

> Проблема, будто бы, в том, что мы хотим взвалить на себя
> самостоятельную разработку.  А это оказывается тяжело и
> неинтересно, а легко и интересно чтобы всё само работало.

Мало того, это ещё и бывает бессмысленно -- если мощным рашпилем
плодить форки и не работать над воспитанием апстримов.  Для чего
требуется быть не только крутым хакером, но ещё и терпеливым
преподавателем.

> А мы значит такие барчуки сидим и переправляем цифирки на новые
> апстримовские версии.

Это нормально для дистрибутива, как тебе уже не один человек
пытается объяснить.  Разработка софта -- _отдельная_ задача.
А доработка -- на стыке, но надо понимать, что это не может быть
_требованием_ к майнтейнеру.

> Куда ведёт этот бизнес перепаковки тарболлов?
> Иногда кажется что "починить пакет" это помогает.
> Но на самом деле это никуда не ведёт.

Ведёт к тому, что в спеках фиксируется опыт сборки и интеграции
этих самых тарболов.  Возможно, ты пользуешься аж одним хостом --
когда их десятки, разница ощущается довольно резко.

> Мне хотелось бы декларировать самостоятельную разработку,
> подключать умных людей, которые разбираются в коде, которые
> способны исправлять код.  Какая тут может быть альтернатива?

Нуу... не {декларировать,подключать} и вообще сидеть сиднем,
например.

> Люди, которые скачивают тарболлы.  Абсолютно честно, никакого
> мошенничества.  Вчера скачал сегодня залил.

Ага.  Скажем, в тарболе memtest86+ мне делать нечего (если тебе
есть чего -- помоги им переехать с gcc 4.1 на 4.3 какой).  Зато
один из наших пользователей не раз подбрасывал патчи.

Некоторым интересней выращивать красивые помидоры, некоторым
-- укладывать их в ящики ровными рядами, чтоб не помялись.
Иным -- нарезать в салат.  Иным -- просто есть этот салат.
Ну, разные люди.  Не стоит их вот так заочно всех.

> > Хорошо бы нам порой устраивать забрасывание апстримов патчами

Кстати: кто-то может подсказать, куда сейчас на irda-utils патчи
слать?  SF tracker у них не разгребается совсем, а davem@ письму
удивился.

> > Это ещё этажом выше, можно и продолжить -- "учёные должны
> > заниматься архитектурами и методологиями" ;-)
> Твоя аналогия плоха тем, что ты хочешь исключить рациональную
> деятельность, потому что она слишком сложная.

Отнюдь.  Есть разные сложности, и ты вполне это сам понимаешь.

Из сегодняшнего: делать фигурные коньки и закладывать на них
виражи -- совсем разные сложности, хоть и тесно связанные.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Aleksey Novodvorsky]

1 января 2009 г. 19:55 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Thu, Jan 01, 2009 at 03:13:11AM +0300, Alexey Tourbin wrote:
>> > > Не все, конечно.
>> > Ну так и не надо проблемы "не всех" переносить на всех.
>> So, what's the problem?
>
> (in a voice of an authentic Shrek, green one)
> I ain't got no problems!
>
>> Проблема, будто бы, в том, что мы хотим взвалить на себя
>> самостоятельную разработку.  А это оказывается тяжело и
>> неинтересно, а легко и интересно чтобы всё само работало.
>
> Мало того, это ещё и бывает бессмысленно -- если мощным рашпилем
> плодить форки и не работать над воспитанием апстримов.  Для чего
> требуется быть не только крутым хакером, но ещё и терпеливым
> преподавателем.
>
>> А мы значит такие барчуки сидим и переправляем цифирки на новые
>> апстримовские версии.
>
> Это нормально для дистрибутива, как тебе уже не один человек
> пытается объяснить.  Разработка софта -- _отдельная_ задача.
> А доработка -- на стыке, но надо понимать, что это не может быть
> _требованием_ к майнтейнеру.

Я полагаю, что для любого менйтейнера необходимо по крайней мере:
1. Уметь собрать пакет в соответствии с нашими policy, для чего часто
необходимы патчи.
2. Уметь настраивать приложения своего пакета и положить настройки в пакет.
3. Уметь исправить и дополнить перевод, отправить его в апстрим.
То есть это уже не совсем админская работа, так как пакет делается не
только для себя.
Я полагаю, что 1 должно проверяться при приеме в тим. 2 есть обычная
админская работа. 3 -- не сложно, но надо этому учить.
Думаю, что человек, овладевший 1-3, весьма часто начинает и более
существенно дорабатывать пакет, все же общение здесь не проходит
даром.

Rgrds, Алексей

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Thu, Jan 01, 2009 at 08:10:44PM +0300, Aleksey Novodvorsky wrote:
> Я полагаю, что для любого менйтейнера необходимо по крайней мере:
> 1. Уметь собрать пакет в соответствии с нашими policy, для чего
> часто необходимы патчи.
[...]
> Я полагаю, что 1 должно проверяться при приеме в тим.

Вот я лично вижу в этом перекос, хотя настаивать не буду.

До сих пор ровно один раз видел тестовое задание, выправленное
блестяще и с первого захода -- обычно вместе читаем вики и
разбираемся, что ещё не так.  И честно говоря, я бы предпочёл
этого не делать -- потому как не все пакеты требуют патчей,
есть и приличные.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Denis Klimov]

Michael Shigorin пишет:
> On Thu, Jan 01, 2009 at 08:10:44PM +0300, Aleksey Novodvorsky wrote:
>   
>> Я полагаю, что для любого менйтейнера необходимо по крайней мере:
>> 1. Уметь собрать пакет в соответствии с нашими policy, для чего
>> часто необходимы патчи.
>>     
> [...]
>   
>> Я полагаю, что 1 должно проверяться при приеме в тим.
>>     
>
> Вот я лично вижу в этом перекос, хотя настаивать не буду.
>
> До сих пор ровно один раз видел тестовое задание, выправленное
> блестяще и с первого захода -- обычно вместе читаем вики и
> разбираемся, что ещё не так.  И честно говоря, я бы предпочёл
> этого не делать -- потому как не все пакеты требуют патчей,
> есть и приличные
Интересно, кто выполнил это тестовое задание?

--
zver

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Thu, Jan 01, 2009 at 11:14:18PM +0500, Denis Klimov wrote:
> >До сих пор ровно один раз видел тестовое задание, выправленное
> >блестяще и с первого захода
> Интересно, кто выполнил это тестовое задание?

Сейчас уже не помню, хотя несколько раз порывался перерыть
архив и найти.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Thursday, 01 January 2009 20:14:18 Denis Klimov wrote:
> Michael Shigorin пишет:
> > On Thu, Jan 01, 2009 at 08:10:44PM +0300, Aleksey Novodvorsky wrote:
> >> Я полагаю, что для любого менйтейнера необходимо по крайней мере:
> >> 1. Уметь собрать пакет в соответствии с нашими policy, для чего
> >> часто необходимы патчи.
> >
> > [...]
> >
> >> Я полагаю, что 1 должно проверяться при приеме в тим.
> >
> > Вот я лично вижу в этом перекос, хотя настаивать не буду.
> >
> > До сих пор ровно один раз видел тестовое задание, выправленное
> > блестяще и с первого захода -- обычно вместе читаем вики и
> > разбираемся, что ещё не так.  И честно говоря, я бы предпочёл
> > этого не делать -- потому как не все пакеты требуют патчей,
> > есть и приличные
>
> Интересно, кто выполнил это тестовое задание?

А что - сейчас уже никто не выполняет? Т.е. для того, чтобы быть мейнтейнером 
уже необязательно уметь паковать пакеты и знать такие "страшные слова" 
как "rpm", "spec" и т.п.?

-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]


Twas brillig at 16:13:57 07.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> А что - сейчас уже никто не выполняет? Т.е. для того, чтобы быть
 L> мейнтейнером уже необязательно уметь паковать пакеты и знать такие
 L> "страшные слова" как "rpm", "spec" и т.п.?

Наоборот. Буквально неделю назад введена практика обязательной практики
под руководством желающих из team, и последующего [не]принятия (с
выдачей прав на аплоад в Сизиф) по результатам.

Т.е. желающий попасть в team получает email и доступ к git.alt, но пока
его наставник не скажет "да, он нормально собирает пакеты, овладел git
etc", не может аплоадить пакеты в Сизиф. В этот промежуток времени
пакеты ученика аплоадит наставник самостоятельно, руководствуюясь своими
критериями качества.

Таким образом получается избавиться от тестовых заданий (eыглядящих
достаточно искусственно), и при этом минимально обучить новичков, в том
числе и навыкам совместной разработки.

Кстати, если кто-то хочет выступать таким наставником - напишите inger'у
и мне. Большой коммуникационный bandiwith не нужен - достаточно просто
review'ить подготовленные пакеты и давать ссылки на документацию, но
желателен маленький latency (< 1 дня, желателен софт-реалтайм).

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Wednesday, 07 January 2009 16:24:17 Mikhail Gusarov wrote:
> Twas brillig at 16:13:57 07.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> А что - сейчас уже никто не выполняет? Т.е. для того, чтобы быть
>  L> мейнтейнером уже необязательно уметь паковать пакеты и знать такие
>  L> "страшные слова" как "rpm", "spec" и т.п.?
>
> Наоборот. Буквально неделю назад введена практика обязательной практики
> под руководством желающих из team, и последующего [не]принятия (с
> выдачей прав на аплоад в Сизиф) по результатам.
>
> Т.е. желающий попасть в team получает email и доступ к git.alt, но пока
> его наставник не скажет "да, он нормально собирает пакеты, овладел git
> etc", не может аплоадить пакеты в Сизиф. В этот промежуток времени
> пакеты ученика аплоадит наставник самостоятельно, руководствуюясь своими
> критериями качества.
>
> Таким образом получается избавиться от тестовых заданий (eыглядящих
> достаточно искусственно), и при этом минимально обучить новичков, в том
> числе и навыкам совместной разработки.
+1. ИМХО лучше тестироваться на пакетах, которые "новичку" лично 
непосредственно интересны.

>
> Кстати, если кто-то хочет выступать таким наставником - напишите inger'у
> и мне. Большой коммуникационный bandiwith не нужен - достаточно просто
> review'ить подготовленные пакеты и давать ссылки на документацию, но
> желателен маленький latency (< 1 дня, желателен софт-реалтайм).

А вот из-за таких жёстких рамок лично я и не могу "поучавствовать". При том, 
что, наверное, такие рамки оправданы.

-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Slava Semushin]

8 января 2009 г. 0:54 пользователь Led <ledest@gmail> написал:
[...]
>> Кстати, если кто-то хочет выступать таким наставником - напишите inger'у
>> и мне. Большой коммуникационный bandiwith не нужен - достаточно просто
>> review'ить подготовленные пакеты и давать ссылки на документацию, но
>> желателен маленький latency (< 1 дня, желателен софт-реалтайм).
>
> А вот из-за таких жёстких рамок лично я и не могу "поучавствовать".

+1


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Wed, Jan 07, 2009 at 08:54:34PM +0200, Led wrote:
> > Таким образом получается избавиться от тестовых заданий
> > (eыглядящих достаточно искусственно), и при этом минимально
> > обучить новичков, в том числе и навыкам совместной
> > разработки.
> +1. ИМХО лучше тестироваться на пакетах, которые "новичку"
> лично непосредственно интересны.

Ага.

> > Кстати, если кто-то хочет выступать таким наставником -
> > напишите inger'у и мне. Большой коммуникационный bandiwith не
> > нужен - достаточно просто review'ить подготовленные пакеты и
> > давать ссылки на документацию, но желателен маленький latency
> > (< 1 дня, желателен софт-реалтайм).
> А вот из-за таких жёстких рамок лично я и не могу
> "поучавствовать". При том, что, наверное, такие рамки
> оправданы.

Мои рамки обычно от "прямщас" до "неделя", с горбом где-то
в районе дня-трёх.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Stanislav Ievlev]

On Wed, Jan 07, 2009 at 08:24:17PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 16:13:57 07.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:
> 
>  L> А что - сейчас уже никто не выполняет? Т.е. для того, чтобы быть
>  L> мейнтейнером уже необязательно уметь паковать пакеты и знать такие
>  L> "страшные слова" как "rpm", "spec" и т.п.?
> 
> Наоборот. Буквально неделю назад введена практика обязательной практики
> под руководством желающих из team, и последующего [не]принятия (с
> выдачей прав на аплоад в Сизиф) по результатам.
> 
> Т.е. желающий попасть в team получает email и доступ к git.alt, но пока
> его наставник не скажет "да, он нормально собирает пакеты, овладел git
> etc", не может аплоадить пакеты в Сизиф. В этот промежуток времени
> пакеты ученика аплоадит наставник самостоятельно, руководствуюясь своими
> критериями качества.
> 
> Таким образом получается избавиться от тестовых заданий (eыглядящих
> достаточно искусственно), и при этом минимально обучить новичков, в том
> числе и навыкам совместной разработки.
Дима уже сделал всё что нужно для этого?
Нужно ещё определиться на какой мне менять статус баги когда я
зарегистрировал участника - это ведь получается не resolved/fixed, а нечто
промежуточное?

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]


Twas brillig at 12:13:51 11.01.2009 UTC+03 when inger@altlinux.org did gyre and gimble:

 SI> Дима уже сделал всё что нужно для этого?

Техподдержка здесь приятна, но не обязательна.

 SI> Нужно ещё определиться на какой мне менять статус баги когда я
 SI> зарегистрировал участника - это ведь получается не resolved/fixed,
 SI> а нечто промежуточное?

А это ты можешь сам придумать, как тебе удобнее. Keyword, скажем,
повешать.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Ivan A. Melnikov]

On Sun, 11 Jan 2009 12:13:51 +0300
Stanislav Ievlev <inger@altlinux.org> wrote:
[...]
> Нужно ещё определиться на какой мне менять статус баги когда я
> зарегистрировал участника - это ведь получается не resolved/fixed, а
> нечто промежуточное?

ACCEPTED?

-- 
Best Regards,
Ivan A. Melnikov

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Michael Shigorin]

On Thu, Jan 01, 2009 at 07:38:50PM +0200, I wrote:
> On Thu, Jan 01, 2009 at 08:10:44PM +0300, Aleksey Novodvorsky wrote:
> > Я полагаю, что для любого менйтейнера необходимо по крайней мере:
> > 1. Уметь собрать пакет в соответствии с нашими policy, для чего
> > часто необходимы патчи.
> [...]
> > Я полагаю, что 1 должно проверяться при приеме в тим.
> Вот я лично вижу в этом перекос, хотя настаивать не буду.

Дополню мысль: это неплохо поясняет, почему в ALT плохо с updates
-- девелоперам они не нужны, у них есть unstable.  А с админами
происходит странное: инфраструктура хороша, но людей системно
распугивают.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Andrii Dobrovol`s`kii]

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]

Aleksey Novodvorsky пишет:
Рискну встрять с таким большим опозданием (праздники...), т.к. не
увидел дальше аналогичных комментариев, а считаю их существенными.
> Я полагаю, что для любого менйтейнера необходимо по крайней мере:
> 1. Уметь собрать пакет в соответствии с нашими policy, для чего часто
> необходимы патчи.
Часто, но не всегда (это уже отметили другие). Но, главное, хорошо
чтоб эти патчи делал сам смотритель пакета, однако, не обязательно.
Он может попросить о помощи окружающих и постепенно научится, если
это будет достаточно часто необходимо.
> 2. Уметь настраивать приложения своего пакета и положить настройки в пакет.
Тоже нужно не всегда и может быть частично сделано кем-то ещё или с
чьей-то помощью. Если это реально нужно.
> 3. Уметь исправить и дополнить перевод, отправить его в апстрим.
И тут тоже можно обратиться к другим членам сообщества. Это и будет
командная работа, ИМХО.
И вполне возможно, что из таких мини-команд вырастет много хороших
смотрителей-универсалов. А если и нет, не беда. Пакеты-то будут...
> То есть это уже не совсем админская работа, так как пакет делается не
> только для себя.
В описанном объеме это и правда уже не админская работа. Это
требования к упаковщику универсалу способному работать без коллег и
тяготеющему к собственно разработке. Иметь таких людей в команде
очень хорошо. Надеяться, что все будут такими не стоит. Или команда
окажется очень небольшой...
> Я полагаю, что 1 должно проверяться при приеме в тим. 2 есть обычная
> админская работа. 3 -- не сложно, но надо этому учить.
> Думаю, что человек, овладевший 1-3, весьма часто начинает и более
> существенно дорабатывать пакет, все же общение здесь не проходит
> даром.
Человек отвечающий всем критериям начинает дорабатывать уже не пакет
-- то что в него завернуто. Это отлично. Всегда ли обязательно?
> 
> Rgrds, Алексей
-- 
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 --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Aleksey Novodvorsky]

12 января 2009 г. 18:46 пользователь Andrii Dobrovol`s`kii
<dobr@iop.kiev.ua> написал:
> Aleksey Novodvorsky пишет:
> Рискну встрять с таким большим опозданием (праздники...), т.к. не
> увидел дальше аналогичных комментариев, а считаю их существенными.
>> Я полагаю, что для любого менйтейнера необходимо по крайней мере:
>> 1. Уметь собрать пакет в соответствии с нашими policy, для чего часто
>> необходимы патчи.
> Часто, но не всегда (это уже отметили другие). Но, главное, хорошо
> чтоб эти патчи делал сам смотритель пакета, однако, не обязательно.
> Он может попросить о помощи окружающих и постепенно научится, если
> это будет достаточно часто необходимо.

Он может попросить, но не всегда сможет найти желающих ему помочь. И
не потому, что люди вокруг злые, а потому, например, что им не нужен
и/или не нравится  этот пакет.

>> 2. Уметь настраивать приложения своего пакета и положить настройки в пакет.
> Тоже нужно не всегда и может быть частично сделано кем-то ещё или с
> чьей-то помощью. Если это реально нужно.

См. выше..

>> 3. Уметь исправить и дополнить перевод, отправить его в апстрим.
> И тут тоже можно обратиться к другим членам сообщества. Это и будет
> командная работа, ИМХО.

Да.

> И вполне возможно, что из таких мини-команд вырастет много хороших
> смотрителей-универсалов. А если и нет, не беда. Пакеты-то будут...

Могут и не быть или быть неработающими. И уж почти наверняка --
неподдерживаемыми. В результате будет видимость наличия пакета. Нужно
ли это?

>> То есть это уже не совсем админская работа, так как пакет делается не
>> только для себя.
> В описанном объеме это и правда уже не админская работа. Это
> требования к упаковщику универсалу способному работать без коллег и
> тяготеющему к собственно разработке. Иметь таких людей в команде
> очень хорошо. Надеяться, что все будут такими не стоит. Или команда
> окажется очень небольшой...

Новый процесс приема в тим включает  период  обучения. Но вот для
того, чтобы войти в команду, нужна самостоятельность.

>> Я полагаю, что 1 должно проверяться при приеме в тим. 2 есть обычная
>> админская работа. 3 -- не сложно, но надо этому учить.
>> Думаю, что человек, овладевший 1-3, весьма часто начинает и более
>> существенно дорабатывать пакет, все же общение здесь не проходит
>> даром.

Согласен. Не нашел  у нас заметных расхождений. :-)
> Человек отвечающий всем критериям начинает дорабатывать уже не пакет
> -- то что в него завернуто. Это отлично. Всегда ли обязательно?

Возможно, стоит взять пакет попроще. Может быть, сразу и не будем
писать патчи. Но проерить присланный со стороны патч -- нужно?
Rgrds, Алексей
> --
> 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************************
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Andrii Dobrovol`s`kii]

[-- 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 --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Tuesday 13 January 2009 14:49:12 Andrii Dobrovol`s`kii wrote:
> >>> 2. Уметь настраивать приложения своего пакета и положить настройки в
> >>> пакет.
> >>
> >> Тоже нужно не всегда и может быть частично сделано кем-то ещё или с
> >> чьей-то помощью. Если это реально нужно.
> >
> > См. выше..
>
> Снова согласен. Но, ведь настройку может выполнить тот кто им
> пользуется уже после установки. Автоматизация это хорошо но не
> необходимо. Ведь так?

В данном случае - нет, не так. Так создастся ложное ощущение, что софтина 
адаптировано для репозитария и готова к использованию, а на самом деле - 
только перепакована из tar.gz в rpm.

-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Tue, Jan 13, 2009 at 03:56:43PM +0200, Led wrote:

L> В данном случае - нет, не так. Так создастся ложное ощущение, что софтина 
L> адаптировано для репозитария и готова к использованию, а на самом деле - 
L> только перепакована из tar.gz в rpm.

Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто ли
он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
можно было :)

Ну нельзя одинаковые требования по качеству упаковки предъявлять к тетрису
и openssh, например. Просто потому, что если есть лишние силы на
гениальную упаковку тетриса -- лучше их направить в более полезное русло
(например на список незакрытых багов в багтрекере).

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Tuesday 13 January 2009 17:38:56 Денис Смирнов wrote:
> On Tue, Jan 13, 2009 at 03:56:43PM +0200, Led wrote:
>
> L> В данном случае - нет, не так. Так создастся ложное ощущение, что
> софтина L> адаптировано для репозитария и готова к использованию, а на
> самом деле - L> только перепакована из tar.gz в rpm.
>
> Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто ли
> он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
> можно было :)
>
> Ну нельзя одинаковые требования по качеству упаковки предъявлять к тетрису
> и openssh, например. Просто потому, что если есть лишние силы на
> гениальную упаковку тетриса -- лучше их направить в более полезное русло
> (например на список незакрытых багов в багтрекере).

Смотрите контекст (что подразумевается под "данным случаем").

-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

* Денис Смирнов <mithraen@> [090113 18:44]:
> Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто ли
> он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
> можно было :)
Как определить, foo - это "тетрис" или "openssh"?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Tuesday 13 January 2009 18:08:07 Alexey I. Froloff wrote:
> * Денис Смирнов <mithraen@> [090113 18:44]:
> > Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто
> > ли он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
> > можно было :)
>
> Как определить, foo - это "тетрис" или "openssh"?

Да и какой толк от "тетриса", если это всего-лишь перепакованный тарболл, И, 
после установки, он требует ещё ручной настройки (кстати, откуда это узнать?) 
для того, чтобы просто его запустить?

-- 
Led

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, Jan 13, 2009 at 06:10:34PM +0200, Led wrote:

L> Да и какой толк от "тетриса", если это всего-лишь перепакованный тарболл, И, 
L> после установки, он требует ещё ручной настройки (кстати, откуда это узнать?) 
L> для того, чтобы просто его запустить?

Большинство "тетрисов" после простой перепаковки тарбола будут просто
работать.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On Tue, Jan 13, 2009 at 07:08:07PM +0300, Alexey I. Froloff wrote:
> * Денис Смирнов <mithraen@> [090113 18:44]:
> > Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто ли
> > он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
> > можно было :)
> Как определить, foo - это "тетрис" или "openssh"?

По багзилле?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Tue, Jan 13, 2009 at 07:08:07PM +0300, Alexey I. Froloff wrote:

>> Если речь идет о каком-нибудь тетрисе -- мне абсолютно все равно просто ли
>> он перепакован, или мантейнер 90% кода переписал сам. Лишь бы играться
>> можно было :)
AIF> Как определить, foo - это "тетрис" или "openssh"?

foo:
- получает внешние IP-соединения;
- выплоняется от привелегированого пользователя;
- не предназначено для развлечения и может быть необходима для
  использовании на серверах или рабочих машинах
  -> openssh

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Andrii Dobrovol`s`kii]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Led пишет:
> On Tuesday 13 January 2009 14:49:12 Andrii Dobrovol`s`kii wrote:
>>>>> 2. Уметь настраивать приложения своего пакета и положить настройки в
>>>>> пакет.
>>>> Тоже нужно не всегда и может быть частично сделано кем-то ещё или с
>>>> чьей-то помощью. Если это реально нужно.
>>> См. выше..
>> Снова согласен. Но, ведь настройку может выполнить тот кто им
>> пользуется уже после установки. Автоматизация это хорошо но не
>> необходимо. Ведь так?
> 
> В данном случае - нет, не так. Так создастся ложное ощущение, что софтина 
> адаптировано для репозитария и готова к использованию, а на самом деле - 
> только перепакована из tar.gz в rpm.
> 
Она не только перепакованна. Она гарантированно запускается на
пакетной базе хранилища и работает минимум у заворачивавшего. Иначе
зачем отправлять пакет в хранилище? А относительно настройки давайте
тогда определим понятия.
Что Вы вкладываете в понятие "настроена" и какие настройки
обязятельно нужно класть в любой пакет?
-- 
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 --]

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Wartan Hachaturow]

2009/1/1 Alexey Tourbin <at@altlinux.ru>:

> Мне хотелось бы декларировать самостоятельную разработку, подключать
> умных людей, которые разбираются в коде, которые способны исправлять
> код.  Какая тут может быть альтернатива?  Люди, которые скачивают
> тарболлы.  Абсолютно честно, никакого мошенничества.  Вчера скачал
> сегодня залил.

Люди разные нужны, люди разные важны.
То, что просто работает, исправлять незачем, и достаточно просто
аккуратно запаковать (кстати, что само по себе в случае софтин типа
OO.org или там X.org представляет собой нетривиальную задачу). То, что
не работает, можно либо исправить самому, либо передать баг апстриму,
если сам не умеешь.

Не пойму сути спора.

-- 
Regards, Wartan.

Re: [devel] майнтейнеры бывают разные *и это нормально*

[Led]

On Thursday, 01 January 2009 19:20:04 Wartan Hachaturow wrote:
> 2009/1/1 Alexey Tourbin <at@altlinux.ru>:
> > Мне хотелось бы декларировать самостоятельную разработку, подключать
> > умных людей, которые разбираются в коде, которые способны исправлять
> > код.  Какая тут может быть альтернатива?  Люди, которые скачивают
> > тарболлы.  Абсолютно честно, никакого мошенничества.  Вчера скачал
> > сегодня залил.
>
> Люди разные нужны, люди разные важны.
> То, что просто работает, исправлять незачем, и достаточно просто
> аккуратно запаковать (кстати, что само по себе в случае софтин типа
> OO.org или там X.org представляет собой нетривиальную задачу). То, что
> не работает, можно либо исправить самому, либо передать баг апстриму,
> если сам не умеешь.
>
> Не пойму сути спора.

Суть очень проста: вы произнесли слово "аккуратно" - сейчас кое-кто будет вас 
убеждать, что это не только не нужно, но и вредно:)

-- 
Led

Re: [devel] perl packages

[Michael Shigorin]

On Wed, Dec 17, 2008 at 07:35:12AM +0300, Alexey Tourbin wrote:
> > > Не следует использовать cpan2rpm.
> > Высокомерно.  Я так не считаю.
> Я имел в виду, что не следует автоматически собирать пакеты (вообще).

Почему?

> Она профанирует весь процесс.

Не вижу никакой профанации в переоформлении низкоэнтропийных
репозиториев.  Наоборот -- возможность сохранить время для
исправления и в идеале -- вразумления апстрима [ещё] высоко-.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/