форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"openSUSE на пути к изменению модели разработки"	+/–
Сообщение от opennews (ok) on 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.dev/opennews/art.shtml?num=34108
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "openSUSE на пути к изменению модели разработки"	+4 +/–
Сообщение от paulus (ok) on 15-Июн-12, 11:00
а говорили, что у Дебиана не правильный подход :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	78. "openSUSE на пути к изменению модели разработки"	–1 +/–
	Сообщение от Anonim (??) on 15-Июн-12, 18:11
	> Кто сказал, что в дебиан побегут? Самый ненужный дистрибутив. В первой пятерке ненужных дистров сама суся. Он нестабильный, обновляется редко, настраивается через какие-то костыли, которые в итоге не работают, но мешают настроить систему самому. Я вообще удивлен, что у них народу вдруг прибавилось, а не наоборот. Там кроме хамелеона (эмблема) ничего хорошего нет.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	102. "openSUSE на пути к изменению модели разработки"	+4 +/–
	Сообщение от Юрий (??) on 15-Июн-12, 23:51
	> Сам дистр стоит в стороне от мейнстрима в > виде редхата и ее клонов дебиана, убунты, арча и многих прочих. Не смущайтесь, так и говорите, все взяли у редхата накатили свои опознавательные знаки и мейнстрим готов.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	110. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от 1 (??) on 16-Июн-12, 03:50
	Во, сразу видно - звездун, который Арча в глаза не видел. Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD. Так что про клона РХ - мимо лужи.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	113. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Юрий (??) on 16-Июн-12, 11:31
	> Во, сразу видно - звездун, который Арча в глаза не видел. > Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD. > Так что про клона РХ - мимо лужи. Да, да. Ссылку в студию. Где вклад LFS, или им все с неба сыпится. Такой себе Рог Изобилия. Взять взятое, это уже называется собственным. И кто тут звездун. А теперь перечисли, что в Арче от FreeBSD.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	117. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от 1 (??) on 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
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	142. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Юрий (??) on 17-Июн-12, 13:30
	> Джадд собрал Арч с нуля: "Arch is independently developed, was built from > scratch and is not based on any other GNU/Linux distribution." Это > из FAQа. С нуля взяв вклад редхата в ядро, gnome и прочую ерунду.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	143. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от 1 (??) on 17-Июн-12, 14:08
	Оттого, что РХ делает вклад в ядро, гном и т.д. не вытекает, что все дистры - клоны РедХата. Космонавт - один из крупных вкладчиков в KDE, но ты же не станешь утверждать, что Мандрива - клон Убунты. Вопрос на засыпку, чей вклад взял РедХат и чьим клоном он должен быть, если на тот момент момент уже были Slackware и Debian?
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	148. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 18-Июн-12, 10:22
	Хоть одну статью написал/перевел?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	112. "openSUSE на пути к изменению модели разработки"	+2 +/–
	Сообщение от pavlinux (ok) on 16-Июн-12, 05:04
	> вручную править конфиги и удобнее и легче, а потом когда смотришь > конфиги, понимаешь что он их просто изговнял. А нефиг руками туда лазит, либо Yast либо руками. Я знаю, надо вам бинарный формат сделать, чтоб свои кривые руки не сували > Например при настройке виртуальных хостов в апаче, если через него их настраивать, Только мужикам не говори, что Апачь настрагиваешь через гуй, зачмырят как говно последнее. --- В прочем я рад, что моем любимом дистре не прибавится дебилов.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	116. "openSUSE на пути к изменению модели разработки"	+2 +/–
	Сообщение от ILYA INDIGO (ok) on 16-Июн-12, 13:48
	И это пишет тот, кто жаловался, что мол анонимы говном поливают без повода, а сам говно расплёскивает ещё гуше... И это пишет тот, у кого на сервере иксы и без гуйного яста вообще конигурировать не умеет... Апач я года 3 назад когда сузю поставил первый паз конфигурировал через яст, сейчас я даже сеть настраиваю не через него, кроме управления пакетами я его вообще не для чего не использую... Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить! ИМХО
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	162. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от pavlinux (ok) on 21-Июн-12, 21:27
	> И это пишет тот, у кого на сервере иксы и без гуйного > яста вообще конигурировать не умеет... Дятел чтоль? Какой нахёр сервер? У меня на всех серверах Debian. > Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить! YaST не говнит конфиги! Это ты их изговнил когда руками полез.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	34. "openSUSE на пути к изменению модели разработки"	+5 +/–
	Сообщение от Аноним (??) on 15-Июн-12, 14:14
	> а говорили, что у Дебиана не правильный подход :) Самый правильный подход - у убунты: забить болт на баги, выпустить точно в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	56. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 16:41
	> Самый правильный подход - у убунты: забить болт на баги, выпустить точно > в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров. А не факт что лучше: софт с багами или доисторический софт из эпохи мезозоя. Который тоже с багами, баги починеные апстримом там в общем случае не фиксят и только бэкпортят секурити фиксы, а еще как бонус - нужной фичи может не оказаться. Впрочем, у любого дистра и ОС - своих проблем навалом. Можно подумать что это самые хучшие.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	76. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Anonim (??) on 15-Июн-12, 18:08
	Есть дистры лишенные обоих этих проблемм. Роллинг чего-то там
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	167. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Вернат on 25-Июн-12, 02:36
	openSUSE Tumbleweed, оно?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	169. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-12, 11:24
	> openSUSE Tumbleweed, оно? Подобные не для всех в плане время- и трудозатрат за среднепотолочный год пользования.  Т.е. на локалхосте (как вот пишу с сизифа) -- ещё может быть, а на поддерживаемых ради других людей хостах в плывущие ABI лучше не играться.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	93. "openSUSE на пути к изменению модели разработки"	+2 +/–
	Сообщение от lucentcode (ok) on 15-Июн-12, 20:47
	Самый правильный у Arch linux. Вот только неофитам он не по зубам, работая в нём надо головой думать, прежде чем изменять настройки и т.п. Всё ручками делается, и головой... Это не мартышкин труд(кнопконажимательство в Arch не в почёте).
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	99. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Куяврик on 15-Июн-12, 23:11
	и gentoo. я бы вообще рекомендовал неофитам начинать с минимала. те, кто останутся - будут толковыми.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	154. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 19-Июн-12, 08:22
	А вам не кажется, что слишком много чести операционке - постоянно разруливать особенности обновления, подправлять конфиги и т.п.? Лично я предпочитаю тратить свое время на работу более творческую
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	100. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Return76 on 15-Июн-12, 23:12
	>> а говорили, что у Дебиана не правильный подход :) > Самый правильный подход - у убунты: забить болт на баги, выпустить точно > в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров. Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост - через 3 года "это" будет стоять у них на серверах! Будете спорить?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	106. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от myhand (ok) on 16-Июн-12, 01:17
	> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu? Потому что таких "сисадминов" надо с работы гнать?  :)  Угадал?  На работе они, понимаешь, Debian настроили - а дома десктоп из него сделать ниасилили. А лучше - отучаемся говорить за "всех".
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	152. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Куяврик on 18-Июн-12, 16:07
	> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов > на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост > - через 3 года "это" будет стоять у них на серверах! > Будете спорить? Нет. В массовые решения всегда вылезают кхм... самая лёгкие фракции. Из всех ОС - Windows. Из всех линуксов - убунта. Ну и далее.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	123. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 16-Июн-12, 23:35
	> Его эффективность наглядно подтверждается рейтингом популярности дистров. Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на Mint...
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	153. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Куяврик on 18-Июн-12, 16:08
	>> Его эффективность наглядно подтверждается рейтингом популярности дистров. > Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на > Mint... +10 к троллингу
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	156. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 20-Июн-12, 00:24
	> +10 к троллингу Да какой троллинг, я когда-то украинское зеркало дистровотча поддерживал.  До сих пор иногда и поглядываю. Другое дело, что метрика эта сама по себе тоже условная, хотя и не самая плохая -- за последние лет десять в первом приближении скорее коррелировала.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

6. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Mr.Yudgin on 15-Июн-12, 11:15
Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы mono они из него выпилили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 11:34
	> Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для > сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и > причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы > mono они из него выпилили. Кто тебя заставляет mono ставить или зузю? Нет выбора?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	85. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Аноним (??) on 15-Июн-12, 19:41
	во-первых, правильно пишется openSUSE. во-вторых, назови хоть один SUSE-специфичный пакет зависимый от mono?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

13. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Reyn on 15-Июн-12, 11:43
6 месяцев, 8, 12... Вместо того, чтобы за цифирками гнаться, может уже пора задуматься об LTS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от I am (??) on 15-Июн-12, 12:00
	Да разрабам opensuse это скучно.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "openSUSE на пути к изменению модели разработки"	+3 +/–
	Сообщение от кверти on 15-Июн-12, 12:15
	не все так просто. для этого есть SLE. если сделать LTS, то это ударит по SLE, и в свою очередь ударит по самим разрабам, так как они в своем большинстве и есть разрабы как openSUSE, так и SLE
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	20. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от I am (??) on 15-Июн-12, 12:38
	> не все так просто. для этого есть SLE. если сделать LTS, то > это ударит по SLE, и в свою очередь ударит по самим > разрабам, так как они в своем большинстве и есть разрабы как > openSUSE, так и SLE Для хеппи энда не хватает только того, что бы обновления для SLE были доступны. Хотя в целом цена на подписку там в разы меньше чем у шапки, но тем не менее.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	17. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от filosofem (ok) on 15-Июн-12, 12:23
	см. SUSE Linux Enterprise
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 12:34
	У них есть LTS версия. Вроде бы Evergreen называется.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	63. "openSUSE на пути к изменению модели разработки"	–1 +/–
	Сообщение от Михрютка on 15-Июн-12, 17:11
	эвергрин не лтс, эвергрин - костыль для подпирания систем, которые хозяева боятся обновлять на новые версии этого цир^W^W OpenSUsE.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	64. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от ппппппяяя on 15-Июн-12, 17:12
	Вместо того как за циферками гнаться, они думают как бы сделать дистрибутив лучше, ищут решения проблем.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	176. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Aquarius (ok) on 22-Сен-12, 22:30
	какая тонкая ирония
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	86. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 19:42
	для тех кто в танке - есть Evergreen.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

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

	87. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 19:44
	Tumbleweed нет нужных пакетов? а ты их туда засабмитил?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "openSUSE на пути к изменению модели разработки"	+4 +/–
