URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 85077
[ Назад ]

Исходное сообщение
"openSUSE на пути к изменению модели разработки"

Отправлено opennews , 15-Июн-12 11:00 
После многократного переноса тестовых версий openSUSE 12.2 стало ясно, что выпустить релиз в срок не удастся и разработчики  выступили (http://news.opensuse.org/2012/06/14/where-is-my-12-2-my-king.../) с  инициативой проведения реорганизации процесса разработки, что по их мнению поможет решить наблюдаемые в настоящее время проблемы с масштабированием организации разработки в условиях растущей пакетной базы.


Стефан Калаф (Stephan Kulow), релиз-менеджер openSUSE, указал (http://lists.opensuse.org/opensuse-factory/2012-06/msg00468....) на то, что текущая модель разработки неэффективна и проекту требуются новые идеи по исправлению сложившейся ситуации. В качестве одного из вариантов, предложенных Сетфаном, называется уход от плановой подготовки новых версий, которые сейчас выпускаются строго раз в 8 месяцев, к модели без жестких планов, основанной на готовности дистрибутива, или к заметному расширению сроков подготовки новых версий, например, переходу к выпуску релизов раз в год.


В качестве мотива такого предложения называется то, что несмотря на приближение даты релиза, наблюдается высокая степень нестабильности в репозитории Factory, в рамках которого ведётся стабилизация пакетов для новых версий openSUSE. Предполагается, что проблемы вызваны быстрым ростом пакетной базы и увеличением числа неподдерживаемых пакетов.  В настоящее время в Factory допускается нахождение слишком большого числа пакетов, которые находятся в неработоспособном состоянии неприемлемо длительное время. Переход системы сборки на GCC 4.7 только усугубляет ситуацию.


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


Что касается подготовки openSUSE 12.2, то для обеспечения полной готовности выпуска вместо планируемого 11 июля, предлагается (http://lists.opensuse.org/opensuse-project/2012-06/msg00141....) перенести релиз на середину сентября. В частности, на следующей неделе предложено выпустить вторую бета-версию, после чего отделить ветку openSUSE:12.2 из Factory для перехода на фазу заморозки, подразумевающую только исправление ошибок. В середине июля планируется подготовить первый кандидат в релизы, а в августе дополнительные тестовые выпуски. В настоящее время данное предложение ещё не утверждено разработчиками, но даже если оно будет отвергнуто, релиз openSUSE 12.2 будет отложен как минимум на две недели.

URL: http://news.opensuse.org/2012/06/14/where-is-my-12-2-my-king.../
Новость: http://www.opennet.me/opennews/art.shtml?num=34108


Содержание

Сообщения в этом обсуждении
"openSUSE на пути к изменению модели разработки"
Отправлено paulus , 15-Июн-12 11:00 
а говорили, что у Дебиана не правильный подход :)

"openSUSE на пути к изменению модели разработки"
Отправлено Anonim , 15-Июн-12 18:11 
> Кто сказал, что в дебиан побегут? Самый ненужный дистрибутив.

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


"openSUSE на пути к изменению модели разработки"
Отправлено ILYA INDIGO , 15-Июн-12 21:01 
Поддерживаю, почти всё верно сказано, только...
там ещё zypper есть - самый удобный и полнофункциональный менеджер пакетов (apt-get,pacman отдыхают)
Очень удобный, на первый взгляд, конфигуратор YaST, причём консольный и новичкам очень удобно в нём конфигурировать, но когда опыта становиться больше, далеко не у всех правда, начинаешь замечать что это убогий неудобный костыль и вручную править конфиги и удобнее и легче, а потом когда смотришь конфиги, понимаешь что он их просто изговнял.
Например при настройке виртуальных хостов в апаче, если через него их настраивать, то он чёрт знает как объеденяет отдельные файлы конфигов в единый файл и групирует по своему...
И так со всем...
Посему для неопытных новичков, каким и был я, это самое оно, но для тех кто по умнее добро пожаловат на Arch.

"openSUSE на пути к изменению модели разработки"
Отправлено Anonim , 15-Июн-12 21:50 
Я тоже был (а может и остаюсь) новичком и даже считал сусю простым удобным дистром с конфигурялками. Это ложное впечатление. Этот дистр сложный, об этом пишут в вики. Надо не только понимать как работает линукс, но еще и уметь пользоваться всеми сусевскими костылями, разбираться в их ошибках и обходить фатальные глюки. Пакеты очень сложные для собирания самому, а в репах нет многих программ. Их система сборки отнюдь процесс не упрощает. Сам дистр стоит в стороне от мейнстрима в виде редхата и ее клонов, пакеты от них подходят далеко не все. Вики недостатоно полное и переведенное.
Обновляется дистр редко. Новых версий программ с каждым месяцем хочется все больше.
Он по идее, похож на идеальный дистр для новичков и массового пользователя (убунта таковым уже не станет, это очевидно). Установка прог в 1 клик - прикольная вещь. Только до юзабильного состояния его все еще не доведут. Может и выкарабкаются.

"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 15-Июн-12 23:51 
> Сам дистр стоит в стороне от мейнстрима в
> виде редхата и ее клонов

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


"openSUSE на пути к изменению модели разработки"
Отправлено 1 , 16-Июн-12 03:50 
Во, сразу видно - звездун, который Арча в глаза не видел.
Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD. Так что про клона РХ - мимо лужи.

"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 16-Июн-12 11:31 
> Во, сразу видно - звездун, который Арча в глаза не видел.
> Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD.
> Так что про клона РХ - мимо лужи.

Да, да. Ссылку в студию. Где вклад LFS, или им все с неба сыпится. Такой себе Рог Изобилия. Взять взятое, это уже называется собственным. И кто тут звездун.
А теперь перечисли, что в Арче от FreeBSD.


"openSUSE на пути к изменению модели разработки"
Отправлено 1 , 16-Июн-12 15:29 
А где я написал, что в Арче что-то взяли из FreeBSD? "С оглядкой" - значит "подсмотрели и сделали похоже", только лучше, конечно.
А глядели на систему инициализации. Сейчас потихоньку systemd проникает.

Джадд собрал Арч с нуля: "Arch is independently developed, was built from scratch and is not based on any other GNU/Linux distribution." Это из FAQа.
А ссылка: https://wiki.archlinux.org/index.php/FAQ


"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 17-Июн-12 13:30 
> Джадд собрал Арч с нуля: "Arch is independently developed, was built from
> scratch and is not based on any other GNU/Linux distribution." Это
> из FAQа.

С нуля взяв вклад редхата в ядро, gnome и прочую ерунду.


"openSUSE на пути к изменению модели разработки"
Отправлено 1 , 17-Июн-12 14:08 
Оттого, что РХ делает вклад в ядро, гном и т.д. не вытекает, что все дистры - клоны РедХата. Космонавт - один из крупных вкладчиков в KDE, но ты же не станешь утверждать, что Мандрива - клон Убунты.

Вопрос на засыпку, чей вклад взял РедХат и чьим клоном он должен быть, если на тот момент момент уже были Slackware и Debian?


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 18-Июн-12 10:22 
Хоть одну статью написал/перевел?

"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 16-Июн-12 05:04 
> вручную править конфиги и удобнее и легче, а потом когда смотришь
> конфиги, понимаешь что он их просто изговнял.

А нефиг руками туда лазит, либо Yast либо руками.
Я знаю, надо вам бинарный формат сделать, чтоб свои кривые руки не сували
> Например при настройке виртуальных хостов в апаче, если через него их настраивать,

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

---
В прочем я рад, что моем любимом дистре не прибавится дебилов.


"openSUSE на пути к изменению модели разработки"
Отправлено ILYA INDIGO , 16-Июн-12 13:48 
И это пишет тот, кто жаловался, что мол анонимы говном поливают без повода, а сам говно расплёскивает ещё гуше...

И это пишет тот, у кого на сервере иксы и без гуйного яста вообще конигурировать не умеет...

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

Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить! ИМХО


"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 21-Июн-12 21:27 
> И это пишет тот, у кого на сервере иксы и без гуйного
> яста вообще конигурировать не умеет...

Дятел чтоль? Какой нахёр сервер? У меня на всех серверах Debian.

> Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить!

YaST не говнит конфиги! Это ты их изговнил когда руками полез.


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 14:14 
> а говорили, что у Дебиана не правильный подход :)

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


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 16:41 
> Самый правильный подход - у убунты: забить болт на баги, выпустить точно
> в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.

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

Впрочем, у любого дистра и ОС - своих проблем навалом. Можно подумать что это самые хучшие.


"openSUSE на пути к изменению модели разработки"
Отправлено Anonim , 15-Июн-12 18:08 
Есть дистры лишенные обоих этих проблемм. Роллинг чего-то там

"openSUSE на пути к изменению модели разработки"
Отправлено Вернат , 25-Июн-12 02:36 
openSUSE Tumbleweed, оно?

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 26-Июн-12 11:24 
> openSUSE Tumbleweed, оно?

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


"openSUSE на пути к изменению модели разработки"
Отправлено lucentcode , 15-Июн-12 20:47 
Самый правильный у Arch linux. Вот только неофитам он не по зубам, работая в нём надо головой думать, прежде чем изменять настройки и т.п. Всё ручками делается, и головой... Это не мартышкин труд(кнопконажимательство в Arch не в почёте).

"openSUSE на пути к изменению модели разработки"
Отправлено Куяврик , 15-Июн-12 23:11 
и gentoo. я бы вообще рекомендовал неофитам начинать с минимала. те, кто останутся - будут толковыми.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 19-Июн-12 08:22 
А вам не кажется, что слишком много чести операционке - постоянно разруливать особенности обновления, подправлять конфиги и т.п.? Лично я предпочитаю тратить свое время на работу более творческую

"openSUSE на пути к изменению модели разработки"
Отправлено Return76 , 15-Июн-12 23:12 
>> а говорили, что у Дебиана не правильный подход :)
> Самый правильный подход - у убунты: забить болт на баги, выпустить точно
> в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.

Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост - через 3 года "это" будет стоять у них на серверах! Будете спорить?


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 16-Июн-12 01:17 
> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu?

