AppIndicator https://russianfedora.github.io/FAQ/using-applications.html#gnome-shell-tray

Спс

баги зарепорчены сейчас или до релиза?

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

толку от этого тривиального вызова, если крашится как раз нетривиальный код

не нагнетай, так всегда было и будет, мы все тестим апстрим

зато потом будет светлое будущее :)

просто надо тестить не в релизе в бете хотя бы и делать баги блокерами

просто надо тестить не в релизе в бете хотя бы и делать баги блокерами

Ты словно переложила всю ответственность на майнтайнера в конкретном дистрибутиве. Так быть не должно.

как ты узнаешь что снапшот из транка нестабильный если его никто не тестил на реальных проектах. Вот и тестим, да, просто feedback loop должна быть не после релиза а до

как ты узнаешь что снапшот из транка нестабильный если его никто не тестил на реальных проектах. Вот и тестим, да, просто feedback loop должна быть не после релиза а до

Ну так он и говорит, не надо брать снапшот из транка)

оно в принципе не прошло должного тестирование и не должно было попасть в релиз федоры)

ну так он там и был, в rawhide. пришёл gcc, всё пересобрали, пересобралось. Дальше какие шаги? Дальше надо было репортить баги во-первых, во-вторых повышать им приоритет. В третьих придти перед бетой и сказать - вон у gcc мильон багов, давайте откатывать фичу

будет весело если какой-нибудь очередной баг в 10 GCC приводит к медленному развалу FS

ну так он там и был, в rawhide. пришёл gcc, всё пересобрали, пересобралось. Дальше какие шаги? Дальше надо было репортить баги во-первых, во-вторых повышать им приоритет. В третьих придти перед бетой и сказать - вон у gcc мильон багов, давайте откатывать фичу

Если бы "собралось и ладно" было единственным критерием качества — ок. Но это ведь не так.

Если бы "собралось и ладно" было единственным критерием качества — ок. Но это ведь не так.

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

зато потом будет светлое будущее :)

Ровно до следующей мажорной версии GCC. 😇

ну так он там и был, в rawhide. пришёл gcc, всё пересобрали, пересобралось. Дальше какие шаги? Дальше надо было репортить баги во-первых, во-вторых повышать им приоритет. В третьих придти перед бетой и сказать - вон у gcc мильон багов, давайте откатывать фичу

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

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

почему не должны были-то

gcc не может один разгрести все баги всех проектов которые его используют, именно для этого делается system-wide change чтобы все были в курсе планов, и участвовали

почему не должны были-то

Согласно твоей логике можно взять любой сырой продукт и потом можно обвинить майнтайнеров, что ОЙ НЕ ТЕСТИРУЕТЕ

а продукт то сам по себе не работает

Согласно твоей логике можно взять любой сырой продукт и потом можно обвинить майнтайнеров, что ОЙ НЕ ТЕСТИРУЕТЕ

расслабьтесь, я никого не обвиняю. Я говорю о том как устроен процесс разработки fedora

скажите, пожалуйста, есть ли что-то, что позволяло бы быстро проверить целостность файла? одна из причин, почему я использую ZFS - это ее контрольная сумма файлов. Я понимаю, что можно архиваторами пользоваться с поддержкой сумм, но они больно тормозные в этом плане... есть ли что-то, что может SHA файлов с директориями и поддиректориями хранить и сравнивать быстро?

тащить или не тащить X в стабильный релиз - решается при тестировании релиза. Соответственно практика показала что тестирование у нас плохо организовано.

я вот и думаю почему и как его надо улучшать

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

мне кажется это нелогично

нет. не только в gcc дело в данном случае, могла быть какая-то лругая фича с таким же эффектом

тащить или не тащить X в стабильный релиз - решается при тестировании релиза. Соответственно практика показала что тестирование у нас плохо организовано.

объясни в чём смысл - тащить нестабильный GCC и в то же время не обновить Qt до следующей стабильной версии?

проблема в том что работу пакетов после масс-ребилда не проверяет вообще никто

лол :)))

тащить или не тащить X в стабильный релиз - решается при тестировании релиза. Соответственно практика показала что тестирование у нас плохо организовано.

А ты не видишь проблемы, что кто-то решил на половине всего тестового периода взять кор компонент системы из транка, таким образом он: 1. Сократил возможное время тестирования 2. Отключил от процесса тестирования майнатайнеров

А ты не видишь проблемы, что кто-то решил на половине всего тестового периода взять кор компонент системы из транка, таким образом он: 1. Сократил возможное время тестирования 2. Отключил от процесса тестирования майнатайнеров

что значит - отключил? каким образом?

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