Сообщение от хамелеон on 15-Июн-12, 12:37
Молодцы! Если сыро ну и правильно что не хотят выпускать релиз.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "openSUSE на пути к изменению модели разработки"	–5 +/–
	Сообщение от sasa (??) on 15-Июн-12, 15:25
	> Если сыро ну и правильно что не хотят выпускать релиз. Ну и будет еще одна слака, потом серваки будут отключать - один фик нечего обновлять а потом обнаружат что это даже не волнует никого - потому что и обновления никому не нужны - все нормальные люди давно на Ubuntu перешли.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	124. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 16-Июн-12, 23:40
	> все нормальные люди давно на Ubuntu перешли. Ну привет вам, "нормальные". Интересно, через сколько лет Шатлворт наберётся смелости сказать, что полугодовой цикл был чисто маркетинговым кидаловом...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

26. "openSUSE на пути к изменению модели разработки"	+6 +/–
Сообщение от Аноним (??) on 15-Июн-12, 12:52
А можно просто пойти по пути Ubuntu - игнорировать баги и выпускать релиз as is точно в срок.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "openSUSE на пути к изменению модели разработки"	+1 +/–
Сообщение от Аноним (??) on 15-Июн-12, 13:02
В могилу оно катится. В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят за пару дней. Даже исправления безопасности выходят с задержкой в недели. А в официально не поддерживаемых репах из obs половина пакетов либо не собираются, либо не работают.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 14:13
	В убунте та же фигня, и ничего, живее всех живых.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	57. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 16:42
	> В убунте та же фигня, и ничего, живее всех живых. Да ладно вам, в убунте свои баги они чинят а апстримные чинят апстримы :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 14:37
	Грустно соглашаюсь.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	38. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от pavlinux (ok) on 15-Июн-12, 15:02
	> В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят > за пару дней. Даже исправления безопасности выходят с задержкой в недели. Оплачивал саппорт? Разрабы обязаны жрать ночами доширак, но выпустить патч через час анонса?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	49. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от SubGun (ok) on 15-Июн-12, 16:03
	Оплачивал саппорт? Про OpenSuSe разговор, а не про SLES.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	88. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 19:46
	> Оплачивал саппорт? > Про OpenSuSe разговор, а не про SLES. поэтому, отправь патч сам!
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	101. "openSUSE на пути к изменению модели разработки"	–1 +/–
	Сообщение от pavlinux (ok) on 15-Июн-12, 23:20
	> Оплачивал саппорт? > Про OpenSuSe разговор, а не про SLES. Так тем более, был бы SLES можно было ещё предъявлять. А так, извините, скажите спасибо, что вообще... :)
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	105. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Юрий (??) on 16-Июн-12, 00:19
	> Про OpenSuSe разговор А кто это. S.u.S.E Linux SuSE Linux SUSE Linux openSUSE Как то так.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

39. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от pavlinux (ok) on 15-Июн-12, 15:06
На Сентябрь это хорошая мысль, но лучше на вторую неделю октября!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "openSUSE на пути к изменению модели разработки"	–5 +/–
Сообщение от pavlinux (ok) on 15-Июн-12, 15:21
Макс, делай коменты только авторизированных, хоть через вконтакт, твытыр, фейсб... Заипли уже анонимы, сайт в какашку превратился. Каждая тема превращается в срач. Обвинения и недовольства вообще никак не аргументируются - вот говно и всё.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 16:44
	> хоть через вконтакт, твытыр, фейсб... Ты действительно этого хочешь? Натурально из вконтакта? :)
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	61. "openSUSE на пути к изменению модели разработки"	+3 +/–
	Сообщение от qux (ok) on 15-Июн-12, 17:02
	Конечно, во всем анонимы виноваты. А главное, никто не сомневается, что как только этот ник исчезнет, все сразу станет как надо.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	62. "openSUSE на пути к изменению модели разработки"	+2 +/–
	Сообщение от Аноним (??) on 15-Июн-12, 17:11
	> Обвинения и недовольства вообще никак не аргументируются - вот гoвно и всё. Это между прочим и твоих коментов касается: в 50% случаев столь же неаргументированные набросы и высeры. Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	66. "openSUSE на пути к изменению модели разработки"	+2 +/–
	Сообщение от Andrey Mitrofanov on 15-Июн-12, 17:21
	> Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных? Он же зарегистрированный! Если анонимов не, то он потребует вернуть деньги.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	168. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Вернат on 25-Июн-12, 02:39
	Друзья, выездная сессия ЛОРа? :)
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	94. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от ILYA INDIGO (ok) on 15-Июн-12, 20:47
	Ну комменты от социалок это вопрос спорный, но вот только от зарегенных это нужно!
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	125. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Июн-12, 23:42
	> но вот только от зарегенных это нужно! Милости просим на linux.kiev.ua, там ровно так и есть. Через какое-то время согласился, что Максим был прав.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

47. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от mf (ok) on 15-Июн-12, 15:42
Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается. Тамблевид - слишком нестабилен, с моей точки зрения, фактори - вообще транк какой-то. Даже пакман выглядит серьёзнее. Ведро тамблевида 2 из 3 раз имеет проблемные драйвера для моего оборудования. Поддерживаю Стефана - так жить нельзя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от SubGun (ok) on 15-Июн-12, 16:04
	> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается. Хотите стабильности - пользуйте SLES.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

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

	104. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Юрий (??) on 16-Июн-12, 00:11
	> ПО стало больше и нужны новые механизмы для формирования стабильного дистрибутива. Откуда. Просто одной задницей на десяти стульях не сесть. Хотят быть хорошими для всех, а оно не получилось. kde3, kde4, gnome2, gnome3, lxde, xfce, enlightenment. freetype1 - сколько лет уже его не существует, а его все тянут. Для совместимости со сферическим астралом, не иначе. Отсюда и качество стремящееся к нулю.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	126. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Июн-12, 23:45
	> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается. Пользуюсь сизифом более 10 лет.  Некоторые поднятые вопросы живо напомнили и то, что в devel@altlinux обсуждалось -- но в общем и в целом сейчас со стабильностью скорее хорошо, кроме времён подвижек тектонических плит вроде xorg. Стопка пруфов доступна на http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima.../ :)
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	131. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от mf (ok) on 17-Июн-12, 00:27
	Миша, я совето-русо-путо-фоб не могу перейти на альт :) Но наверное в виртуалке поставлю...
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	133. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июн-12, 00:31
	> Но наверное в виртуалке поставлю... Да не, не стоит, если имеющееся устраивает.  Ссылка была упреждающей для иных любителей подоказывать ;-) Кстати, первый экспериментальный образ для виртуалки сегодня тоже выпек.  Осталось купить турбореактивные двигатели у англичан -- ой, потырить конверсию из kiwi -- и можно взлетать!
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

52. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Аноним (??) on 15-Июн-12, 16:11
Мой вопрос немного не в тему, но все же. Скажите можно ли переносить патчи между дистрибутивами? Например, есть некоторая функция в виде патча, но в другом дистрибутиве, могу ли я сделать пакет, для другого дистрибутива используя там этот патч? Я так же хочу после выложить этот пакет для общего доступа в виде исходного кода и бинарного пакета. Буду благодарен за компетентный ответ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 16:13
	Этот же вопрос интересует и к патчам исправляющим те или иные ошибки
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

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

	75. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 18:05
	> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы > могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы > бы таких вопросов не задавали. Поэтому вам - нельзя. За то, что ответили на мой вопрос, спасибо. А на счет всего остального: поменьше желчи
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	177. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Aquarius (ok) on 22-Сен-12, 22:39
	>> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы >> могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы >> бы таких вопросов не задавали. Поэтому вам - нельзя. > За то, что ответили на мой вопрос, спасибо. А на счет всего > остального: поменьше желчи теперь совсем нельзя P.S. 100% не желчь
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	60. "openSUSE на пути к изменению модели разработки"	–2 +/–
	Сообщение от свищ on 15-Июн-12, 16:54
	используйте obs. автоматического создания патчей нет, конечно, но возможность централизованно иметь пачку патчей для всех популярных дистрибутивов в одном месте, собирать, тестировать и раздавать в виде репозиториев
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	73. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 15-Июн-12, 17:50
	Спасибо вам за ответ. Собственно я и хочу бэкпортировать некоторые функции с одного дистрибутива в другой. Как это сделать у меня трудностей не возникает, интересовал лишь вопрос законности применения патчей разработчиков одного дистрибутива в другом дистрибутиве. Если я, верно вас пониманию, то получается если я переношу результат работы одного сообщества в другое сообщество то в данном случае никаких препятствий и ограничений нет?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	118. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 16-Июн-12, 18:25
	Лицензию смотри к патчам.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	134. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 17-Июн-12, 02:54
	Если не сложно, покажите для примера где такая используется. Конечно в OpenSUSE по моему видел, но это скорее относится к spec содержимому.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	127. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Июн-12, 23:49
	> Скажите можно ли переносить патчи между дистрибутивами? Как правило, да -- но в каждом конкретном случае могут возникнуть свои нюансы (от разных веток софта, который упаковывается, до разного взаимодействия с окружением). Например, сегодня стырил три гентушных патча и один дебиановский, поправляя сборку photoprint, и заодно в апстрим закинул.  Всё просто легло, хоть и чуть разные версии. Так что лучше конкретизировать. PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи.  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к легитимному применению.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	128. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 17-Июн-12, 00:12
	> PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи. "Вы мне запрещаете?" (c) >  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к > легитимному применению. Что не обязывает патчи лицензий не иметь вовсе.  Или иметь совпадающую с исходниками. В Debian большая часть пакетов (я не знаю контрпримеров) имеет на debian/* (в т.ч. и патчи) - в качестве лицензии варианты GPL.  А в архиве есть исходники с самыми разнообразными лицензиями. Use common sense, Luke!
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	132. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июн-12, 00:28
	> Use common sense, Luke! common sense как раз и подсказывает, что лицензия на патч (особенно тривиальный) -- такая же, как и на тот исходник, разницу с созданной на основе которого производной работой он и описывает. Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на первой же софтине с GPL incompatible license -- но такое бы явно уже вскрылось.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	136. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 17-Июн-12, 10:39
	> common sense как раз и подсказывает, что лицензия на патч (особенно тривиальный) > -- такая же, как и на тот исходник, разницу с созданной > на основе которого производной работой он и описывает. Не логично.  Как на остальной кусок работы по пакетированию (сдержимое debian/, к примеру).  Это - логично. > Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на > первой же софтине с GPL incompatible license -- но такое бы > явно уже вскрылось. Да чего уж тут "занудство".  Также, вполне логично - людям лень выписывать на каждый debian/patches/01_bla-bla.patch - отдельный крендель в copyright (а сабмиттеры патчей не настаивают на откровенном legal-маразме).  Вот и лепят на весь debian-stuff - одну лицензию.  Естественно, она обязана быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	140. "(offtopic) права на патчи и инструкции по сборке"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июн-12, 12:26
	>> лицензия на патч (особенно тривиальный) -- такая же, как и на тот исходник, >> разницу с созданной на основе которого производной работой он и описывает. > Не логично. Исходники и патчи -- данные, debian/{copyright,rules} -- метаданные.  Почему нелогично? Я могу и более строго пояснить, но это будет очередной офтопик. > Вот и лепят на весь debian-stuff - одну лицензию.  Естественно, она обязана > быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG. Так это ж совсем другое дело. :) // кажется, опять перезанудствовал дебианщиков -- брр, срочно на озеро
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

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

	158. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 20-Июн-12, 12:04
	> Итог = Грустно слышать :(  Может, хоть багу на тот же Pg им повесите, вдруг переобсудят?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	159. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Andrey Mitrofanov on 20-Июн-12, 13:11
	>> Итог = > Грустно слышать :(  Может, хоть багу на тот же Pg им > повесите, вдруг переобсудят? Да, всё уже переобсужено и починено. http://bugs.debian.org/607907 Чтоб GNU readline _фактически использовался в pgsql, его нужно доставить в систему, т.к. его нет в зависимостях пакета, а бинарник собирается с _бинарно-_совместимым editline^Wlibedit из-за лицензионных ограничений, насколько я помню, таки _openssl. Это (установка целого одного пакета руками), конечно, славная причина "свалить с" и "трахаться с". ///Да, конечно, я опять ничего не понял.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

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

	135. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Аноним (??) on 17-Июн-12, 03:04
	>[оверквотинг удален] > Как правило, да -- но в каждом конкретном случае могут возникнуть свои > нюансы (от разных веток софта, который упаковывается, до разного взаимодействия с > окружением). > Например, сегодня стырил три гентушных патча и один дебиановский, поправляя сборку photoprint, > и заодно в апстрим закинул.  Всё просто легло, хоть и > чуть разные версии. > Так что лучше конкретизировать. > PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи. >  Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к > легитимному применению. Спасибо вам за ответ, вы реально мне помогли. На самом деле, некоторое время назад, я видел в Gentoo патчи от Fedora. И единственное что было приложено к патчу, это текст, мол взято из федоры. Я пошел таким же путем, пишу источник патча точнее имя пакета с которого я его взял. Свои патчи оставляю без комментариев, думаю, что оно и так ясно кто их сделал. Еще раз спасибо за помощь
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	137. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от myhand (ok) on 17-Июн-12, 10:47
	> Свои патчи оставляю без комментариев, думаю, > что оно и так ясно кто их сделал. И напрасно. Вспомните трамвай Аннушки!  И будет следующий мейнтейнер гадать откуда взялся патч и нафига он вообще нужен. В дебиане для подобного есть (опциональный) стандарт (http://dep.debian.net/deps/dep3/) метаинформации к патчам.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	139. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 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
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

74. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от petyanamlt (ok) on 15-Июн-12, 17:51
Правильно делают, версия 12,1 глюкавая получилась.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

77. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Аноним (??) on 15-Июн-12, 18:11
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается > Правильно делают, версия 12,1 глюкавая получилась. Хоть тут и критикуют подход Каноникла к выпуску релизов, но нельзя не согласится со сказанным выше - качество релизов суси неуклонно снижается. 12.1 ужасен. Не припомню ни одного случая, чтобы после успешной установки с Livecd система после grub вылетала в kernel panic, на другом компе все работает, но печалит многочисленными багами и тормознутостью. В убунту с такими эпичными багами не сталкивался.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

80. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Aceler (ok) on 15-Июн-12, 18:32
Передайте им, что при наличии OBS репозитарий им просто не нужен. Соответственно, никаких проблем со сроками — главное стабилизировать основное окружение, остальное собирать отдельно. Релиз делать через месяц после стабилизации, чтобы не оказаться с пустым набором софта. Правда, роллинг в этом случае совсем не гарантирован.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	81. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от mf (ok) on 15-Июн-12, 19:03
	Одному мне показалось что Вы показали Windows-way?
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	83. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Aceler (ok) on 15-Июн-12, 19:07
	> Одному мне показалось что Вы показали Windows-way? Увы, нет, очень многие путают микрорепозитарии а-ля PPA или OBS (а теперь ещё и ABF) с нестандартными инсталляционными пакетами, как это принято в Windows, или в лучшем случае с MSI/DMG. Однако это не так, репозитарии остаются репозитариями, вне зависимости от того, на сколько они большие.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	84. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от mf (ok) on 15-Июн-12, 19:34
	Вы пока разницы не показали. Если программа не пользуется тем, что в системе, а тащит с собой - это либо тестовая программа, либо виндовс.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	107. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от Юрий (??) on 16-Июн-12, 01:20
	Вот в этом их и проблема, они не могут определится с основным окружением. Набрали горы барахла и стыкуют его с новым gcc-4.7.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

82. "openSUSE на пути к изменению модели разработки"	–3 +/–
Сообщение от mihalych on 15-Июн-12, 19:06
> Например, после обновления версии сам пакет может работать без проблем, но работоспособность связанных с ним пакетов часто нарушается. Поэтому gentoo forever!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

89. "openSUSE на пути к изменению модели разработки"	+1 +/–
Сообщение от vle (ok) on 15-Июн-12, 20:17
> В качестве одного из вариантов, предложенных > Сетфаном, называется уход от плановой подготовки > новых версий, которые сейчас выпускаются строго > раз в 8 месяцев, к модели без жестких планов, основанной > на готовности дистрибутива, или к заметному расширению сроков подготовки новых версий, > например, переходу к выпуску релизов раз в год. Я не понял, а где Шигорин со своим "Да! А я им это еще n лет назад говорил!"?  :-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	129. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июн-12, 00:17
	>> например, переходу к выпуску релизов раз в год. > Я не понял, а где Шигорин со своим > "Да! А я им это еще n лет назад говорил!"?  :-) Как где, в архиве: http://www.opennet.dev/openforum/vsluhforumID3/50315.html#19 (n > 3)
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

90. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от ILYA INDIGO (ok) on 15-Июн-12, 20:32
>переход к модели непрерывного цикла обновления пакетной базы (Rolling-release) Вот это реально нам и надо, как в Arch и никаких проблем. >...перенести релиз на середину сентября...на следующей неделе...перехода на фазу заморозки... Это и так устарелый пакеты (libreofice php postqresql mariadb mysqlworkbench geany memcashed) ещё и замарозят на 3 месяца... Не я точно валю на Arch!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Игорь (??) on 15-Июн-12, 20:41
Я тоже пользуюсь openSUSE более 5 лет. Часто ради собственного интереса ставлю на попробовать Бета-версии. Проблема снижения качества отладки дистрибутива перед релизом мне понятна. Я согласен с тем, чтобы релизы выходили реже, например раз в 10 месяцев, но более качественные. Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	130. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июн-12, 00:19
	> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее... См. тж. анализ Игоря Власенко: http://ftp.linux.kiev.ua/pub/conference/peers/lviv/2012/Vlas...
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	138. "openSUSE на пути к изменению модели разработки"	–1 +/–
	Сообщение от myhand (ok) on 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 будет?).  И т.д.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	141. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 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: пришёл.  Коллеги, лето на дворе, хватит втыкать в монитор!
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	144. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 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: > Коллеги, лето на дворе На чужом дворе мож-т и лето.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	145. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 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: Коллеги, лето на дворе > На чужом дворе мож-т и лето. Дык приезжайте ;-)  Аж подгорел малость за час-полтора...
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	146. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от vle (ok) on 17-Июн-12, 22:29
	> По крайней мере watch-файлики изобрели в дебиане -- стало > быть, и те люди скорее всего предполагали, что увеличить циферку и > попытаться собрать может и робот Аналог "watch-файликов" был ВСЕГДА в source-based системах, т.е. примерно с середины/второй половины 90-х в *BSD.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	147. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 18-Июн-12, 00:13
	> Аналог "watch-файликов" был ВСЕГДА в source-based системах О, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	149. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от vle (ok) on 18-Июн-12, 12:13
	>> Аналог "watch-файликов" был ВСЕГДА в source-based системах > О, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge. MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=dict/} \                 ftp://ftp.dict.org/pub/dict/
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	150. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 18-Июн-12, 14:19
	>>> (заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то. >> Ну, "караул" на уровне Инго - не кричат. > > Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel > team). С разработчиком ядра логично сравнивать разработчиков ядра. >> Не знаю что там до вас долетае... > Например, необходимость прописывать зависимости ручками. Вы имеете ввиду в Build-Depends?  Но телепатии пока не изобрели и разработчиков ходить строем с чем-то стандартным типа ./configure && make && make install - не приучили и не предвидится. Увы, доклад не показывает пути решения данной проблемы.  Даже намека. > Я к тому, что есть огромное поле того, что люди собирают сами > предоставляемыми сторонними инструментами.  И CPAN тут -- это только верхушка > айсберга проблемы модулей для скриптовых языков, увы.  Там хоть базовая > версия относительно одна. Я указывал правильное решение: если люди не хотят собирать сами - пусть попросят.  Тех же debian-perl@.  Зачем автоматически класть в дистрибутив что-то "абы было"? >> причем подготовка пакета достаточно хорошо автоматизирована. > Ну с тех пор как тот кромешный ужас на старом dh в > debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой > хотя бы ;-) Он не был и до.  Существовали (и продолжают) инструменты, облегчающие подготовку первоначальной версии пакета (всякие dh_make).  См. вашу же новость http://www.opennet.dev/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" - совершенно иной принцип, иная цель. Можно ли совместить их в одном дистрибутиве?  Думаю, здесь есть ресурс, который пока задействован в наименьшей степени - это собственно апстрим.  Там, где он активно взаимодействует с мейнтейнерами в дистрибутиве (или сам играет эту роль) - с версиями проблем нет.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	151. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от vle (ok) on 18-Июн-12, 14:51
	> А в ALT есть аналог, к примеру, puiparts?  А lintian Миша, я уже не один с такими "странными" вопросами ;-) У вас rpm-щиков этого похоже ни у кого нет. В pkgsrc pkglint ну очень дотошный, и это очень удобно.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	155. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 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...
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	160. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 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" - совершенно иной принцип, иная цель. > > Это заодно принцип минимизации форка.  Хорошо сочетается с предыдущим тогда, когда > апстрим понимает, поддерживает и реализует подход со стабильными ветками (хотя бы > одной, лучше двумя). Если глюкодром апстрим не интересен - рано или поздно стабильными ветками он заинтересуется.  А нехорошие вещи лучше не поощрять.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	164. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 23-Июн-12, 02:36
	> Ну все просто. В следующей серии кто-нить явно вспомнит бронепоезд... >>> Вы имеете ввиду в Build-Depends? >> В том числе. > Ну а ишшо-то где?  В бинарных пакетах dh все давно генерит. Это радует ;-) > Кстати, сколько "обычных" - на вашу оценку? Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева) > А надо класть не "когда понадобится", а когда это на это что-то найдется мейнтейнер. > Вот потому и не нули.  Собрать пакет - это только самый первый и простой шаг. Верите ль, я в курсе. > И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;) Да мне-то что, это dh и шаблоны такие. > Упс.  Еще один никому не нужный бедный хомячок... Вы вот зря с таким attitude. >> Можно поинтересоваться, сколько пакетов Вы первоначально подготовили? > Немного: ~10-20.  Если считать только публичные (т.е. в архиве). Спасибо. >> Вот и я не очень понимаю, хотя теоретически несколько use cases и представляю > Да сколько угодно.  Десктоп (от разработчика ядра до домохозяйки), С трудом, но верю (скорее последнее, чем первое). > хостинговый сервер, Опять же с некоторым трудом. > вычислительный кластер... А вот тут не припоминаю вовсе, хотя наверняка всё-таки есть.  И даже есть предположение, почему так. >> К сожалению, безумная свистопляска с железом > Какая свистопляска? С выпуском железа, не живущего на имеющихся драйверах добавлением PCI ID-шек. > В тяжелых случаях есть бакпорты. Мало того, я и на серверах что-то не припоминаю дебианов с ядрами не из бэкпортов.  Не расспрашивал (а надо бы), но. > Хотя, перед squeeze я имел привычку ставить testing "дома", дабы освоиться пораньше > и багов порепортить. Аналогично :) > не знаю что у вас было за "научное".  Может из категории "образовательное", скорее? Именно жёстко-научное... > Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом > не стал бы.  Речь шла именно о ПО такого рода. Это скорее "общее", чем именно "научное".  Соответственно при более разностороннем интересе шансы на совместное допинывание до формы шара куда выше, чем при "мне тут посчитать". >> При обеспечении возможности протестировать "сборку сбоку". > Так будет только очередной глюкодром: один баг исправили - десять новых сочинили. Ключевое слово -- "возможности". > А нехорошие вещи лучше не поощрять. Эт да.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	165. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 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 и т.п. - я подобным образом >> не стал бы.  Речь шла именно о ПО такого рода. > > Это скорее "общее", чем именно "научное". Это "научное" того уровня, что кладут в дистрибутивы.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	170. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 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) модули апача. А это всё уже проектоспецифичное (местами даже проще). >>> не знаю что у вас было за "научное".  Может из категории "образовательное", скорее? >> Именно жёстко-научное... > Настолько, что стыдно упомянуть героев? Да если б сходу помнил (пора уж записывать таковых).  Можете честно сказать "а, ну ясно" -- но просто стараюсь получше руки мыть от такого софта :(
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	171. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 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) модули апача. > > А это всё уже проектоспецифичное (местами даже проще). Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.  Если уж вы *это* игнорируете... >>>> не знаю что у вас было за "научное".  Может из категории "образовательное", скорее? >>> Именно жёстко-научное... >> Настолько, что стыдно упомянуть героев? > > Да если б сходу помнил (пора уж записывать таковых).  Можете честно > сказать "а, ну ясно" -- но просто стараюсь получше руки мыть > от такого софта :( Тогда вам лучше, наверно, отозвать свою критику.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	172. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-12, 18:58
	> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан. > Если уж вы *это* игнорируете... Да не игнорирую, а с таким несколько проще, если только не забыли при создании положить нужные метаданные (как в своё время с гемсами).  Вариативность меньше. > Тогда вам лучше, наверно, отозвать свою критику. Скорее "оставить при себе".  Отзывать не буду, кошмарные исходники от того не пропадут. IIRC тот же WIEN2K тоже не подарок.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	173. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от myhand (ok) on 28-Июн-12, 00:55
	>> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан. >> Если уж вы *это* игнорируете... > Да не игнорирую, а с таким несколько проще Может и проще.  Но это совершенно разные системы сборки.  Причем, поддержка одной даст немного для другой. > IIRC тот же WIEN2K тоже не подарок. Это вообще пропиетарное ПО. Я не знаком с ним, к сложалению, предметно.  Можно какие-то подробности?  Гугл заставляет меня верить, что данное ПО работает чуть больше чем на одной машине разработчика ;)
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	174. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Michael Shigorin (ok) on 28-Июн-12, 11:35
	>> IIRC тот же WIEN2K тоже не подарок. > Это вообще проп[р]иетарное ПО. Ага. > Я не знаком с ним, к сложалению, предметно.  Можно какие-то подробности? Можно поискать по запискам, что с ним приходилось делать -- но это был относительно недавний пример всё тех же старых ощущений: "чем эти люди думали и писали"... Впрочем, долгого и нудного ругания явно не стоит.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	166. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от vle (ok) on 23-Июн-12, 13:14
	>> Кстати, сколько "обычных" - на вашу оценку? > Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева) Я все слышу, и граната уже летит :-)
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	161. "openSUSE на пути к изменению модели разработки"	+1 +/–
	Сообщение от vle (ok) on 21-Июн-12, 12:30
	>> и разработчиков ходить строем с чем-то стандартным типа ./configure && make && >> make install - не приучили и не предвидится. > Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".   > И этих "обычных" не так уж и много. - Эй, мужик! - А! - Ну ты в курсе.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

92. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от кевин on 15-Июн-12, 20:44
а и правильно тамблвид и база меняющаяся раз в год это хорошо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

103. "openSUSE на пути к изменению модели разработки"	+2 +/–
Сообщение от Wormik (ok) on 16-Июн-12, 00:08
Буду предзаказывать в их Интернет-магазине двуслойный DVD с openSUSE, чтобы поддержать их деньгами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	115. "openSUSE на пути к изменению модели разработки"	+/–
	Сообщение от Sluggard (ok) on 16-Июн-12, 12:58
	Почтой России в Задрипански всякие доставляют? Я б тоже купил.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

114. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Sluggard (ok) on 16-Июн-12, 12:56
Главное, чтоб чертов яст подхватывал чертовы темы чертовых кед, из коробки. Ну и чтобы сеть не ломали. Так победим! ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

119. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Тот самый аноним on 16-Июн-12, 19:08
Выпускать пора, а они все еще планы о планах по плану выпуска утрясают
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

121. "openSUSE на пути к изменению модели разработки"	–2 +/–
Сообщение от Julia (??) on 16-Июн-12, 19:26
Удачи разработчикам, но пока не сделают из сюси нормальный дистрибутив - с федоры не слезу! :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

163. "openSUSE на пути к изменению модели разработки"	+/–
Сообщение от Денис (??) on 22-Июн-12, 10:54
Сусе не такой плохой дистр как тут многие говорят. Я много узнал и научился пользуясь сусе, и с этим дистром у меня возникало меньше проблем чем с остальными. Но я реально не понимаю почему разрабы рвутся работать именно по этой модели выпусков релизов. Если эта попытка держать себя в узде и не давать слабинку... то мы видим результат. Разрабы сусе уже не первые кто работают по этой системе и как правило не всегда удачно, так что не понимаю почему им нравиться наступать на те же грабли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема