Разработчики проекта KDE рассматривают (http://permalink.gmane.org/gmane.comp.kde.devel.core/79888) вопрос о сокращении цикла подготовки значительных выпусков. В соответствии с опубликованным предложением (http://community.kde.org/KDE_Core/ReleasesProposal), релизы планируется формировать раз в три месяца, что позволит ускорить доведение новых возможностей до пользователей и упростить формирование выпуска за счёт сокращения числа изменений и введения единой заморозки для всех компонентов KDE.
По мнению авторов предложения ускорить темп разработки можно за счёт сокращения фазы тестирования - для обеспечения стабильности предлагается поддерживать master-ветку в постоянно стабилизированном и готовом к релизу виде. Два месяца предлагается уделить приёму новых возможностей, а третий месяц потратить на формирование релиза и бета-тестирование. Таким образом, значительные выпуски будут выходить чаще и включить только возможности, готовые для использования в текущий момент. Предложение будет рассмотрено на ближайшем саммите разработчиков и в случае одобрения будет применено в процессе подготовки KDE SC 4.12.
Против предложения уже выступили (http://permalink.gmane.org/gmane.comp.kde.devel.core/79924) представители проекта openSUSE, которые указали на том, что для поддержания пакетов с KDE в дистрибутиве оптимальным является текущий шестимесячный цикл разработки. При более частом формировании релизов нагрузка на мэйнтейнеров пакетов заметно возрастёт, что может отрицательно сказаться на качестве интеграции KDE в дистрибутив. Кроме того, значительные релизы раз в три месяца плохо синхронизируются с типичным 6- и 8-месячными циклами подготовки дистрибутивов.
В противовес авторы инициативы указывают на то, что релизы будут содержать меньше изменений и соответственно меньше ошибок, что скажется на упрощении процесса тестирования. Дистрибутивы также смогут включать в свой состав более свежие версии KDE, так как можно будет избежать ситуации когда очередной значительный выпуск KDE выходит после заморозки пакетной базы и дистрибутив вынужден поставлять устаревшее окружение, так как не успевает интегрировать новую версию.
URL: http://permalink.gmane.org/gmane.comp.kde.devel.core/79888
Новость: http://www.opennet.ru/opennews/art.shtml?num=37385
> можно будет избежать ситуации когда очередной значительный выпуск KDE выходит после заморозки пакетной базы и дистрибутив вынужден поставлять устаревшее окружение, так как не успевает интегрировать новую версию.Избежать - нельзя. Смягчить - можно. Но нужно ли?
Не нужно, пускай будет как есть.
Думаю, любой вариант имеет недостатки и достоинства. Так что остаётся основной критерий - надо так, как интересно разработчикам. Если им не будет интересно, то вообще ничего не будет :)
>надо так, как интересно разработчикамGnome 3 так разрабатывался и разрабатывается. И, ИМХО, KDE не стоит идти той же дорогой.
> Gnome 3 так разрабатывался и разрабатывается.Так разрабатываются все открытые проекты, начиная с Linux.
Кроме тех, которые контролируются какой-то одной компанией (mysql, mir и т.д.)> И, ИМХО, KDE не стоит идти той же дорогой.
Спорно.
Особенно если учесть, что они шли ею всю свою историю.
>> Gnome 3 так разрабатывался и разрабатывается.
> Так разрабатываются все открытые проекты, начиная с Linux.
> Кроме тех, которые контролируются какой-то одной компанией (mysql, mir и т.д.)Сейчас Gnome контролируется практически одной компанией — Red Hat.
Боюсь, что даже редхат не контролирует этих укурков.
Сейчас там на полном серьезе обсуждают использование MATE как дефолтной оболочки в RHEL7.
> Боюсь, что даже редхат не контролирует этих укурков.
> Сейчас там на полном серьезе обсуждают использование MATE как дефолтной оболочки в
> RHEL7.А почему тогда редхат платит этим укуркам зарплату?. И вообще, они же вроде хотели Gnome 3 в "классическом" режиме для RHEL7.
> А почему тогда редхат платит этим укуркам зарплату?Видимо, еще надеются, что они смогут повторить успех гном2.
> И вообще, они же вроде хотели Gnome 3 в "классическом" режиме для RHEL7.
Это альтернативный вариант. На случай, если гном3 не совсем доломали.
Но MATE в штатных репах федоры 19, и даже наличие сборки ф19 с этим DE по умолчанию - очень сильно намекают.
ну а самое интересное - циферьки в версии будут щелкать?
Спорно как-то. Я не разраб KDE, но какие значительные изменения в четвертой ветке предполагаются? Это столько разрабатывали и когда подошли к концу цикла зачесалось в заднице? Не так уж много изменений было в последних выпусках. Ну, пусть думают.
> Спорно как-то. Я не разраб KDE, но какие значительные изменения в четвертой
> ветке предполагаются? Это столько разрабатывали и когда подошли к концу цикла
> зачесалось в заднице? Не так уж много изменений было в последних
> выпусках. Ну, пусть думают.KDE 4.11 планируется как LTS, плюс репозиторий kdelibs будет заморожен - в 4.12 и далее новых фич по этой части не будет. KDE Workspaces и KDE PIM будут развиваться дальше в 4.x, а разработчики kdelibs вплотную займутся KDE Frameworks (основа KDE5).
По основной теме: как минимум один из основных разработчиков KDE, Laurent Montel, от имени KDE PIM выступает против означенной инициативы. С одной стороны, я с ним согласен. С другой - он себя зарекомендовал на редкость ненадёжным кодом в составе KDE SDK и стеке Akonadi, поэтому когда он против - стоит задуматься, может, изначальная идея не такая уж плохая...
так пусть pim обновляют в два раза реже остальных, кто б был против. увеличивать цифирку каждый второй раз, так еще и репутация хорошая заработается - у всех баги, только kde pim весь в белом
Блин, оно и так все в багах, а если еще время тестирования уменьшат - вообще капец будет.
Обычно частота релизов положительно сказывается на качестве софта (особенно в сочетании с непрерывной интеграцией). Релиз - это контрольная точка в разработке софта: чем больше контрольных точек, тем легче управлять разработкой, тем быстрее можно получить обратную связь по продукту и тем быстрее можно скорректировать развитие.
какие нафиг новые возможности. допилите оптимизируйте то что есть. я вообще не понимаю нафиг такая гонка. такое впечатление что они на винде маках сидят и не видят проблем своего творения.
> какие нафиг новые возможностиНовые возможности - это когда старые возможности таки начинают нормально работать.
Вы забыли табличку "Сарказм".
> такое впечатление что они на винде маках сидят и не видят проблем своего творенияА вы думаете, что они на линуксах сидят? Зачем им это?
новость не читай, херню отвечай. Написано же, что мастер будет содержаться стабильным и включаться будут стабильные фичи.
> какие нафиг новые возможности. допилите оптимизируйте то что есть. я вообще не
> понимаю нафиг такая гонка. такое впечатление что они на винде маках
> сидят и не видят проблем своего творения.На текущий момент ИМХО KDE 4 одна из самых вылизанных DE. Для любителей некрофильной "допиленности и оптимизации" есть Trinity.
Молодцы ребята умеют заниматься ерундой. Больше релизов еще больше чтобы к концу этого десятилетия у нас был релиз с версией 20.20. По факту уровень ошибок в коде очень велик, о чем они там вообще думают предлагая ускорить процесс еще больше. Очень часто бывает что процессы из состава KDE падают в кору, от релиза к релизу только еще больше усугубляется ситуация. Кто их в шею гонит, не понимаю. Так ослеплены желанием добиться высоких результатов что не видят как спускают те результаты чтобы были достигнуты ранее.
Это заговор: уничтожить все значимые DE в Линуксе. Сарказм сарказмом, а чуть больше паранойи и мой вывод покажется не таким уж фантастичным.
Видимо, сама идея DE уже отжила свое, и испытывает агонию.
То есть, теперь и DE уже стало "нинужно"?
> Это заговор: уничтожить все значимые DE в Линуксе. Сарказм сарказмом, а чуть больше паранойи и мой вывод покажется не таким уж фантастичным.Не покажется. Относительно KDE он стал таким не казаться, а выглядеть, когда "почётным свадебним генералом" проекта KDE4 "избрали" Космонавта.
> Не покажется. Относительно KDE он стал таким не казаться, а выглядеть, когда
> "почётным свадебним генералом" проекта KDE4 "избрали" Коcмонавта.Так вроде кдешники послали коcмонавта лесом, после того, как он спалился на черном антипиаре вяленого.
Вместо того, чтобы трындеть - лучше бы помогли снизить "уровень ошибок в коде" или баги хотя бы завели.
>>релизы будут содержать меньше изменений и соответственно меньше ошибокНадо срочно переходить на еженедельные релизы!
В условиях когда версия 5 будет готова неизвестно когда, а в ветке 4 будут только правиться ошибки смысл менять релиз цикл? Чтоб багфиксы быстрее получать?
Кеды не настолько идеальны чтоб забить на тестирование.
>>>релизы будут содержать меньше изменений и соответственно меньше ошибок
> Надо срочно переходить на еженедельные релизы!
> В условиях когда версия 5 будет готова неизвестно когда, а в ветке
> 4 будут только правиться ошибки смысл менять релиз цикл? Чтоб багфиксы
> быстрее получать?
> Кеды не настолько идеальны чтоб забить на тестирование.Только хардкор! Коммитить сразу в master-ветку и сразу пересобирать всё, что затронуто этим коммитом в пакеты и разливать по репозиториям роллинг-релиз дистрибутивов. Федоре такое и не снилось!
>>>>релизы будут содержать меньше изменений и соответственно меньше ошибок
>> Надо срочно переходить на еженедельные релизы!
>> В условиях когда версия 5 будет готова неизвестно когда, а в ветке
>> 4 будут только правиться ошибки смысл менять релиз цикл? Чтоб багфиксы
>> быстрее получать?
>> Кеды не настолько идеальны чтоб забить на тестирование.
> Только хардкор! Коммитить сразу в master-ветку и сразу пересобирать всё, что затронуто
> этим коммитом в пакеты и разливать по репозиториям роллинг-релиз дистрибутивов. Федоре
> такое и не снилось!а почему хардкор? стандартная работающая схема описана, что в ней такого, чего Федоре не снилось? (там ведь так и работает, конкретно с kde собранные пакеты в репах могут появиться еще когда архивы с сорцами не выложили для скачивания с сайта апстрима)
> выступили представители проекта openSUSE, которые указали на то, что для поддержания пакетов с KDE в дистрибутиве оптимальным является текущий шестимесячный цикл разработкиДа эти лентяи из openSUSE еще смеют что-то говорить? Вы только посмотрите на официальное обновленное ядро, используемое в текущей версии 12.3. Какой версии ядро? 3.7.10. А знаете какой ерундой они занимаются? Берут исправления ошибок с более новых версий, натягивают на эту старую версию(по мере возможности, т.е. исправления, которые не требуют нового функционала из новой версии ядра), потом месяц тестируют и выходит обновление. Это же сколько времени и ресурсов необходимо потратить, чтобы заниматься этим бэкпортированием? Не проще ли просто взять новую версию ядра с уже готовыми исправлениями ошибок и прочими интересными новшествами? Причем никакая совместимость нарушена не будет и ничего не потеряется. Мало того, при выходе очередного релиза они берут версию EOL, которая поддерживаться уже не будет, и занимаются мазохизмом. А еще они любители обрезать.. нет, просто отключать функционал драйвера, потому что они сочли его нестабильным, а все остальные дистрибутивы почему-то наоборот. Посмотрите на radeonsi. 2-3 месяца я специально наблюдаю, когда же они включат поддержку 3d в новых radeon hd 7xxx. В Fedora почему-то всё работает (хоть и медленее по сравнению с 5ххх/6ххх сериями, но приемлемо), никаких подвисаний драйвера и вообще нареканий относительно стабильности не обнаружено. Не успевают они, говорят? Клоуны!
Вам горит свежее ядро? Подключите официальный репозиторий "Kernel" со стабильными свежими версиями ядра и наслаждайтесь.p.s. ох уж эти диванные аналитики на опеннете
> Вам горит свежее ядро?Уж поверите, ядро версии 3.11 будет очень гореть. И связано это с видеокартой Radeon HD 7ххх. Вот вы говорите про репозиторий, а толку с него, если в другом репозитории X11/XOrg драйвер ati собран без поддержки radeonsi. Хотя версия там и гитовская свежая (наверное для нового релиза подготавливают), но драйвер ничего не может.
Не думайте. openSUSE - великолепный дистрибутив. Особенно zypper и управление пакетами, репозиториями. Просто убойная фича. Думается.. конкурентов им здесь не найти. Но этого мало.
Так расхвалил, что всем кто видел зипер показалось, что это вброс.
Да не расхваливаю я, серьезно. Но надстойка gui для него и вообще обновление системы, работа с репозиториями, с пакетами, выборка приоритетов для репозиториев и пр. действительно сильная сторона openSUSE. Особенно установка пакетов, например, 200-пакетов. Минуты 2-3 и готово. По сравнению с Ubuntu 10 и более минутным это ощутимо существенно. Вот возьмем обновление kde с версии 4.10.3 на 4.10.5. Около 400 пакетов нужно обновить. Да легко. Минут 4-5 и они и загружены, и установлены. Вот эта сторона сусе действительно вне конкуренции.
> Да не расхваливаю я, серьезно. Но надстойка gui для него и вообще
> обновление системы, работа с репозиториями, с пакетами, выборка приоритетов для репозиториев
> и пр. действительно сильная сторона openSUSE. Особенно установка пакетов, например, 200-пакетов.
> Минуты 2-3 и готово. По сравнению с Ubuntu 10 и более
> минутным это ощутимо существенно. Вот возьмем обновление kde с версии 4.10.3
> на 4.10.5. Около 400 пакетов нужно обновить. Да легко. Минут 4-5
> и они и загружены, и установлены. Вот эта сторона сусе действительно
> вне конкуренции.если по такой схеме сравнить пакетные менеджеры, арч с пакманом быстрее будет.
но в сусе все упирается в rpm (оверхед от zypper'а незначительный), так что сравнение не вполне справедливое.но вообще оценивать работу пакетного менеджера лучше не по ситуациям, когда все хорошо. когда все хорошо - можно оценить скорость работы, удобство для пользователя, язык программирования (если на православном С - добро!), занимаемое место ну и т. п. но когда система полуразломана (совместными усилиями пользователей, мейнтейнеров и общей непрухи) - важно во-первых работоспособность самого пакетного менеджера, во-вторых - чем он может помочь в починке остального. сколько он при этом сожрет процессорного времени - да пофиг, пусть хоть час считает, и написан хоть на брейнфаке.
а у suse сильных сторон немало :)
А что там с проприетарным драйвером от AMD? Он уже поддерживает? Я как-то не слежу за этим...
>> Вам горит свежее ядро?
> Уж поверите, ядро версии 3.11 будет очень гореть. И связано это с
> видеокартой Radeon HD 7ххх. Вот вы говорите про репозиторий, а толку
> с него, если в другом репозитории X11/XOrg драйвер ati собран без
> поддержки radeonsi. Хотя версия там и гитовская свежая (наверное для нового
> релиза подготавливают), но драйвер ничего не может.так модули xorg можно юзать и обновлять без привязки к остальному (как раз тот редкий случай, где это приемлимо), да и ядерную часть драйвера тоже можно юзать поверх "не родного" для него ядра.
а пробовать готовые сборки (репозитории, дистрибутивы, конфигурации ...) для решения частной проблемы - мартышкин труд, и результат зависит от везения. если нужный драйвер известен - лучше его руками запустить в существующей системе (или той которая нравится по остальным параметрам). вплоть до configure/make/install - а соображения о правильности лучше отложить на потом, когда все свистелки в должном качестве заработают :)
>> Вам горит свежее ядро?
> Уж поверите, ядро версии 3.11 будет очень гореть. И связано это с
> видеокартой Radeon HD 7ххх. Вот вы говорите про репозиторий, а толку
> с него, если в другом репозитории X11/XOrg драйвер ati собран без
> поддержки radeonsi. Хотя версия там и гитовская свежая (наверное для нового
> релиза подготавливают), но драйвер ничего не может.и кстати, ядро брать из другого дистрибутива - вполне нормальная практика (как раз по причине поддержки железа). с АМД я не сталкивался, но подобные проблемы с nvidia к примеру очень удобно решать установкой ядра из убунты прямо вместе с драйвером (suse если обнаруживает неучтенное ядро в /boot - собирает для него initrd и добавляет в конфиг при случае).
>> Вам горит свежее ядро?
> Уж поверите, ядро версии 3.11 будет очень гореть. И связано это с
> видеокартой Radeon HD 7ххх. Вот вы говорите про репозиторий, а толку
> с него, если в другом репозитории X11/XOrg драйвер ati собран без
> поддержки radeonsi. Хотя версия там и гитовская свежая (наверное для нового
> релиза подготавливают), но драйвер ничего не может.и кстати, ядро брать из другого дистрибутива - вполне нормальная практика (как раз по причине поддержки железа). с АМД я не сталкивался, но подобные проблемы с nvidia к примеру очень удобно решать установкой ядра из убунты прямо вместе с драйвером (suse если обнаруживает неучтенное ядро в /boot - собирает для него initrd и добавляет в конфиг при случае).
Так поступают 90% дистрибутивов, если чо.
Хотя могли бы lts ядро брать за основу, это да. Видно, хотят к релизу все наиболее свежее иметь.
В целом дистр годный. Юзаю на ноуте с незначительными проблемами
> Хотя могли бы lts ядро брать за основуСогласен с вами на все 100%. Логичнее же взять ядро с длительной поддержкой и всё, какие вопросы. Самое худшее - время. Весь мир узнает о критической ошибке в ядре, после чего ядра всех lts/не lts версий обновят, а эти разработчики будут еще месяц натягивать исправления и тестировать/проверять. Дистрибутив этот как эдакий слон, пока повернется - год пройдет.
>> Хотя могли бы lts ядро брать за основу
> Согласен с вами на все 100%. Логичнее же взять ядро с длительной
> поддержкой и всё, какие вопросы.Малыш, как, по-твоему, ядро становится "lts"?
Очень хорошо. Ну а владельцы бинарных недодистров должны страдать :)
Оу, вот он, тру-генту-пукальщик в лужу.
> темп разработки можно за счёт сокращения фазы тестированияНу молодцы. master-ветку пошлют нафиг практически все дистрибутивы и будем вечными тестерами блин. Спасибо !
> меньше изменений и соответственно меньше ошибок, что скажется на упрощении процесса тестирования.
С одной стороны конечно да. Но с другой стороны, все мы люди, темпы исправления багов нифига не изменятся. Может вначале и будут выпирая грудь исправлть баги, но потом как это всегда бывает плюнут и разотрут, ведь можно и в следующий раз исправить.
>Против предложения уже выступили представители проекта openSUSE, которые указали на то, что для поддержания пакетов с KDE в дистрибутиве оптимальным является текущий шестимесячный цикл разработки. При более частом формировании релизов нагрузка на мэйнтейнеров пакетов заметно возрастёт, что может отрицательно сказаться на качестве интеграции KDE в дистрибутив. Кроме того, значительные релизы раз в три месяца плохо синхронизируются с типичным 6- и 8-месячными циклами подготовки дистрибутивов.Шок, сенсация, Canonical хочет быть в отрыве от сообщества и тянет одеяло на себя.
Где вы там Кононикл узрели ? Там жеж Мелкософтова *люха жалуется. Правильно жалуется правда.
Да чего уж там - давайте вообще просто собирать из транка. К черту релизы!PS не эти ли ребята обещали что в 4-й ветке, начиная с 4,10-4,11, теперь заморозка и дальше пойдет только отлаживание?
> не эти ли ребята обещали что в 4-й ветке, начиная с 4,10-4,11, теперь заморозка и дальше пойдет только отлаживание?Есть грибы - плохо.
> Да чего уж там - давайте вообще просто собирать из транка. К
> черту релизы!а в kde релиз берется откуда по-вашему? ответвлением от мастера и долгим процессом стабилизации/тестирования? так это если кто-нибудь так думает - лучше не разубеждать, зачем плохому учить...
> PS не эти ли ребята обещали что в 4-й ветке, начиная с
> 4,10-4,11, теперь заморозка и дальше пойдет только отлаживание?feature freeze они не имели ввиду. речь шла об отсутствии серьезных изменений, то есть что-то новое будут развивать отдельно. а там доделывать и нечего толком (баги фиксить и оптимизировать только). они просто успокоили народ, что они не собираются превратить текущую версию в ОС для планшетов и мобилок, а то были опасения :)
Кедорасы наносят ответный удар! :))))))))))))))))))))))))))))
Итак большой и нестабильный ДЕ станет еще более нестабильным. В общем-то какая разница...
> В общем-то какая разница....Хоть и виртуально но отчаянно плюсую!
А где фонд СПО и его громкая речь про переход на Linux?! А ведь для десктопа очень важна DE хорошая и стабильная. Такими темпами KDE из сообщества превратится в секту где останется парочку программистов которые продолжат клепать релизы со скоростью конвеера
В этом случае "сообщество" гордо скажет: DE нинужно! У них очень предсказуемая "логика" же.
Забавно, как много комментаторов оставляют свои "веские" мнения, не будучи при этом знакомыми с методологиями разработки и даже не слышавшими про continuous integration и continuous deployment.
Они знакомы с результатами этих ваших континиусов.
Каким же, интересно, образом? Технологии разработки являются внутренней кухней девелоперов и пользователям обычно до лампочки, тем более, что последние все равно даже скрам от канбана отличить не в силах.
И уж для того, чтобы оценить результат модернизации процессов разработки, мимолетного "профессионального" взгляда форумного балабола явно недостаточно. К тому же, пока что все претензии пока что сводятся к воплям "номера версий накручивают!!1", хотя непонятно, что в этом плохого.
Если возрастёт стабильность помимо частоты , то я за.