Потому что таких "сисадминов" надо с работы гнать?  :)  Угадал?  На работе они, понимаешь, Debian настроили - а дома десктоп из него сделать ниасилили.

А лучше - отучаемся говорить за "всех".


"openSUSE на пути к изменению модели разработки"
Отправлено Куяврик , 18-Июн-12 16:07 
> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов
> на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост
> - через 3 года "это" будет стоять у них на серверах!
> Будете спорить?

Нет. В массовые решения всегда вылезают кхм... самая лёгкие фракции. Из всех ОС - Windows. Из всех линуксов - убунта. Ну и далее.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 16-Июн-12 23:35 
> Его эффективность наглядно подтверждается рейтингом популярности дистров.

Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на Mint...


"openSUSE на пути к изменению модели разработки"
Отправлено Куяврик , 18-Июн-12 16:08 
>> Его эффективность наглядно подтверждается рейтингом популярности дистров.
> Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на
> Mint...

+10 к троллингу


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 20-Июн-12 00:24 
> +10 к троллингу

Да какой троллинг, я когда-то украинское зеркало дистровотча поддерживал.  До сих пор иногда и поглядываю.

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


"openSUSE на пути к изменению модели разработки"
Отправлено Mr.Yudgin , 15-Июн-12 11:15 
Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы mono они из него выпилили.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 11:34 
> Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для
> сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и
> причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы
> mono они из него выпилили.

Кто тебя заставляет mono ставить или зузю? Нет выбора?


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 19:41 
во-первых, правильно пишется openSUSE.
во-вторых, назови хоть один SUSE-специфичный пакет зависимый от mono?

"openSUSE на пути к изменению модели разработки"
Отправлено Reyn , 15-Июн-12 11:43 
6 месяцев, 8, 12...
Вместо того, чтобы за цифирками гнаться, может уже пора задуматься об LTS?

"openSUSE на пути к изменению модели разработки"
Отправлено I am , 15-Июн-12 12:00 
Да разрабам opensuse это скучно.

"openSUSE на пути к изменению модели разработки"
Отправлено кверти , 15-Июн-12 12:15 
не все так просто. для этого есть SLE. если сделать LTS, то это ударит по SLE, и в свою очередь ударит по самим разрабам, так как они в своем большинстве и есть разрабы как openSUSE, так и SLE

"openSUSE на пути к изменению модели разработки"
Отправлено I am , 15-Июн-12 12:38 
> не все так просто. для этого есть SLE. если сделать LTS, то
> это ударит по SLE, и в свою очередь ударит по самим
> разрабам, так как они в своем большинстве и есть разрабы как
> openSUSE, так и SLE

Для хеппи энда не хватает только того, что бы обновления для SLE были доступны. Хотя в целом цена на подписку там в разы меньше чем у шапки, но тем не менее.


"openSUSE на пути к изменению модели разработки"
Отправлено filosofem , 15-Июн-12 12:23 
см. SUSE Linux Enterprise

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 12:34 
У них есть LTS версия. Вроде бы Evergreen называется.

"openSUSE на пути к изменению модели разработки"
Отправлено Михрютка , 15-Июн-12 17:11 
эвергрин не лтс, эвергрин - костыль для подпирания систем, которые хозяева боятся обновлять на новые версии этого цир^W^W OpenSUsE.

"openSUSE на пути к изменению модели разработки"
Отправлено ппппппяяя , 15-Июн-12 17:12 
Вместо того как за циферками гнаться, они думают как бы сделать дистрибутив лучше, ищут решения проблем.

"openSUSE на пути к изменению модели разработки"
Отправлено Aquarius , 22-Сен-12 22:30 
какая тонкая ирония

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 19:42 
для тех кто в танке - есть Evergreen.

"openSUSE на пути к изменению модели разработки"
Отправлено Дед Анон , 15-Июн-12 12:05 
Согласен с предыдущим постером!
И ещё... Давно пора перейти на как минимум две ветки одна пусть постоянно обновляется(жаль что они от этого метода отказались), а другая пусть будет LTS лет на 5 как минимум(а в мечтах лет на 10), с возможностью безболезненной миграции на следующий стабильный релиз!

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 19:44 
Tumbleweed
нет нужных пакетов? а ты их туда засабмитил?

"openSUSE на пути к изменению модели разработки"
Отправлено хамелеон , 15-Июн-12 12:37 
Молодцы! Если сыро ну и правильно что не хотят выпускать релиз.

"openSUSE на пути к изменению модели разработки"
Отправлено sasa , 15-Июн-12 15:25 
> Если сыро ну и правильно что не хотят выпускать релиз.

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


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 16-Июн-12 23:40 
> все нормальные люди давно на Ubuntu перешли.

Ну привет вам, "нормальные".

Интересно, через сколько лет Шатлворт наберётся смелости сказать, что полугодовой цикл был чисто маркетинговым кидаловом...


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 12:52 
А можно просто пойти по пути Ubuntu - игнорировать баги и выпускать релиз as is точно в срок.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 13:02 
В могилу оно катится. В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят за пару дней. Даже исправления безопасности выходят с задержкой в недели.
А в официально не поддерживаемых репах из obs половина пакетов либо не собираются, либо не работают.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 14:13 
В убунте та же фигня, и ничего, живее всех живых.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 16:42 
> В убунте та же фигня, и ничего, живее всех живых.

Да ладно вам, в убунте свои баги они чинят а апстримные чинят апстримы :)


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 14:37 
Грустно соглашаюсь.

"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 15-Июн-12 15:02 
> В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят
> за пару дней. Даже исправления безопасности выходят с задержкой в недели.

Оплачивал саппорт? Разрабы обязаны жрать ночами доширак, но выпустить патч через час анонса?


"openSUSE на пути к изменению модели разработки"
Отправлено SubGun , 15-Июн-12 16:03 
Оплачивал саппорт?

Про OpenSuSe разговор, а не про SLES.


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 19:46 
> Оплачивал саппорт?
> Про OpenSuSe разговор, а не про SLES.

поэтому, отправь патч сам!


"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 15-Июн-12 23:20 
> Оплачивал саппорт?
> Про OpenSuSe разговор, а не про SLES.

Так тем более, был бы SLES можно было ещё предъявлять.
А так, извините, скажите спасибо, что вообще... :)


"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 16-Июн-12 00:19 
> Про OpenSuSe разговор

А кто это.

S.u.S.E Linux
SuSE Linux
SUSE Linux
openSUSE

Как то так.



"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 15-Июн-12 15:06 
На Сентябрь это хорошая мысль, но лучше на вторую неделю октября!  

"openSUSE на пути к изменению модели разработки"
Отправлено pavlinux , 15-Июн-12 15:21 
Макс, делай коменты только авторизированных, хоть через вконтакт, твытыр, фейсб...

Заипли уже анонимы, сайт в какашку превратился. Каждая тема превращается в срач.
Обвинения и недовольства вообще никак не аргументируются - вот говно и всё.


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 16:44 
> хоть через вконтакт, твытыр, фейсб...