заявляется system-wide change, анонсируется по всем каналам, у этого изменения есть план по выполнению, и contingency plan на случай если что-то пошло не так. Все майнтейнеры обязаны быть подписаны на devel-announce и быть в курсе таких обновлений

это не что-то происходящее скрытно о всех, это шаг в разработке

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

(если что - я для своего пакета тоже не проверила работу после ребилда)

это не наезд на майнтейнеров, я просто говорю о том что у нас пропущен шаг верификации при пересборке

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

Ребятки, тут что-то сделал неадекватное. ЕБитес.

Не проверили? Ну так это же вы виноваты

плохо тестируйте

да успокойся ты уже про свой транк. я всё поняла про него. Но иногда в fedora мы допускаем использование pre-release версий. так бывает. Опять же это ни для кого не было сюрпризом. Да, надо было действовать аккуратнее в данном случае. Но я про другую сторону проблемы говорю.

да успокойся ты уже про свой транк. я всё поняла про него. Но иногда в fedora мы допускаем использование pre-release версий. так бывает. Опять же это ни для кого не было сюрпризом. Да, надо было действовать аккуратнее в данном случае. Но я про другую сторону проблемы говорю.

Другая сторона проблемы аффектит только какой-то 1 пакет, а не всю систему в целом.

ДА

Ты решаешь существующую проблему, но другую.

можно теперь тестирование обсудить?

можно теперь тестирование обсудить?

Если оно начнётся с майнтайнера кор-компонента, который принимает такие необдуманные решения на половине срока теста.

У неё строители не те. Чини строителей!

эта беда с транком должна была вылезти не сейчас а три месяца назад, когда у нас был шанс всё откатить

Если оно начнётся с майнтайнера кор-компонента, который принимает такие необдуманные решения на половине срока теста.

🍿

то что она не вылезла. при том что ошибки легко ловятся - это проблема тестирования fedora

нет, она не вылезла как массовая проблема с gcc10 являющаяся блокером релиза. А должна была.

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

у нас такого процесса не оказалось или он не сработал

вот это проблема

но это решение другой проблемы)

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

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

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

Ты иногда отвечаешь как политик) Накосячили здесь определённые люди и процессы не сработали с ними.

гном до сих пор на исключении работает

гном до сих пор на исключении работает

Гном не системообразующий компонент

поэтому просто запрет - это не решение, нам нужны дополниетльные критерии

важный, но не корневой

ах если бы к билдам были тесты...

Гном не системообразующий компонент

dnf -C repoquery --whatrequires glib2

Ты иногда отвечаешь как политик) Накосячили здесь определённые люди и процессы не сработали с ними.

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

dnf -C repoquery --whatrequires glib2

и что? Может ли без гнома существовать система? Может. Сервара, облака, терминалы где открыта 1 программа и всё.

хм, на 32 тоже приехало nss-3.51.1-1.fc32.i686 nss-3.51.1-1.fc32.x86_64 никакого стима

gcc-то в блокерах, проблема в том что в блокерах возможность с помощью gcc собрать рабочий релиз workstation. И все пакеты которые не в дефолтной поставке пролетели мимо release criteria. Что плохо.

а вот пункт два я как раз и упоминала там в начале

то есть да, в принципе согласна, о том и речь

gcc-то в блокерах, проблема в том что в блокерах возможность с помощью gcc собрать рабочий релиз workstation. И все пакеты которые не в дефолтной поставке пролетели мимо release criteria. Что плохо.

Ты аккуратно с этим. Если критерий релиза — собираются и работают программы в поставке, то так и не заметишь как их будет собирать clang. Формально. — критерий выполнен. Фактически — бомба с gcc может где угодно выстрелить.

Ты аккуратно с этим. Если критерий релиза — собираются и работают программы в поставке, то так и не заметишь как их будет собирать clang. Формально. — критерий выполнен. Фактически — бомба с gcc может где угодно выстрелить.

если мы начнем fedora собирать clang и это будет работать, то не вижу проблем

и что? Может ли без гнома существовать система? Может. Сервара, облака, терминалы где открыта 1 программа и всё.

То, что ты не понимаешь о чем говоришь, как обычно. И что даже не соизволил выполнить команду эту перед тем как продолжать далье постить свой нонсенс. libvirt-dbus flatpak libgit и т.д. Это всё тоже десктоп?

сейчас критерии заточены на получение работоспособного дефолтного окружения

надо бы добавить какие-то проверки для более широкого круга пакетов

что возвращает нас к моей любимой теме гейтинга

в общем-то мы не спорим ведь по сути, просто упор делаем на разное, так что всё ок

на следующем fesco-митинге попробую поговорить об этом