Ты действительно этого хочешь? Натурально из вконтакта? :)


"openSUSE на пути к изменению модели разработки"
Отправлено qux , 15-Июн-12 17:02 
Конечно, во всем анонимы виноваты. А главное, никто не сомневается, что как только этот ник исчезнет, все сразу станет как надо.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 17:11 
> Обвинения и недовольства вообще никак не аргументируются - вот гoвно и всё.

Это между прочим и твоих коментов касается: в 50% случаев столь же неаргументированные набросы и высeры.

Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных?


"openSUSE на пути к изменению модели разработки"
Отправлено Andrey Mitrofanov , 15-Июн-12 17:21 
> Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных?

Он же зарегистрированный! Если анонимов не, то он потребует вернуть деньги.


"openSUSE на пути к изменению модели разработки"
Отправлено Вернат , 25-Июн-12 02:39 
Друзья, выездная сессия ЛОРа? :)

"openSUSE на пути к изменению модели разработки"
Отправлено ILYA INDIGO , 15-Июн-12 20:47 
Ну комменты от социалок это вопрос спорный, но вот только от зарегенных это нужно!

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 16-Июн-12 23:42 
> но вот только от зарегенных это нужно!

Милости просим на linux.kiev.ua, там ровно так и есть.

Через какое-то время согласился, что Максим был прав.


"openSUSE на пути к изменению модели разработки"
Отправлено mf , 15-Июн-12 15:42 
Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается. Тамблевид - слишком нестабилен, с моей точки зрения, фактори - вообще транк какой-то. Даже пакман выглядит серьёзнее. Ведро тамблевида 2 из 3 раз имеет проблемные драйвера для моего оборудования.
Поддерживаю Стефана - так жить нельзя.

"openSUSE на пути к изменению модели разработки"
Отправлено SubGun , 15-Июн-12 16:04 
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается.

Хотите стабильности - пользуйте SLES.


"openSUSE на пути к изменению модели разработки"
Отправлено mf , 15-Июн-12 17:24 
В моём случае это SLED. Вы его когда нибудь видели? И цены на него (патчи - 50 баков в год). Но и это не всё. Как я понял ветки - SLES & SLED - это для корпорасов. Для дома - опенсуся. Так что замечание не в кассу.
Преимущество линукса над виндовсом для десктопа в его стабильности и постоянном развитии. ПО стало больше и нужны новые механизмы для формирования стабильного дистрибутива.

"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 16-Июн-12 00:11 
> ПО стало больше и нужны новые механизмы для формирования стабильного дистрибутива.

Откуда. Просто одной задницей на десяти стульях не сесть. Хотят быть хорошими для всех, а оно не получилось. kde3, kde4, gnome2, gnome3, lxde, xfce, enlightenment. freetype1 - сколько лет уже его не существует, а его все тянут. Для совместимости со сферическим астралом, не иначе. Отсюда и качество стремящееся к нулю.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 16-Июн-12 23:45 
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается.

Пользуюсь сизифом более 10 лет.  Некоторые поднятые вопросы живо напомнили и то, что в devel@altlinux обсуждалось -- но в общем и в целом сейчас со стабильностью скорее хорошо, кроме времён подвижек тектонических плит вроде xorg.

Стопка пруфов доступна на http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima.../ :)


"openSUSE на пути к изменению модели разработки"
Отправлено mf , 17-Июн-12 00:27 
Миша, я совето-русо-путо-фоб не могу перейти на альт :) Но наверное в виртуалке поставлю...

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 00:31 
> Но наверное в виртуалке поставлю...

Да не, не стоит, если имеющееся устраивает.  Ссылка была упреждающей для иных любителей подоказывать ;-)

Кстати, первый экспериментальный образ для виртуалки сегодня тоже выпек.  Осталось купить турбореактивные двигатели у англичан -- ой, потырить конверсию из kiwi -- и можно взлетать!


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 16:11 
Мой вопрос немного не в тему, но все же. Скажите можно ли переносить патчи между дистрибутивами? Например, есть некоторая функция в виде патча, но в другом дистрибутиве, могу ли я сделать пакет, для другого дистрибутива используя там этот патч? Я так же хочу после выложить этот пакет для общего доступа в виде исходного кода и бинарного пакета. Буду благодарен за компетентный ответ

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 16:13 
Этот же вопрос интересует и к патчам исправляющим те или иные ошибки

"openSUSE на пути к изменению модели разработки"
Отправлено ram_scan , 15-Июн-12 16:25 
Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы бы таких вопросов не задавали. Поэтому вам - нельзя.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 18:05 
> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы
> могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы
> бы таких вопросов не задавали. Поэтому вам - нельзя.

За то, что ответили на мой вопрос, спасибо. А на счет всего остального: поменьше желчи


"openSUSE на пути к изменению модели разработки"
Отправлено Aquarius , 22-Сен-12 22:39 
>> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы
>> могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы
>> бы таких вопросов не задавали. Поэтому вам - нельзя.
> За то, что ответили на мой вопрос, спасибо. А на счет всего
> остального: поменьше желчи

теперь совсем нельзя

P.S. 100% не желчь


"openSUSE на пути к изменению модели разработки"
Отправлено свищ , 15-Июн-12 16:54 
используйте obs. автоматического создания патчей нет, конечно, но возможность централизованно иметь пачку патчей для всех популярных дистрибутивов в одном месте, собирать, тестировать и раздавать в виде репозиториев

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 17:50 
Спасибо вам за ответ. Собственно я и хочу бэкпортировать некоторые функции с одного дистрибутива в другой. Как это сделать у меня трудностей не возникает, интересовал лишь вопрос законности применения патчей разработчиков одного дистрибутива в другом дистрибутиве.

Если я, верно вас пониманию, то получается если я переношу результат работы одного сообщества в другое сообщество то в данном случае никаких препятствий и ограничений нет?


"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 16-Июн-12 18:25 
Лицензию смотри к патчам.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 17-Июн-12 02:54 
Если не сложно, покажите для примера где такая используется. Конечно в OpenSUSE по моему видел, но это скорее относится к spec содержимому.

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 16-Июн-12 23:49 
> Скажите можно ли переносить патчи между дистрибутивами?

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

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

Так что лучше конкретизировать.

PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи.  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к легитимному применению.


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 17-Июн-12 00:12 
> PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи.

"Вы мне запрещаете?" (c)

>  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к
> легитимному применению.

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

В Debian большая часть пакетов (я не знаю контрпримеров) имеет на debian/* (в т.ч. и патчи) - в качестве лицензии варианты GPL.  А в архиве есть исходники с самыми разнообразными лицензиями.

Use common sense, Luke!


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 00:28 
> Use common sense, Luke!

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

Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на первой же софтине с GPL incompatible license -- но такое бы явно уже вскрылось.


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 17-Июн-12 10:39 
> common sense как раз и подсказывает, что лицензия на патч (особенно тривиальный)
> -- такая же, как и на тот исходник, разницу с созданной
> на основе которого производной работой он и описывает.

Не логично.  Как на остальной кусок работы по пакетированию (сдержимое debian/, к примеру).  Это - логично.

> Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на
> первой же софтине с GPL incompatible license -- но такое бы
> явно уже вскрылось.

Да чего уж тут "занудство".  Также, вполне логично - людям лень выписывать на каждый debian/patches/01_bla-bla.patch - отдельный крендель в copyright (а сабмиттеры патчей не настаивают на откровенном legal-маразме).  Вот и лепят на весь debian-stuff - одну лицензию.  Естественно, она обязана быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG.


"(offtopic) права на патчи и инструкции по сборке"
Отправлено Michael Shigorin , 17-Июн-12 12:26 
>> лицензия на патч (особенно тривиальный) -- такая же, как и на тот исходник,
>> разницу с созданной на основе которого производной работой он и описывает.
> Не логично.

Исходники и патчи -- данные, debian/{copyright,rules} -- метаданные.  Почему нелогично?

Я могу и более строго пояснить, но это будет очередной офтопик.

> Вот и лепят на весь debian-stuff - одну лицензию.  Естественно, она обязана
> быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG.

Так это ж совсем другое дело. :)

// кажется, опять перезанудствовал дебианщиков -- брр, срочно на озеро


"openSUSE на пути к изменению модели разработки"
Отправлено PnD , 20-Июн-12 10:56 
  Уже, млин :(. Выпилили libreadline >> несъедобный интерфейс пострги, выпилили openssl >> гнутая версия глючит при постановке сессии с рядом клиентов (TheBat! smtp over tls, например). А что ядро у них не суспендится под xen'ом, это вообще выше моего понимания - такой херни даже в убунте нет.
  Итог = Debian потерял для меня смысл как серверный дистрибутив, а жалко - на ряде задач с RHEL-клонами возиться существенно дольше.

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 20-Июн-12 12:04 
> Итог =

Грустно слышать :(  Может, хоть багу на тот же Pg им повесите, вдруг переобсудят?


"openSUSE на пути к изменению модели разработки"
Отправлено Andrey Mitrofanov , 20-Июн-12 13:11 
>> Итог =
> Грустно слышать :(  Может, хоть багу на тот же Pg им
> повесите, вдруг переобсудят?

Да, всё уже переобсужено и починено. http://bugs.debian.org/607907

Чтоб GNU readline _фактически использовался в pgsql, его нужно доставить в систему, т.к. его нет в зависимостях пакета, а бинарник собирается с _бинарно-_совместимым editline^Wlibedit из-за лицензионных ограничений, насколько я помню, таки _openssl.

Это (установка целого одного пакета руками), конечно, славная причина "свалить с" и "трахаться с". ///Да, конечно, я опять ничего не понял.


"openSUSE на пути к изменению модели разработки"
Отправлено PnD , 02-Июл-12 16:02 
  Причина для меня = ядро не суспендится под xen'ом, остальное - да, решается костылями.
Вон, в убунте 12.04 расфаршмачили /etc/network/interfaces (перепутан порядок запуска интерфейсов в апстарте), но это не блокирующий баг (хотя ограничивает область испоьзования) и на него в рабочем порядке запилили костыль. А вот криво собранное ядро - это уже в морг, у нас нет штата заниматься сборкой/отладкой для боевых систем.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 17-Июн-12 03:04 
>[оверквотинг удален]
> Как правило, да -- но в каждом конкретном случае могут возникнуть свои
> нюансы (от разных веток софта, который упаковывается, до разного взаимодействия с
> окружением).
> Например, сегодня стырил три гентушных патча и один дебиановский, поправляя сборку photoprint,
> и заодно в апстрим закинул.  Всё просто легло, хоть и
> чуть разные версии.
> Так что лучше конкретизировать.
> PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи.
>  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к
> легитимному применению.

Спасибо вам за ответ, вы реально мне помогли. На самом деле, некоторое время назад, я видел в Gentoo патчи от Fedora. И единственное что было приложено к патчу, это текст, мол взято из федоры. Я пошел таким же путем, пишу источник патча точнее имя пакета с которого я его взял. Свои патчи оставляю без комментариев, думаю, что оно и так ясно кто их сделал.

Еще раз спасибо за помощь


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 17-Июн-12 10:47 
> Свои патчи оставляю без комментариев, думаю,
> что оно и так ясно кто их сделал.

И напрасно.

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

В дебиане для подобного есть (опциональный) стандарт (http://dep.debian.net/deps/dep3/) метаинформации к патчам.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 12:17 
> На самом деле, некоторое время назад, я видел в Gentoo патчи от Fedora.
> И единственное что было приложено к патчу, это текст, мол взято из федоры.
> Я пошел таким же путем, пишу источник патча точнее имя пакета
> с которого я его взял.

Тут есть два момента:
- credit where credit is due (в смысле отдать должное, а не "в кредит");
- практическая сторона вопроса, т.е. сверяемость/воспроизводимость.

Сам стараюсь (но по лени не всегда так делаю) отмечать, из какой в точности версии-сборки пакета утащен патч; и опять же по лени в следующий раз проделывать то же самое стараюсь и чужие патчи более-менее очевидного толка (например, фиксы сборки с новыми gcc/autotools/...) отправлять авторам софтинки.

Обычно полезно включить название источника в имя файла с патчем -- см., например, http://www.altlinux.org/ALT_Packaging_HOWTO#.D0.9D.D0.B0.D0....

> Свои патчи оставляю без комментариев, думаю, что оно и так ясно кто их сделал.

Комментарии можно писать в том же RPM spec около Patch: -- либо в письме разработчикам или заявке на включение патча.  В простом случае и полстроки достаточно.

Почему патчи лучше мержить -- см., например, http://vimeo.com/23522095


"openSUSE на пути к изменению модели разработки"
Отправлено petyanamlt , 15-Июн-12 17:51 
Правильно делают, версия 12,1 глюкавая получилась.

"openSUSE на пути к изменению модели разработки"
Отправлено Аноним , 15-Июн-12 18:11 
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается
> Правильно делают, версия 12,1 глюкавая получилась.

Хоть тут и критикуют подход Каноникла к выпуску релизов, но нельзя не согласится со сказанным выше - качество релизов суси неуклонно снижается. 12.1 ужасен. Не припомню ни одного случая, чтобы после успешной установки с Livecd система после grub вылетала в kernel panic, на другом компе все работает, но печалит многочисленными багами и тормознутостью.
В убунту с такими эпичными багами не сталкивался.


"openSUSE на пути к изменению модели разработки"
Отправлено Aceler , 15-Июн-12 18:32 
Передайте им, что при наличии OBS репозитарий им просто не нужен. Соответственно, никаких проблем со сроками — главное стабилизировать основное окружение, остальное собирать отдельно. Релиз делать через месяц после стабилизации, чтобы не оказаться с пустым набором софта.

Правда, роллинг в этом случае совсем не гарантирован.


"openSUSE на пути к изменению модели разработки"
Отправлено mf , 15-Июн-12 19:03 
Одному мне показалось что Вы показали Windows-way?

"openSUSE на пути к изменению модели разработки"
Отправлено Aceler , 15-Июн-12 19:07 
> Одному мне показалось что Вы показали Windows-way?

Увы, нет, очень многие путают микрорепозитарии а-ля PPA или OBS (а теперь ещё и ABF) с нестандартными инсталляционными пакетами, как это принято в Windows, или в лучшем случае с MSI/DMG. Однако это не так, репозитарии остаются репозитариями, вне зависимости от того, на сколько они большие.


"openSUSE на пути к изменению модели разработки"
Отправлено mf , 15-Июн-12 19:34 
Вы пока разницы не показали. Если программа не пользуется тем, что в системе, а тащит с собой - это либо тестовая программа, либо виндовс.

"openSUSE на пути к изменению модели разработки"
Отправлено Юрий , 16-Июн-12 01:20 
Вот в этом их и проблема, они не могут определится с основным окружением. Набрали горы барахла и стыкуют его с новым gcc-4.7.

"openSUSE на пути к изменению модели разработки"
Отправлено mihalych , 15-Июн-12 19:06 
> Например, после обновления версии сам пакет может

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

Поэтому gentoo forever!


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 15-Июн-12 20:17 
> В качестве одного из вариантов, предложенных
> Сетфаном, называется уход от плановой подготовки
> новых версий, которые сейчас выпускаются строго
> раз в 8 месяцев, к модели без жестких планов, основанной
> на готовности дистрибутива, или к заметному расширению сроков подготовки новых версий,
> например, переходу к выпуску релизов раз в год.

Я не понял, а где Шигорин со своим
"Да! А я им это еще n лет назад говорил!"?  :-)


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 00:17 
>> например, переходу к выпуску релизов раз в год.
> Я не понял, а где Шигорин со своим
> "Да! А я им это еще n лет назад говорил!"?  :-)

Как где, в архиве: http://www.opennet.me/openforum/vsluhforumID3/50315.html#19 (n > 3)


"openSUSE на пути к изменению модели разработки"
Отправлено ILYA INDIGO , 15-Июн-12 20:32 
>переход к модели непрерывного цикла обновления пакетной базы (Rolling-release)

Вот это реально нам и надо, как в Arch и никаких проблем.
>...перенести релиз на середину сентября...на следующей неделе...перехода на фазу заморозки...

Это и так устарелый пакеты (libreofice php postqresql mariadb mysqlworkbench geany memcashed) ещё и замарозят на 3 месяца...

Не я точно валю на Arch!


"openSUSE на пути к изменению модели разработки"
Отправлено Игорь , 15-Июн-12 20:41 
Я тоже пользуюсь openSUSE более 5 лет. Часто ради собственного интереса ставлю на попробовать Бета-версии. Проблема снижения качества отладки дистрибутива перед релизом мне понятна. Я согласен с тем, чтобы релизы выходили реже, например раз в 10 месяцев, но более качественные. Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...

"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 00:19 
> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...

См. тж. анализ Игоря Власенко: http://ftp.linux.kiev.ua/pub/conference/peers/lviv/2012/Vlas...


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 17-Июн-12 11:29 
>> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
> См. тж. анализ Игоря Власенко: http://ftp.linux.kiev.ua/pub/conference/peers/lviv/2012/Vlas...

Плач Яросл^Wальтовцев это, а не анализ.  И все сказошные аналогии с феодализмом - увы, основаны только на проблемах конкретного комьюнити.  Debian имеет раза в два большую пакетную базу, но никто не жалуется.

Финал:
> Widespreading the technology will definitly change ALT Linux into a prominent distribution and make it an innovation leader.

No chance.  Не, ну вам, ребят - удачи, конечно...

Утилит для этого самого "automation of maintainer's work" - в том же Debian'е вагон, причем давно (куда больше интересны утилиты для автоматизации QA, а не подобные велосипеды; тем более, что буквально воровать пакеты - там неоткуда).  Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?).  И т.д.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 12:49 
>>> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
>> См. тж. анализ Игоря Власенко:
> Плач Яросл^Wальтовцев это, а не анализ.

А, ну подождите ещё пару годиков.

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

(заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то.

> Финал:
>> Widespreading the technology will definitly change ALT Linux into a prominent
>> distribution and make it an innovation leader.
> No chance.  Не, ну вам, ребят - удачи, конечно...

Это был докторский вброс, да :)

> Утилит для этого самого "automation of maintainer's work" - в том же
> Debian'е вагон, причем давно (куда больше интересны утилиты для автоматизации QA,
> а не подобные велосипеды; тем более, что буквально воровать пакеты -
> там неоткуда).

Если Вы полагаете, что в дебиане есть всё, то заблуждаетесь.  Окиньте взглядом CPAN.

> Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid
> в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?).  И т.д.

Буквально на неделе коллега разве что не матерился на Debian testing и дрова nvidia 295-й серии, которые ему приехали вследствие желания поставить "всего лишь" одну софтинку, потянувшую новую glibc.

Вы поймите правильно: на дебиан году в 2001 я и сам собирался переходить, так что присматривался ещё с тех пор довольно внимательно.  Но что криво у нас в альте или у вас в дебиане или над чем не думают (либо думают, но не делают) -- то надо уметь признать.

PS: усё, сбёг на озеро, чего и Вам желаю ;-)

PSP: пришёл.  Коллеги, лето на дворе, хватит втыкать в монитор!


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 17-Июн-12 15:15 
> (заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то.

Ну, "караул" на уровне Инго - не кричат.  Не знаю что там до вас долетае...

> Если Вы полагаете, что в дебиане есть всё, то заблуждаетесь.  Окиньте
> взглядом CPAN.

Все что попросили включить (см. BTS wnpp) - стараются включать, причем подготовка пакета достаточно хорошо автоматизирована.

А вот зачем мейнтейнерам перл в Debian заморачиваться еще какой-то специальной инфраструктурой для автоматического запихивания в архив ненужного никому хлама?  Непонятно.

>> Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid
>> в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?).  И т.д.
>
> Буквально на неделе коллега разве что не матерился на Debian testing и
> дрова nvidia 295-й серии, которые ему приехали вследствие желания поставить "всего
> лишь" одну софтинку, потянувшую новую glibc.

Тут нужны подробности.  Пока у меня складывается плохое впечатление о вашем коллеге.  Как ни крути полученную от вас информацию:
a) коллега использует тестинг и обновлялся
b) коллега использует squeeze и подключил тестинг ради плюшки
c) иной вариант, фантазия отказывает
- он таки выглядит ССЗБ.  Тестинг - это тестинг, там много чего периодически ломают.  Использование микса stable+testing - официально не поддерживается.  Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.

В варианте b) - действительно, помог бы бэкпорт.

Увы, автоматизировать полностью его принципиально невозможно.  Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog и пересобрали".  Если, конечно, у вас нет развернутой автоматической системы тестирования пакетов.  Работы оных, а не сборки.

А вручную - бэкпорты для указанного пакета периодически делаются.  Ничто не мешает помочь интересующимся людЯм ускорить процесс.

> Вы поймите правильно: на дебиан году в 2001 я и сам собирался
> переходить, так что присматривался ещё с тех пор довольно внимательно.  

Ну, с 2001 года Дебиан малость изменился в (ИМХО) лучшую сторону...  Как, наверно, и ALT.  Может пора присмотреться по-новой?

> Но что криво у нас в альте или у вас в
> дебиане или над чем не думают (либо думают, но не делают)
> -- то надо уметь признать.

По содержимому доклада выше - так и не понял что конкретно криво в Debian.  А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.  Боюсь, с подходом к выпуску, тестированию и дальнейшему сопровождению релизов в Debian - такое стало бы для него фатальным и никакая автоматизированная система сборки хлама с CPAN - его бы не спасла :)

Думаю, это применимо и к ALTLinux.  Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.  Соответственно, сабж без хорошей системы автоматического тестирования - приведет элементарно к дальнейшему падению качества дистрибутива.

PS:
> Коллеги, лето на дворе

На чужом дворе мож-т и лето.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 17-Июн-12 21:17 
>> (заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то.
> Ну, "караул" на уровне Инго - не кричат.

Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel team).

> Не знаю что там до вас долетае...

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

>> Окиньте взглядом CPAN.
> Все что попросили включить (см. BTS wnpp) - стараются включать

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

> причем подготовка пакета достаточно хорошо автоматизирована.

Ну с тех пор как тот кромешный ужас на старом dh в debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой хотя бы ;-)

> А вот зачем мейнтейнерам перл в Debian заморачиваться

Полагаю, Вы к таковым не относитесь -- потому предложу за них и не выступать.  Перловку в альте немного майнтейню, если что.

> Тут нужны подробности.  Пока у меня складывается плохое впечатление о вашем коллеге.

Обычный дядька, линуксовод со стажем, сишник.  Притащил его к нам netch@, кстати.

> a) коллега использует тестинг и обновлялся

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

> Тестинг - это тестинг, там много чего периодически ломают.
> Использование микса stable+testing - официально не поддерживается.
> Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.

Внимание, вопрос: для каких задачи тогда пригоден Debian stable?

> В варианте b) - действительно, помог бы бэкпорт.

О чём было второе внушение (с упоминанием альтовских autoports).

> Увы, автоматизировать полностью его принципиально невозможно.
> Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog
> и пересобрали".  Если, конечно, у вас нет развернутой автоматической системы
> тестирования пакетов.  Работы оных, а не сборки.

Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование (или автоматизацию сбора статуса -- "работает/сломано").

> А вручную - бэкпорты для указанного пакета периодически делаются.
> Ничто не мешает помочь интересующимся людЯм ускорить процесс.

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

>> Вы поймите правильно: на дебиан году в 2001 я и сам собирался
>> переходить, так что присматривался ещё с тех пор довольно внимательно.
> Ну, с 2001 года Дебиан малость изменился в (ИМХО) лучшую сторону...  

Конечно.

> Как, наверно, и ALT.  Может пора присмотреться по-новой?

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

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

> По содержимому доклада выше - так и не понял что конкретно криво в Debian.

Рукопашный подход.

> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.

Было и сопоставимое с Debian лет десять тому, это тоже не работает.  Собсно, перечитайте новость.

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

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

> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.

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

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

Проблема вкратце такова: либо релизить "when it's совсем ready" и пользоваться заслуженной репутацией ископаемого, либо перераспределять и подпирать _ограниченный_ ресурс человеческого внимания так, чтобы протекание кода из апстримов к пользователям происходило с минимальными накладными расходами и максимальным отловом проблем по дороге.

Кстати, будет интересно посмотреть, как эта самая проблема повлияет на взаимодействие Debian и Ubuntu.  Особенно если у них не найдётся толкового д.м.н. подумать заранее.

>> PS: Коллеги, лето на дворе
> На чужом дворе мож-т и лето.

Дык приезжайте ;-)  Аж подгорел малость за час-полтора...


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 17-Июн-12 22:29 
> По крайней мере watch-файлики изобрели в дебиане -- стало
> быть, и те люди скорее всего предполагали, что увеличить циферку и
> попытаться собрать может и робот

Аналог "watch-файликов" был ВСЕГДА в source-based системах, т.е.
примерно с середины/второй половины 90-х в *BSD.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 18-Июн-12 00:13 
> Аналог "watch-файликов" был ВСЕГДА в source-based системах

О, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge.


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 18-Июн-12 12:13 
>> Аналог "watch-файликов" был ВСЕГДА в source-based системах
> О, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge.

MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=dict/} \
                ftp://ftp.dict.org/pub/dict/


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 18-Июн-12 14:19 
>>> (заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то.
>> Ну, "караул" на уровне Инго - не кричат.
>
> Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel
> team).

С разработчиком ядра логично сравнивать разработчиков ядра.

>> Не знаю что там до вас долетае...
> Например, необходимость прописывать зависимости ручками.

Вы имеете ввиду в Build-Depends?  Но телепатии пока не изобрели и разработчиков ходить строем с чем-то стандартным типа ./configure && make && make install - не приучили и не предвидится.

Увы, доклад не показывает пути решения данной проблемы.  Даже намека.

> Я к тому, что есть огромное поле того, что люди собирают сами
> предоставляемыми сторонними инструментами.  И CPAN тут -- это только верхушка
> айсберга проблемы модулей для скриптовых языков, увы.  Там хоть базовая
> версия относительно одна.

Я указывал правильное решение: если люди не хотят собирать сами - пусть попросят.  Тех же debian-perl@.  Зачем автоматически класть в дистрибутив что-то "абы было"?

>> причем подготовка пакета достаточно хорошо автоматизирована.
> Ну с тех пор как тот кромешный ужас на старом dh в
> debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой
> хотя бы ;-)

Он не был и до.  Существовали (и продолжают) инструменты, облегчающие подготовку первоначальной версии пакета (всякие dh_make).  См. вашу же новость http://www.opennet.me/opennews/art.shtml?num=34119

Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета - сильно преувеличены.  Это действие, которое делается один раз.  Основное время мейнтейнера занимает исправление багов, тестирование, адаптация пакетов под новый релиз upstream (это и автоматизировано лучше первоначального сетапа debian/).

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

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

>> Тут нужны подробности.  Пока у меня складывается плохое впечатление о вашем коллеге.
> линуксовод со стажем, сишник.

Да будь он хоть трижды ГСС и полный кавалер ордена Славы :)

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

>> Тестинг - это тестинг, там много чего периодически ломают.
>> Использование микса stable+testing - официально не поддерживается.
>> Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.
>
> Внимание, вопрос: для каких задачи тогда пригоден Debian stable?

Вопрос философский.  Зачем человеку компьютер?  Даже не знаю что сказать.

Читайте http://www.debian.org/News/ - там, в частности, есть и некоторые примеры применения.

>> В варианте b) - действительно, помог бы бэкпорт.
> О чём было второе внушение

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

>> Увы, автоматизировать полностью его принципиально невозможно.
>> Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog
>> и пересобрали".  Если, конечно, у вас нет развернутой автоматической системы
>> тестирования пакетов.  Работы оных, а не сборки.
>
> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование (или
> автоматизацию сбора статуса -- "работает/сломано").

Это почему так?  Ручное тестирование кучи пакетов - оно на порядок сложнее, собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.).  Особенно, для "интерактивных" программ (слыхал, что в opensuse что-то ковыряли на эту тему, но искать лень).

Так что это реально облегчило бы труд мейнтейнеров.

>> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
> Рукопашный подход.

Емм...  А в ALT есть аналог, к примеру, puiparts?  А lintian, а debcheck?  Упрекать Debian в недостатке автоматизации - крайне несправедливо, имхо.

>> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
> Было и сопоставимое с Debian лет десять тому, это тоже не работает.
> Собсно, перечитайте новость.

Но в дебиан-то, вроде, работает?

>> Боюсь, с подходом к выпуску, тестированию и дальнейшему
>> сопровождению релизов в Debian - такое стало бы для него фатальным
>
> Не уверен.  По крайней мере watch-файлики изобрели в дебиане -- стало
> быть, и те люди скорее всего предполагали, что увеличить циферку и
> попытаться собрать может и робот, а вот человеку лучше побольше времени
> оставить читать NEWS или коммиты и проверять работоспособность, освободив при возможности
> от лишней рутины.

Так вот это и есть реальная автоматизация.  Более того, она действительно *работает*.

>> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
> Можно [ссылку на] список?  Смутно припоминается, что чего-то действительно не хватало
> -- но в дебиане не припоминаю, например, реализованной в масштабах всего
> main проверки на разрешимость ELF-символов.

Откройте цитированный адрес - там в вики есть обзор деятельности команды.  Кое-какие из сервисов я упомянул выше.

>> Соответственно, сабж без хорошей системы автоматического тестирования -
>> приведет элементарно к дальнейшему падению качества дистрибутива.
> Проблема вкратце такова: либо релизить "when it's совсем ready" и пользоваться заслуженной
> репутацией ископаемого, либо перераспределять и подпирать _ограниченный_ ресурс человеческого
> внимания так, чтобы протекание кода из апстримов к пользователям происходило с
> минимальными накладными расходами и максимальным отловом проблем по дороге.

"Ископаемое" - это эмоционально и необъективно.  Вот не нужно, чтобы ко мне "плавно перетек" Gnome3 из апстрима.  Мне удобно работать, и я не хочу быть альфатестером сомнительных инноваций.  Что касается более специфического ПО (научное, для сервера) - там мастеров-ломастеров меньше и интеграция с апстрим лучше и меньше разрыв версий, если он вообще существенный.

Вы путаете разные дистрибутивы с разными целями.  Принцип "when it's ready" - относится к качеству включаемого ПО.  Сдерживающим фактором обновления версий ПО здесь является количество RC багов, для которых автоматическое пакетирование новых релизов - совершенно иррелевантно.

"Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.

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


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 18-Июн-12 14:51 
> А в ALT есть аналог, к примеру, puiparts?  А lintian

Миша, я уже не один с такими "странными" вопросами ;-)
У вас rpm-щиков этого похоже ни у кого нет.
В pkgsrc pkglint ну очень дотошный, и это очень удобно.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 19-Июн-12 19:33 
> С разработчиком ядра логично сравнивать разработчиков ядра.

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

То есть в чём проблема: _везде_ плохо. (мальчикам-прянишничикам: у ваших ещё хуже)

>>> Не знаю что там до вас долетае...
>> Например, необходимость прописывать зависимости ручками.
> Вы имеете ввиду в Build-Depends?

В том числе.

> Но телепатии пока не изобрели

Да, но http://lists.altlinux.org/pipermail/devel/2011-December/1927...

> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
> make install - не приучили и не предвидится.

Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".  И этих "обычных" не так уж и много.

> Увы, доклад не показывает пути решения данной проблемы.  Даже намека.

Боюсь, просто не желаете воспринимать (NIH?).  Но не настаиваю.

> Зачем автоматически класть в дистрибутив что-то "абы было"?

Не "абы было", а "с минимальными усилиями, как только понадобится".  Статистику на http://www.debian.org/devel/wnpp/ наверняка же видели -- там далеко не нули.

>>> причем подготовка пакета достаточно хорошо автоматизирована.
>> Ну с тех пор как тот кромешный ужас на старом dh в debian/rules стал необязателен
>> -- эту подготовку можно не называть пыточной камерой хотя бы ;-)
> Он не был и до.

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

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

PS: ещё один пруфлинк как раз в руки пришёл: http://projects.deepnet.cx/trac/debbuild

> Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета -
> сильно преувеличены.

Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?

> Основное время мейнтейнера занимает

Это всё очень сильно зависит от того, насколько сложен/устоялся упаковываемый.

>>> А вот зачем мейнтейнерам перл в Debian заморачиваться [...] ?
>> Полагаю, Вы к таковым не относитесь -- потому предложу за них и
>> не выступать.  Перловку в альте немного майнтейню, если что.
> Альт здесь нерелевантен, извините.

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

> Кое-кто порядком покоцал цитату из меня любимого - и убрал знак вопроса в конце.

Простите, всего лишь постарался оставить главное; восстановил.

>>> Пока у меня складывается плохое впечатление о вашем коллеге.
>> линуксовод со стажем, сишник.
> Да будь он хоть трижды ГСС и полный кавалер ордена Славы :) [неправильно понятое skip]

Что-то я тоже всё меньше Вас понимаю и это огорчительно.

>> Внимание, вопрос: для каких задач тогда пригоден Debian stable?
> Вопрос философский.  Зачем человеку компьютер?  Даже не знаю что сказать.

Вот и я не очень понимаю, хотя теоретически несколько use cases и представляю -- например, когда разработка чего-либо хорошо синхронизируется с unstable/testing и можно позволить себе риски откладывания формального релиза stable, выпуская свой продукт.

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

> Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались.

Да ладно, это всё про выводы.  Хотя также и на заметку тем, кто на всякий чих будет советовать Debian testing и говорить, мол, сам сижу и всё хорошо.  Т.е. хоть предупреждайте, что тогда надо отслеживать...

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

Вот ровно потому, что автоматизация тестирования ещё сложнее.

> Особенно, для "интерактивных" программ (слыхал, что в opensuse что-то ковыряли
> на эту тему, но искать лень).

В альте тоже ковыряли, что характерно.  И для инсталяторов тоже.

>>> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
>> Рукопашный подход.
> Емм...  А в ALT есть аналог, к примеру, puiparts?

Проверка устанавливаемости пакетов интегрирована в сборочную систему: http://git.altlinux.org/people/ldv/packages/?p=girar-builder...

> А lintian, а debcheck?

Есть целый http://www.altlinux.org/Repocop авторства того же Игоря Власенко, а также обязательный sisyphus_check.  Некоторые пользуются и rpmlint, но его прохождение не является обязательным.

> Упрекать Debian в недостатке автоматизации - крайне несправедливо, имхо.

Обычно да, но смотря с чем сравнивать.

>>> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
>> Было и сопоставимое с Debian лет десять тому, это тоже не работает.
> Но в дебиан-то, вроде, работает?

Скорее тоже нет, см. WNPP (о применимости выпусков допрошу ещё коллег-дебианщиков при случае).

>> Не уверен.  По крайней мере watch-файлики изобрели в дебиане
> Так вот это и есть реальная автоматизация.  Более того, она действительно
> *работает*.

Так честь и хвала :)

>>> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
>> Можно [ссылку на] список?
> Откройте цитированный адрес - там в вики есть обзор деятельности команды.

Открыл, за разумные несколько минут не нашёл, закрыл.  Собственно, по ченжлогам она видна и это хорошо.

> Кое-какие из сервисов я упомянул выше.

Ответил.  Собственно, буду только рад, если изобретут и в дебиане.

> "Ископаемое" - это эмоционально и необъективно.

Извольте, термин debian stale не я придумал.  Можно подобное игнорировать, конечно.

> Вот не нужно, чтобы ко мне "плавно перетек" Gnome3 из апстрима.

Для этого апстрим не должен игнорировать Вас, по-хорошему...

> Что касается более специфического ПО (научное, для сервера) -
> там мастеров-ломастеров меньше и интеграция с апстрим лучше

Ой, вот давайте только без сказок про научное ПО.  Типичный случай как раз обратный, увы -- принцип "работает на моей машине" из всех щелей :(

> Вы путаете разные дистрибутивы с разными целями.

Отнюдь -- скорее задаюсь вопросом вслух.  Заметьте, меня он интересует в практическом плане; иллюзий же сам стараюсь не держать и Вам не советую.

> Принцип "when it's ready" - относится к качеству включаемого ПО.  Сдерживающим
> фактором обновления версий ПО здесь является количество RC багов, для которых
> автоматическое пакетирование новых релизов - совершенно иррелевантно.

Если такой баг -- апстримный, то может быть и релевантно.  При обеспечении возможности протестировать "сборку сбоку".

> "Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.

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

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

Отчасти да; поддержкой/образованием апстримов тоже стоит (и приходится порой) заниматься.

> Там, где он активно взаимодействует с мейнтейнерами в дистрибутиве (или сам
> играет эту роль) - с версиями проблем нет.

Да, конечно.  К слову: http://freecode.com/articles/lessons-in-packaging-linux-appl...


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 20-Июн-12 22:37 
>> С разработчиком ядра логично сравнивать разработчиков ядра.
>
> Минуточку, Инго вроде бы как не приводил дебиан в качестве исключения.  
> Или я Вас совсем не понимаю.

Ну все просто.

Мнение Инго: все плохо, судьи куп^W^W!
Мнение разработчиков Debian: ничего не все, никаких фатальных караулов не кричим, работаем помаленьку.  За всех, конечно, не могу расписаться - но радикально менять никто ничего не планирует.

>>>> Не знаю что там до вас долетае...
>>> Например, необходимость прописывать зависимости ручками.
>> Вы имеете ввиду в Build-Depends?
>
> В том числе.

Ну а ишшо-то где?  В бинарных пакетах dh все давно генерит.

>> Но телепатии пока не изобрели
> Да, но http://lists.altlinux.org/pipermail/devel/2011-December/1927...

Как еще один костыль для мейнтейнера (ручками пускать!) - да.  И спасибки!  А как часть ентой системы автоматизации сборки - сильно сомневаюсь.  Ну, поживем - увидим.

>> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
>> make install - не приучили и не предвидится.
>
> Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".  
> И этих "обычных" не так уж и много.

Да вот, "чисто случайно": mdadm.  Свой ручной Makefile.  Другой пример - ядро Linux.  Тоже не последний проект (хотя его вы можете забраковать в "обычные" в силу значимости).

Кстати, сколько "обычных" - на вашу оценку?

>> Зачем автоматически класть в дистрибутив что-то "абы было"?
>
> Не "абы было", а "с минимальными усилиями, как только понадобится".  Статистику
> на http://www.debian.org/devel/wnpp/ наверняка же видели -- там далеко не нули.

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

> Кому как, для меня это был один из существенных доводов держаться от
> самой мысли о поддержке пакетов в дебиане как можно дальше.  
> Потому как совершенно безумное дублирование болванки без какой бы то ни
> было необходимости

Если необходимости не было - дублировать не следовало.   Требуемые цели в debian/rules очень ограничены числом.  И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)

> Совершенно позорное для дебиана место и непонятно, как оно столько прожило.

Policy.  И никуда оно не делось - требования к debian/rules остались прежними (и простыми), а debhelper/cdbs - остались опциональными.

> PS: ещё один пруфлинк как раз в руки пришёл: http://projects.deepnet.cx/trac/debbuild

$ apt-cache search debbuild
$

Упс.  Еще один никому не нужный бедный хомячок...

>> Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета -
>> сильно преувеличены.
>
> Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?

Немного: ~10-20.  Если считать только публичные (т.е. в архиве).  Пакеты разные - есть и сервисы, и библиотеки, и модули (python, octave; guile :D), и всякий ******* на perl/php.

>> Основное время мейнтейнера занимает
> Это всё очень сильно зависит от того, насколько сложен/устоялся упаковываемый.

debian/copyright, по моему опыту - требует наиболее фундаментальных усилий :)

>>> Внимание, вопрос: для каких задач тогда пригоден Debian stable?
>> Вопрос философский.  Зачем человеку компьютер?  Даже не знаю что сказать.
>
> Вот и я не очень понимаю, хотя теоретически несколько use cases и представляю

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

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

Какая свистопляска?  Сервера живут года по три - как минимум.  Да и рабочие станции не меньше.

В тяжелых случаях есть бакпорты.  А вообще - это на совести железячников, если они поддерживают только HEAD релиз в mainline.  Либо это уйдет и драйвера будут, наконец, клепать и для стабильных веток - либо ежики будут и дальше есть кактус.  Ну или из области фантастики: гора двинется к Магомету и начнет когда-нибудь блюсти совместимость хоть на уровне API.

>> Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались.
>
> Да ладно, это всё про выводы.  Хотя также и на заметку
> тем, кто на всякий чих будет советовать Debian testing и говорить,
> мол, сам сижу и всё хорошо.  Т.е. хоть предупреждайте, что
> тогда надо отслеживать...

Предупреждение висит здесь:
http://www.debian.org/releases/
http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en....

Хотя, перед squeeze я имел привычку ставить testing "дома", дабы освоиться пораньше и багов порепортить.

>>> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование
>> Это почему так?  Ручное тестирование кучи пакетов - оно на порядок сложнее,
>> собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.).
>
> Вот ровно потому, что автоматизация тестирования ещё сложнее.

Зато и нужнее, как я пытался выше представить :)

>> Что касается более специфического ПО (научное, для сервера) -
>> там мастеров-ломастеров меньше и интеграция с апстрим лучше
> Ой, вот давайте только без сказок про научное ПО.  Типичный случай
> как раз обратный, увы -- принцип "работает на моей машине" из
> всех щелей :(

Ну, не знаю что у вас было за "научное".  Может из категории "образовательное", скорее?  Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом не стал бы.  Речь шла именно о ПО такого рода.

>> Принцип "when it's ready" - относится к качеству включаемого ПО.  Сдерживающим
>> фактором обновления версий ПО здесь является количество RC багов, для которых
>> автоматическое пакетирование новых релизов - совершенно иррелевантно.
>
> Если такой баг -- апстримный, то может быть и релевантно.  При
> обеспечении возможности протестировать "сборку сбоку".

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

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

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


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 23-Июн-12 02:36 
> Ну все просто.

В следующей серии кто-нить явно вспомнит бронепоезд...

>>> Вы имеете ввиду в Build-Depends?
>> В том числе.
> Ну а ишшо-то где?  В бинарных пакетах dh все давно генерит.

Это радует ;-)

> Кстати, сколько "обычных" - на вашу оценку?

Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)

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

Верите ль, я в курсе.

> И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)

Да мне-то что, это dh и шаблоны такие.

> Упс.  Еще один никому не нужный бедный хомячок...

Вы вот зря с таким attitude.

>> Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?
> Немного: ~10-20.  Если считать только публичные (т.е. в архиве).

Спасибо.

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

С трудом, но верю (скорее последнее, чем первое).

> хостинговый сервер,

Опять же с некоторым трудом.

> вычислительный кластер...

А вот тут не припоминаю вовсе, хотя наверняка всё-таки есть.  И даже есть предположение, почему так.

>> К сожалению, безумная свистопляска с железом
> Какая свистопляска?

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

> В тяжелых случаях есть бакпорты.

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

> Хотя, перед squeeze я имел привычку ставить testing "дома", дабы освоиться пораньше
> и багов порепортить.

Аналогично :)

> не знаю что у вас было за "научное".  Может из категории "образовательное", скорее?

Именно жёстко-научное...

> Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом
> не стал бы.  Речь шла именно о ПО такого рода.

Это скорее "общее", чем именно "научное".  Соответственно при более разностороннем интересе шансы на совместное допинывание до формы шара куда выше, чем при "мне тут посчитать".

>> При обеспечении возможности протестировать "сборку сбоку".
> Так будет только очередной глюкодром: один баг исправили - десять новых сочинили.

Ключевое слово -- "возможности".

> А нехорошие вещи лучше не поощрять.

Эт да.


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 23-Июн-12 11:03 
>> Кстати, сколько "обычных" - на вашу оценку?
> Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)

Буу.  Считайте гнев интернациональным.

Считаем: 1) ./configure && make 2) cmake 3) scons 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9) RubyGems 10) модули апача.

Каждый пример подобного "обычного" сценария конфигурации-сборки-инсталляции - десятки или сотни пакетов в Debian.  Каждый интерпретируемый язык, каждая система с dso-плагинами - имеет что-то свое, уникальное.

>> И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)
> Да мне-то что, это dh и шаблоны такие.

Шаблоны можно и нужно редактировать.

>> Упс.  Еще один никому не нужный бедный хомячок...
> Вы вот зря с таким attitude.

Если это было бы кому-то в Debian надо - было бы в архиве.  Все честно.

>> вычислительный кластер...
> А вот тут не припоминаю вовсе, хотя наверняка всё-таки есть.  И
> даже есть предположение, почему так.

Примеры есть даже в цитированных выше новостях.   В Европе Debian любят, так что "таки есть".

> Мало того, я и на серверах что-то не припоминаю дебианов с ядрами
> не из бэкпортов.  Не расспрашивал (а надо бы), но.

Ну, у меня нет на данный момент ни одного с бекпортами.  Например.

>> не знаю что у вас было за "научное".  Может из категории "образовательное", скорее?
> Именно жёстко-научное...

Настолько, что стыдно упомянуть героев?

>> Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом
>> не стал бы.  Речь шла именно о ПО такого рода.
>
> Это скорее "общее", чем именно "научное".

Это "научное" того уровня, что кладут в дистрибутивы.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 26-Июн-12 14:54 
> Считаем: 1) ./configure && make 2) cmake 3) scons

Да, причём третий уже с натяжкой.

> 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9)
> RubyGems 10) модули апача.

А это всё уже проектоспецифичное (местами даже проще).

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

Да если б сходу помнил (пора уж записывать таковых).  Можете честно сказать "а, ну ясно" -- но просто стараюсь получше руки мыть от такого софта :(


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 26-Июн-12 18:54 
>> Считаем: 1) ./configure && make 2) cmake 3) scons
> Да, причём третий уже с натяжкой.

Ну, гранатами вам не зря грозили...

>> 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9)
>> RubyGems 10) модули апача.
>
> А это всё уже проектоспецифичное (местами даже проще).

Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.  Если уж вы *это* игнорируете...

>>>> не знаю что у вас было за "научное".  Может из категории "образовательное", скорее?
>>> Именно жёстко-научное...
>> Настолько, что стыдно упомянуть героев?
>
> Да если б сходу помнил (пора уж записывать таковых).  Можете честно
> сказать "а, ну ясно" -- но просто стараюсь получше руки мыть
> от такого софта :(

Тогда вам лучше, наверно, отозвать свою критику.


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 26-Июн-12 18:58 
> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.
> Если уж вы *это* игнорируете...

Да не игнорирую, а с таким несколько проще, если только не забыли при создании положить нужные метаданные (как в своё время с гемсами).  Вариативность меньше.

> Тогда вам лучше, наверно, отозвать свою критику.

Скорее "оставить при себе".  Отзывать не буду, кошмарные исходники от того не пропадут.

IIRC тот же WIEN2K тоже не подарок.


"openSUSE на пути к изменению модели разработки"
Отправлено myhand , 28-Июн-12 00:55 
>> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.
>> Если уж вы *это* игнорируете...
> Да не игнорирую, а с таким несколько проще

Может и проще.  Но это совершенно разные системы сборки.  Причем, поддержка одной даст немного для другой.

> IIRC тот же WIEN2K тоже не подарок.

Это вообще пропиетарное ПО.

Я не знаком с ним, к сложалению, предметно.  Можно какие-то подробности?  Гугл заставляет меня верить, что данное ПО работает чуть больше чем на одной машине разработчика ;)


"openSUSE на пути к изменению модели разработки"
Отправлено Michael Shigorin , 28-Июн-12 11:35 
>> IIRC тот же WIEN2K тоже не подарок.
> Это вообще проп[р]иетарное ПО.

Ага.

> Я не знаком с ним, к сложалению, предметно.  Можно какие-то подробности?

Можно поискать по запискам, что с ним приходилось делать -- но это был относительно недавний пример всё тех же старых ощущений: "чем эти люди думали и писали"...

Впрочем, долгого и нудного ругания явно не стоит.


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 23-Июн-12 13:14 
>> Кстати, сколько "обычных" - на вашу оценку?
> Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)

Я все слышу, и граната уже летит :-)


"openSUSE на пути к изменению модели разработки"
Отправлено vle , 21-Июн-12 12:30 
>> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
>> make install - не приучили и не предвидится.
> Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".  
> И этих "обычных" не так уж и много.

- Эй, мужик!
- А!
- Ну ты в курсе.


"openSUSE на пути к изменению модели разработки"
Отправлено кевин , 15-Июн-12 20:44 
а и правильно тамблвид и база меняющаяся раз в год это хорошо.

"openSUSE на пути к изменению модели разработки"
Отправлено Wormik , 16-Июн-12 00:08 
Буду предзаказывать в их Интернет-магазине двуслойный DVD с openSUSE, чтобы поддержать их деньгами.

"openSUSE на пути к изменению модели разработки"
Отправлено Sluggard , 16-Июн-12 12:58 
Почтой России в Задрипански всякие доставляют? Я б тоже купил.

"openSUSE на пути к изменению модели разработки"
Отправлено Sluggard , 16-Июн-12 12:56 
Главное, чтоб чертов яст подхватывал чертовы темы чертовых кед, из коробки. Ну и чтобы сеть не ломали. Так победим! ))

"openSUSE на пути к изменению модели разработки"
Отправлено Тот самый аноним , 16-Июн-12 19:08 
Выпускать пора, а они все еще планы о планах по плану выпуска утрясают

"openSUSE на пути к изменению модели разработки"
Отправлено Julia , 16-Июн-12 19:26 
Удачи разработчикам, но пока не сделают из сюси нормальный дистрибутив - с федоры не слезу! :)

"openSUSE на пути к изменению модели разработки"
Отправлено Денис , 22-Июн-12 10:54 
Сусе не такой плохой дистр как тут многие говорят. Я много узнал и научился пользуясь сусе, и с этим дистром у меня возникало меньше проблем чем с остальными. Но я реально не понимаю почему разрабы рвутся работать именно по этой модели выпусков релизов. Если эта попытка держать себя в узде и не давать слабинку... то мы видим результат. Разрабы сусе уже не первые кто работают по этой системе и как правило не всегда удачно, так что не понимаю почему им нравиться наступать на те же грабли.