Discussion:
[arch-general] arch health
ITwrx.org
2017-04-19 23:29:48 UTC
Permalink
i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.

why am i concerned?

Many users tested to demonstrate that PIE would not cause an undue
performance burden but it has still not been implemented due to dev's
lack of time. Now said dev is also resigning from packaging due to it
becoming a chore. Is PIE on the menu of the adopter of those packages?

There are also many official packages that have been out of date for a
while. At least one of the devs seems to have too many packages to
maintain. Probably because packages were orphaned and someone had to
pick up the slack. There are probably many packages in aur that should
be moved to official if there were devs who had time to deal with them.
There are probably some bugs that need to be fixed too. Maybe we can
use some % of donations to pay a dev/devs? Can we modernize the
donations system? I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.

IMHO, a general donate method doesn't cut it. Crowd funding should
demonstrate clearly that people will donate much more when they have
input and can see goals, progress, etc. Donors and devs should be able
to designate goals (devs could have approval/veto power) and/or donors
should be able to donate towards approved goals. It would be nice if we
could fund developers or maybe just a rewards pool where devs get some
appreciation money each month. Crypto currency could be an option. Devs
could choose what they want to receive. If nothing else, maybe we could
crypto tip individually or to an Arch address. Some way to make arch
development more practical for people. I know in the past arch devs have
said roughly that "he who does the dev makes the decisions" but maybe us
users can buy our way in just enough to influence the speed or goals of
the distro's dev? It doesn't seem like the current state of things can
keep up with threats, new features, etc. I think i am not alone in being
willing to pitch in money, when i can, to make it easier or more
worthwhile for devs, new or current. At least we could see what the
current funding levels for goals were so we would know if more needs to
be done. Some other distros have large corps that can foot the bill to
get things done. I'm sure Arch could use some help too, even if we
already have donation funds for infrastructure needs.

thanks
--
Information Technology Works
https://ITwrx.org
@ITwrxorg
Dragon ryu via arch-general
2017-04-19 23:32:26 UTC
Permalink
2017/04/20 午前8:30 "ITwrx.org" <***@itwrx.org>:

i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.

why am i concerned?

Many users tested to demonstrate that PIE would not cause an undue
performance burden but it has still not been implemented due to dev's
lack of time. Now said dev is also resigning from packaging due to it
becoming a chore. Is PIE on the menu of the adopter of those packages?

There are also many official packages that have been out of date for a
while. At least one of the devs seems to have too many packages to
maintain. Probably because packages were orphaned and someone had to
pick up the slack. There are probably many packages in aur that should
be moved to official if there were devs who had time to deal with them.
There are probably some bugs that need to be fixed too. Maybe we can
use some % of donations to pay a dev/devs? Can we modernize the
donations system? I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.

IMHO, a general donate method doesn't cut it. Crowd funding should
demonstrate clearly that people will donate much more when they have
input and can see goals, progress, etc. Donors and devs should be able
to designate goals (devs could have approval/veto power) and/or donors
should be able to donate towards approved goals. It would be nice if we
could fund developers or maybe just a rewards pool where devs get some
appreciation money each month. Crypto currency could be an option. Devs
could choose what they want to receive. If nothing else, maybe we could
crypto tip individually or to an Arch address. Some way to make arch
development more practical for people. I know in the past arch devs have
said roughly that "he who does the dev makes the decisions" but maybe us
users can buy our way in just enough to influence the speed or goals of
the distro's dev? It doesn't seem like the current state of things can
keep up with threats, new features, etc. I think i am not alone in being
willing to pitch in money, when i can, to make it easier or more
worthwhile for devs, new or current. At least we could see what the
current funding levels for goals were so we would know if more needs to
be done. Some other distros have large corps that can foot the bill to
get things done. I'm sure Arch could use some help too, even if we
already have donation funds for infrastructure needs.

thanks



--
Information Technology Works
https://ITwrx.org
@ITwrxorg

Wait, actual question is about PIE?
If you find that package are outdated in community or extra, file a bug rep.
Why not do it?
ITwrx.org
2017-04-19 23:55:05 UTC
Permalink
Post by ITwrx.org
i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.
why am i concerned?
Many users tested to demonstrate that PIE would not cause an undue
performance burden but it has still not been implemented due to dev's
lack of time. Now said dev is also resigning from packaging due to it
becoming a chore. Is PIE on the menu of the adopter of those packages?
There are also many official packages that have been out of date for a
while. At least one of the devs seems to have too many packages to
maintain. Probably because packages were orphaned and someone had to
pick up the slack. There are probably many packages in aur that should
be moved to official if there were devs who had time to deal with them.
There are probably some bugs that need to be fixed too. Maybe we can
use some % of donations to pay a dev/devs? Can we modernize the
donations system? I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.
IMHO, a general donate method doesn't cut it. Crowd funding should
demonstrate clearly that people will donate much more when they have
input and can see goals, progress, etc. Donors and devs should be able
to designate goals (devs could have approval/veto power) and/or donors
should be able to donate towards approved goals. It would be nice if we
could fund developers or maybe just a rewards pool where devs get some
appreciation money each month. Crypto currency could be an option. Devs
could choose what they want to receive. If nothing else, maybe we could
crypto tip individually or to an Arch address. Some way to make arch
development more practical for people. I know in the past arch devs have
said roughly that "he who does the dev makes the decisions" but maybe us
users can buy our way in just enough to influence the speed or goals of
the distro's dev? It doesn't seem like the current state of things can
keep up with threats, new features, etc. I think i am not alone in being
willing to pitch in money, when i can, to make it easier or more
worthwhile for devs, new or current. At least we could see what the
current funding levels for goals were so we would know if more needs to
be done. Some other distros have large corps that can foot the bill to
get things done. I'm sure Arch could use some help too, even if we
already have donation funds for infrastructure needs.
thanks
--
Information Technology Works
https://ITwrx.org
@ITwrxorg
Wait, actual question is about PIE?
If you find that package are outdated in community or extra, file a bug rep.
Why not do it?
no, PIE is just one of the examples i listed of symptoms of a larger
issue that i thought might could be helped by paying devs and
modernizing the donation system. why would i file a bug for an out of
date package? i'm sure the developer is notified when a package is
flagged? why should i pester them to update it?
Ralf Mardorf
2017-04-20 00:34:59 UTC
Permalink
Post by ITwrx.org
Post by ITwrx.org
i'm a little concerned about arch's overall health and i was
wondering if there's anything we can do about it.
no, PIE is just one of the examples i listed of symptoms of a larger
issue
You are concerned about the "overall health", but you only provide a
vague diagnosis. A hiccup seldom is a symptom of sickness, but you even
do not clearly describe a hiccup.
Jelle van der Waa
2017-04-20 07:09:51 UTC
Permalink
Post by ITwrx.org
<snip>
Wait, actual question is about PIE?
If you find that package are outdated in community or extra, file a bug rep.
Why not do it?
no, PIE is just one of the examples i listed of symptoms of a larger
issue that i thought might could be helped by paying devs and
modernizing the donation system.
PIE is blocked by upstream because of this bug iirc. [1]
Post by ITwrx.org
why would i file a bug for an out of
date package? i'm sure the developer is notified when a package is
flagged? why should i pester them to update it?
You don't and it's counterproductive, just flag it out of date.
Currently you might experience packages being updated a lot slower since
we have a lot of big invasive rebuilds; OpenSSL 1.1, LLVM 4.0.
Especially the OpenSSL rebuild was painful and time consuming.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
--
Jelle van der Waa
Ralf Mardorf
2017-04-20 00:22:36 UTC
Permalink
Hi,

I would be concerned, if too many security features not everybody needs,
would become default. Why not dropping security features completely and
instead making real-time optimised features the default? This is a
rhetorical question, but actually I would prefer the latter.

In my experiences Arch is very healthy.

I doubt that many packages are outdated.

Right off the bat a few come to mind, e.g.

claws-mail and clawsker

but we had Easter holidays and some packages are already in testing.

Other packages, such as e.g.

ardour

are out of date for a long time, but the maintainer explained why he has
got no time for a while. Apart from this Ardour is niche software.

Each of the outdated packages I noticed still build using ABS or AUR
PKGBUILDs by just changing the version and skipping or changing the
checksums or they require minimal additional editing, if so I
usually drop a note to AUR comments, how to fix the issue.

It's hard to find much more packages I consider really outdated.
I noticed that some packages from official repositories are flagged out
of date, a few minutes after upstream released a new version, so I
wouldn't count those packages.

In my experiences Arch is a healthy rolling release. There are a few
hiccups, but I experience less hiccups using Arch, than I experience
serious issues with other distros.

Regards,
Ralf
ITwrx.org
2017-04-20 00:42:17 UTC
Permalink
Post by Ralf Mardorf
Hi,
I would be concerned, if too many security features not everybody needs,
would become default. Why not dropping security features completely and
instead making real-time optimised features the default? This is a
rhetorical question, but actually I would prefer the latter.
In my experiences Arch is very healthy.
I doubt that many packages are outdated.
Right off the bat a few come to mind, e.g.
claws-mail and clawsker
but we had Easter holidays and some packages are already in testing.
Other packages, such as e.g.
ardour
are out of date for a long time, but the maintainer explained why he has
got no time for a while. Apart from this Ardour is niche software.
Each of the outdated packages I noticed still build using ABS or AUR
PKGBUILDs by just changing the version and skipping or changing the
checksums or they require minimal additional editing, if so I
usually drop a note to AUR comments, how to fix the issue.
It's hard to find much more packages I consider really outdated.
I noticed that some packages from official repositories are flagged out
of date, a few minutes after upstream released a new version, so I
wouldn't count those packages.
In my experiences Arch is a healthy rolling release. There are a few
hiccups, but I experience less hiccups using Arch, than I experience
serious issues with other distros.
Regards,
Ralf
thanks for your input. i'm not saying Arch isn't great. I use it for
everything and it would take a whole lot for that to change. I just want
the healthiest Arch possible. I think that Arch could have a few
different "build profiles" if it was possible to automate packaging a
little or if there were more devs or devs had more time to allocate to
Arch because they were getting paid. Or, if the donation system were
modernized, Arch could fund it's priorities in that regard and maybe
people choose your goals instead of mine.
Dragon ryu via arch-general
2017-04-20 01:46:21 UTC
Permalink
Post by Ralf Mardorf
Hi,
I would be concerned, if too many security features not everybody needs,
would become default. Why not dropping security features completely and
instead making real-time optimised features the default? This is a
rhetorical question, but actually I would prefer the latter.
In my experiences Arch is very healthy.
I doubt that many packages are outdated.
Right off the bat a few come to mind, e.g.
claws-mail and clawsker
but we had Easter holidays and some packages are already in testing.
Other packages, such as e.g.
ardour
are out of date for a long time, but the maintainer explained why he has
got no time for a while. Apart from this Ardour is niche software.
Each of the outdated packages I noticed still build using ABS or AUR
PKGBUILDs by just changing the version and skipping or changing the
checksums or they require minimal additional editing, if so I
usually drop a note to AUR comments, how to fix the issue.
It's hard to find much more packages I consider really outdated.
I noticed that some packages from official repositories are flagged out
of date, a few minutes after upstream released a new version, so I
wouldn't count those packages.
In my experiences Arch is a healthy rolling release. There are a few
hiccups, but I experience less hiccups using Arch, than I experience
serious issues with other distros.
Regards,
Ralf
thanks for your input. i'm not saying Arch isn't great. I use it for
everything and it would take a whole lot for that to change. I just want
the healthiest Arch possible. I think that Arch could have a few
different "build profiles" if it was possible to automate packaging a
little or if there were more devs or devs had more time to allocate to
Arch because they were getting paid. Or, if the donation system were
modernized, Arch could fund it's priorities in that regard and maybe
people choose your goals instead of mine.

Well, Arcg standard is Keep It Simple, mate.
David C. Rankin
2017-04-20 07:21:01 UTC
Permalink
Post by Ralf Mardorf
In my experiences Arch is very healthy.
Taking the needed time to git it done correctly the first time is NOT an
indication of poor health -- just the opposite. I would rather have packages
stay in testing an additional 30 days and have all problems addressed than
have it called "good enough" in some arbitrary rush that results in more
problems and bug reports down the line.

Since the infighting of systemd and the libc move have been relegated to
history, I haven't seen any indication of ill heath since that time. (having
to build php56 from AUR is a bit of a pain, but that too is no indication of
any ill health in the distro...
--
David C. Rankin, J.D.,P.E.
Francisco Barbee via arch-general
2017-04-20 10:14:08 UTC
Permalink
Post by Ralf Mardorf
I would be concerned, if too many security
features not everybody needs,
Post by Ralf Mardorf
would become default. Why not dropping security
features completely and
Post by Ralf Mardorf
instead making real-time optimised features the
default? This is a
Post by Ralf Mardorf
rhetorical question, but actually I would prefer
the latter.

Did you know those security features were
extensively tested for performance, with many
peoples involved?
See: https://github.com/pid1/test-sec-flags/wiki

It's 2017, security doesn't mean unoptimized.
There was attempt to bring in more optimizations
already used in Clearlinux project like pgo and
lto to makepkg but it's still on sidelines due to
lack of time from devs.
See
https://aur.archlinux.org/packages/makepkg-optimize2/
Post by Ralf Mardorf
On 20 April 2017 at 10:32:32, Jelle van der Waa
PIE is blocked by upstream because of this bug
iirc. [1]
Post by Ralf Mardorf
[1]
https://sourceware.org/bugzilla/show_bug.cgi?id=21090

Did you know this bug was reported by concerned
user because dev hadn't time for it for a half of
year? Plus nobody ever explained why minor bug in
testsuite should be a blocker here. Also there are
more security flags to be enabled, trivial to add
and blocked only by lack of time/lack of will,
even when other devs explicitly asked for this.
Post by Ralf Mardorf
On 20 April 2017 at 10:43:03, David C. Rankin
Taking the needed time to git it done correctly
the first time is NOT an
Post by Ralf Mardorf
indication of poor health -- just the opposite.
I would rather have packages
Post by Ralf Mardorf
stay in testing an additional 30 days and have
all problems addressed than
Post by Ralf Mardorf
have it called "good enough" in some arbitrary
rush that results in more
Post by Ralf Mardorf
problems and bug reports down the line.
I agree with the above but it's not the case here.
Packages doesn't stay in testing for extended
period because actual problems are resolved but
because everyone who did his/her job has to wait
for someone who didn't. See
https://www.archlinux.org/todo/openssl-rebuild-take-2/
. Everything is done except one package and
nothing changed for weeks.

It's not about blaming anyone because I believe
everybody do what they can. It's about finding a
way to help those who struggle. When some users
are asking about how they can help, answering WE
DON'T NEED HELP isn't very appropriate. Even if
you don't care at all about it please don't try to
discourage those who care.
Ralf Mardorf
2017-04-20 11:07:11 UTC
Permalink
Post by Francisco Barbee via arch-general
There was attempt to bring in more optimizations
already used in Clearlinux project like pgo and
lto to makepkg but it's still on sidelines due to
lack of time from devs.
Hi,

are you in a hurry?

IMO it's unhealthy to be in a hurry, apart from this seemingly not
everybody needs those security features.

Arch isn't ill, there seems to be no foreseeable risk that Arch
could become ill.

If somebody should really experience some illness, then please don't be
vague, post a pointer to the illness.

I only claim that I don't experience illness and that my impression is,
that Arch is distinctly healthy. In my experience more healthy, than any
other distro I experience/experienced.

YMMV!

Imagine everybody who wants something, Arch doesn't provide, would
argue with being "a little concerned about arch's overall health", to
get it into Arch.

Regards,
Ralf

Regards,
Ralf
Francisco Barbee via arch-general
2017-04-20 13:10:18 UTC
Permalink
Hi, are you in a hurry?
Not at all. But I can imagine what feels someone
who made effort to make things better by writing
patches which are still ignored year after.
IMO it's unhealthy to be in a hurry, apart from
this seemingly not everybody needs those security
features.

Some people need them, some don't. You can just
ignore this topic instead of writing another post
about how much you don't need it.
Arch isn't ill, there seems to be no foreseeable
risk that Arch could become ill. If somebody
should really experience some illness, then please
don't be vague, post a pointer to the illness.

OP already mentioned few things. You can look into
https://www.archlinux.org/todo/ and
https://lists.archlinux.org/listinfo/arch-dev-public
to see how many things are need to be done. One
example is abs which wasn't maintained for years.
I only claim that I don't experience illness and
that my impression is, that Arch is distinctly
healthy. In my experience more healthy, than any
other distro I experience/experienced.

It's not really about being healthy but being
healthier
Imagine everybody who wants something, Arch
doesn't provide, would argue with being "a little
concerned about arch's overall health", to get it
into Arch.

Enabling those flags was already decided by devs
regardless how much you hate it. It's lack of
execution which is concern here. Maybe bigger
issue than Arch health is attitude of some people
who're trying hard to water-down any attempt to
make things better. If you don't need any help
let others help those who need it.
Tinu Weber
2017-04-20 13:23:41 UTC
Permalink
Post by Francisco Barbee via arch-general
Post by Ralf Mardorf
IMO it's unhealthy to be in a hurry, apart from
this seemingly not everybody needs those security
features.
[...]
Post by Ralf Mardorf
Arch isn't ill, there seems to be no foreseeable
risk that Arch could become ill. If somebody
should really experience some illness, then please
don't be vague, post a pointer to the illness.
[...]
Post by Ralf Mardorf
I only claim that I don't experience illness and
that my impression is, that Arch is distinctly
healthy. In my experience more healthy, than any
other distro I experience/experienced.
[...]
Post by Ralf Mardorf
Imagine everybody who wants something, Arch
doesn't provide, would argue with being "a little
concerned about arch's overall health", to get it
into Arch.
Hello, this is unrelated, but it appears that your MUA or MTA screws up
the formatting of your mails, making it difficult to follow this
conversation, as I have to figure out for each line whether it's part of
a quote or not.
Post by Francisco Barbee via arch-general
Post by Ralf Mardorf
I would be concerned, if too many security
features not everybody needs,
Post by Ralf Mardorf
would become default. Why not dropping security
features completely and
Post by Ralf Mardorf
instead making real-time optimised features the
default? This is a
Post by Ralf Mardorf
rhetorical question, but actually I would prefer
the latter.
Would you mind finding out why that is so, and try to fix that?
Thank you in advance!

Best,
Tinu
Martin Kühne via arch-general
2017-04-20 14:03:21 UTC
Permalink
Not only could most of the concerns be successfully identified as
Other People's Problems™, pepole are still very focused on email
ettiquette. I think interpreting these two basic indicators about the
health of Arch can left as an exercise for the reader.

I'm not exactly sure what OP expected in this thread, but it's
definitely entertaining. I'll quote the original email's contents
fragmentally to spare you the whole pain.
Post by ITwrx.org
i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.
why am i concerned?
Oh come on.
You're making a case against your flawed judgment with such polemic.
Post by ITwrx.org
[...] I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.
Would you mind to share the content of these emails?
Your argument seems suspicious and can't be verified as long as the
content of your scripture is in absence.
Post by ITwrx.org
[...blah...money...blah...]
Money definitely is an important factor. We're all using arch for the money.

cheers!
mar77i
Ralf Mardorf
2017-04-20 15:21:14 UTC
Permalink
You can just ignore this topic instead of writing another post
about how much you don't need it.
Hi,

you completely missed my point. You ignore that in my opinion, in this
context, it's not appropriate to argue with being "a little concerned
about arch's overall health", while there is no causal indication for
even a hiccup.

I'm not necessarily against pathos (I'm not using the term "polemic").
Pathos is a very good tool when making art, but it's not good when
trying to get something into a distro, that seemingly already was
rejected.

Regards,
Ralf
--
Money definitely is an important factor. We're all using arch for the
money.
No, I'm not interested in money, my aim is world domination to satisfy
my interests and much more my compulsion neuroses. If I become leader
of the world, all distros are forced to optimize for real-time audio and
nobody is allowed to wear blue t-shirts on uneven days and no orange
t-shirts on even days.

Btw. I guess the OP wanted to point out that Arch is in a bad shape,
because "making" (not "using") Arch requires money.
Carsten Mattner via arch-general
2017-04-20 17:56:19 UTC
Permalink
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered. Case in point ffmpeg 3.3.
3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
corrupts files. It's not the first instance where I wished
for official revoke and replace in the index instead of
manual user intervention.
Ralf Mardorf
2017-04-20 18:54:43 UTC
Permalink
Post by Carsten Mattner via arch-general
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered.
Hi,

IIRC a few downgrades happened already, but since it's a rolling
release, IMO it's understandable, that this can't be done that easy as
for release model distros with a freeze, since there are dependency
chains and Arch tries to follows upstream when ever possible, without
patching "stable" releases from upstream. If such a hiccup happens,
we could report bugs upstream and temporarily downgrade [1], or if
necessary, rebuild packages against new dependencies using PKGBUILDs
from ABS [2].

I sometimes build with fixes from upstream, e.g. git commits, that
aren't official released as a new version, without adding "-git" or
similar to the package, so next time a stable version is released, the
upgrade happens automatically. At the moment I'm doing this for jack2
[3].

Until now nobody claimed that Arch Linux is perfect, free from any
hiccups. It's just "pathetic" or "polemic" to imply that Arch tends to
become less healthy. If an issue happens, we need to establish a
differential diagnosis, instead of careless diagnosing a disease.

There are no doubts that hiccups happen from time to time, but the
advantage of Arch is, that it does follow upstream as simple and close
as possible, so it's much easier to fix an issue temporarily on your
own, perhaps with help from the community, than it could be done for
most other distros.

The more features Arch developers would add by default, the more prone
Arch would become to make fixing it harder, if an issue does arise for
your domain/usage.

My domain is real-time audio and I prefer Arch not because it's perfect
by default, but because it's perfect to fix issues even for niches. A
lot of other distros are optimised for different usages. There are
without doubts needs, that require really long term support, where
restoring from a backup isn't an option. IMO Arch is good for a
specific target group, but maybe not good for all purposes.

Any unreasonable changes won't improve Arch. Until now we only know
that somebody guess that too many packages are outdated and some
features aren't provided, because it's presumed that Arch developers
don't have the time/money to do the work.

I'm not a developer, so I won't judge this claim. However, until now no
developer agreed that there is a lack of money and time. At least not
by such an amount, that Arch danger threatens.

I don't know, but until not several users confirm that Arch's overall
health is fishy, we should assume that Arch is in good shape.

Just my 2 Cents,
Ralf

[1]
https://aur.archlinux.org/packages/downgrade/
[2]
https://www.archlinux.org/packages/extra/x86_64/abs/
[3]
[***@archlinux ~]$ pacman -Si jack2 | grep Ver
Version : 1.9.10-6
[***@archlinux ~]$ pacman -Q jack2
jack2 1.9.10.r261.g2d1d3235-1
Mauro Santos via arch-general
2017-04-20 19:00:13 UTC
Permalink
Post by Carsten Mattner via arch-general
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered. Case in point ffmpeg 3.3.
3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
corrupts files. It's not the first instance where I wished
for official revoke and replace in the index instead of
manual user intervention.
Have you reported the bug? If yes and the dev decides that it should be
reverted to a previous version there is a way to do it, see:
man pacman | grep -A1 epoch
--
Mauro Santos
Ralf Mardorf
2017-04-20 19:21:53 UTC
Permalink
Post by Mauro Santos via arch-general
Post by Carsten Mattner via arch-general
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered. Case in point ffmpeg 3.3.
3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
corrupts files. It's not the first instance where I wished
for official revoke and replace in the index instead of
manual user intervention.
Have you reported the bug? If yes and the dev decides that it should be
man pacman | grep -A1 epoch
For the sake of completeness:

"Upstream or Arch?
[snip]
If Arch is not responsible for a bug, the problem
will not be solved by reporting the bug to Arch developers." -
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F

This policy isn't always pleasant ;), but the Arch developers sometimes
are willing to balance pros and cons, so sometimes they fix such
issues ;).
Mauro Santos via arch-general
2017-04-20 20:27:14 UTC
Permalink
Post by Ralf Mardorf
Post by Mauro Santos via arch-general
Have you reported the bug? If yes and the dev decides that it should be
man pacman | grep -A1 epoch
"Upstream or Arch?
[snip]
If Arch is not responsible for a bug, the problem
will not be solved by reporting the bug to Arch developers." -
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F
This policy isn't always pleasant ;), but the Arch developers sometimes
are willing to balance pros and cons, so sometimes they fix such
issues ;).
Maybe I should have been more specific, I was talking about
downgrading/reverting an update. That is why the epoch field exists and
it has been used before. Ffmpeg does have the mark of shame already so I
suppose sometime in the past it has been necessary to do a downgrade.

In the case where the bug comes from upstream one should report it
upstream, but if it is something "serious" you have to report it in
Arch's bug tracker, the maintainer does not have a crystal ball to know
some nasty bug reared its head.
--
Mauro Santos
Carsten Mattner via arch-general
2017-04-20 22:37:10 UTC
Permalink
On Thu, Apr 20, 2017 at 8:27 PM, Mauro Santos via arch-general
Post by Mauro Santos via arch-general
Post by Ralf Mardorf
Post by Mauro Santos via arch-general
Have you reported the bug? If yes and the dev decides that it should be
man pacman | grep -A1 epoch
"Upstream or Arch?
[snip]
If Arch is not responsible for a bug, the problem
will not be solved by reporting the bug to Arch developers." -
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F
This policy isn't always pleasant ;), but the Arch developers sometimes
are willing to balance pros and cons, so sometimes they fix such
issues ;).
Maybe I should have been more specific, I was talking about
downgrading/reverting an update. That is why the epoch field exists and
it has been used before. Ffmpeg does have the mark of shame already so I
suppose sometime in the past it has been necessary to do a downgrade.
In the case where the bug comes from upstream one should report it
upstream, but if it is something "serious" you have to report it in
Arch's bug tracker, the maintainer does not have a crystal ball to know
some nasty bug reared its head.
Bug has been reported in Arch's tracker and there's a companion
bug from someone else about ffmpeg2.8. It makes sense to report
in Arch first because arch has published 3.3 in testing and maybe
ffmpeg's version scheme is just convoluted and 3.3 is unstable
while 2.8 and 3.2 (even numbers) were stable branches. ffmpeg.org
doesn't label 3.3 as a dev branch so I don't blame arch for
picking ffmpeg3.3. In fact it says 3.3 is a stable release.

The corruption is easy to reproduce and so obvious that I didn't
consider reporting it to ffmpeg.org. It looks impossible to slip
their tests.

I'm using ffmpeg 2.8.11 now, but since it's dangerous for other
users to have their files corrupted, I think an official downgrade
to 3.2.4 is in order.
Mauro Santos via arch-general
2017-04-20 23:00:12 UTC
Permalink
Post by Carsten Mattner via arch-general
Bug has been reported in Arch's tracker and there's a companion
bug from someone else about ffmpeg2.8. It makes sense to report
in Arch first because arch has published 3.3 in testing and maybe
ffmpeg's version scheme is just convoluted and 3.3 is unstable
while 2.8 and 3.2 (even numbers) were stable branches. ffmpeg.org
doesn't label 3.3 as a dev branch so I don't blame arch for
picking ffmpeg3.3. In fact it says 3.3 is a stable release.
In case of doubt you should ask upstream, doesn't mean it has to be a
bug report right away, you can start by asking in a mailing list. If it
turns out it really is a nasty bug then opening a bug in arch's bug
tracker for the current affected version is the way to go to get the
attention of the maintainer. Obviously you should provide links to
upstream's bug report or mailing list thread.
Post by Carsten Mattner via arch-general
The corruption is easy to reproduce and so obvious that I didn't
consider reporting it to ffmpeg.org. It looks impossible to slip
their tests.
I haven't used ffmpeg directly very much so I don't know if there are
any ways to shoot yourself in the foot, but you should consider that
what is broken and easy to reproduce for you might just work™ for
someone else. If upstream didn't catch it and no one else is complaining
you have to consider the problem _could_ be in your setup.
Post by Carsten Mattner via arch-general
I'm using ffmpeg 2.8.11 now, but since it's dangerous for other
users to have their files corrupted, I think an official downgrade
to 3.2.4 is in order.
If you've reported the bug both upstream and in arch's bug tracker and
it turns out it really is a nasty bug it will most probably either get a
downgrade or will be patched quickly (after upstream fixes it).
--
Mauro Santos
Guus Snijders via arch-general
2017-04-21 12:09:22 UTC
Permalink
Op 20 apr. 2017 19:56 schreef "Carsten Mattner via arch-general" <
arch-***@archlinux.org>:

If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered.


From a user POV, that is something where Arch really stands out (for me,
anyway).
My procedure was always:
#cleanup, keep current versions
pacman -Sc
#update all pkg's
pacman -Syu

And when I run into a buggy package, install the previous version from the
cached pkgs. That usually did the trick.

The important part is to only cleanup right before an upgrade.

Of course, this in itself does nothing for the packages in the repro, but
my users can happily keep working :).

The bugged pkg needs a report, of course, but usually someone has already
reported it by the time I see it.


Mvg, Guus Snijders
(With apologies for the messy HTML)
Carsten Mattner via arch-general
2017-04-21 16:05:01 UTC
Permalink
Post by Carsten Mattner via arch-general
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered.
From a user POV, that is something where Arch really stands out (for me,
anyway).
#cleanup, keep current versions
pacman -Sc
#update all pkg's
pacman -Syu
And when I run into a buggy package, install the previous version from the
cached pkgs. That usually did the trick.
Yes it's easy to downgrade manually on a single machine, but my
suggestion is about repo maintainers having a mechanism to force
a downgrade via the index. This is less of an issue for LTS distros
but important for non-testing users of Arch and other rolling distros.
The package maintainer cannot know that 3.3 has a corruption bug and
naturally trusts ffmpeg's announcement that 3.3 is a stable release.
I did too and was surprised. It's my first ffmpeg surprise and usually
ffmpeg is reliable.

I bring this up as a good precedent to consider such a mechanism
since corruption is the worst kind of regression. A crash is
easy to notice and work around but had I not watched the muxed
videos myself, I wouldn't have seen the corruption until the
number of videos would have been painfully large to queue for
remux/re-coding.

In the past there have been just crashes or buggy behavior that
only got fixed with the version-next++ and until then arch had
to live with the broken and regressed version as the default
since there wasn't a revoke/downgrade via the index. Since
you can downgrade manually, the index ought to have mechanism
for this too. Hope this makes sense.
Martin Kühne via arch-general
2017-04-21 16:13:33 UTC
Permalink
On Fri, Apr 21, 2017 at 6:05 PM, Carsten Mattner via arch-general
Post by Carsten Mattner via arch-general
In the past there have been just crashes or buggy behavior that
only got fixed with the version-next++ and until then arch had
to live with the broken and regressed version as the default
since there wasn't a revoke/downgrade via the index. Since
you can downgrade manually, the index ought to have mechanism
for this too. Hope this makes sense.
Such a feature would mean all dependencies would be flagged for
downgrades too, except when two packages a package depends on have
been upgraded. then an intermediate version with package A_old and
B_new. That should even be possible in the *usual* case, but we
*would* need a plan for when that wasn't possible, which would mean
forcing downgrade of package B because A_new cannot be satisfied
because package C depends on either being compatible, and we're kind
of dissolving the foundations of KISS on which arch is built. See what
I mean?

cheers!
mar77i
Ralf Mardorf
2017-04-21 16:45:48 UTC
Permalink
Post by Carsten Mattner via arch-general
In the past there have been just crashes or buggy behavior that
only got fixed with the version-next++ and until then arch had
to live with the broken and regressed version as the default
since there wasn't a revoke/downgrade via the index. Since
you can downgrade manually, the index ought to have mechanism
for this too. Hope this makes sense.
There already were "local is newer than" packages by official
repositories, IOW a new version of a package was provided by an
update and later an older version was provided. I don't remember an
example, but it definitively already happened.

However, those concerns about Arch's health are grotesque.

Please open a new thread for the ffmpeg topic and post the links to the
upstream bug report and to the Arch bug report. If you want to avoid
that others experience the same issue, this is the way to go.
Post by Carsten Mattner via arch-general
If you've reported the bug both upstream and in arch's bug tracker and
it turns out it really is a nasty bug it will most probably either get
a downgrade or will be patched quickly (after upstream fixes it).
At least upstream would fix it.

Bugs are something normal, even bugs that require to restore data from
backups, because the original data gets corrupted. Sometimes software
upgrades require to convert data for usage with the new software
version, so even when downgrading the software, the data needs to be
restored from a backup.

Hiccups aren't something that serious as Heartbleed was.

Even if _one_ bug should be very dangerous, it wouldn't make sense to
add a new revoke/downgrade feature, just for a single bug.
Oon-Ee Ng via arch-general
2017-04-22 02:04:07 UTC
Permalink
On Sat, Apr 22, 2017 at 12:05 AM, Carsten Mattner via arch-general <
Post by Carsten Mattner via arch-general
Yes it's easy to downgrade manually on a single machine, but my
suggestion is about repo maintainers having a mechanism to force
a downgrade via the index. This is less of an issue for LTS distros
but important for non-testing users of Arch and other rolling distros.
The package maintainer cannot know that 3.3 has a corruption bug and
naturally trusts ffmpeg's announcement that 3.3 is a stable release.
I did too and was surprised. It's my first ffmpeg surprise and usually
ffmpeg is reliable.
They do, it's called the epoch (see man PKGBUILD).
Eli Schwartz via arch-general
2017-04-20 13:20:37 UTC
Permalink
It's 2017, security doesn't mean unoptimized. There was attempt to
bring in more optimizations already used in Clearlinux project like
pgo and lto to makepkg but it's still on sidelines due to lack of
time from devs. See
https://aur.archlinux.org/packages/makepkg-optimize2/
Actually, Allan said he dislikes that concept entirely and refuses to
merge it at all because:
1) CFLAGS+="-flto" should be set in makepkg.conf, not libmakepkg
2) PGO will not be a thing because "I am not adding an option to makepkg
that does non-deterministic optimisation."
3) PGO that involves makepkg being context-sensitive between two makepkg
runs, is not an option; use a wrapper script with multiple
makepkg.conf's instead.

Lack of time is not the issue, in fact, Allan has reviewed *lots* of
pacman/makepkg patches, and merged lots of them, in the time he has
refused to even consider these.
Did you know this bug was reported by concerned user because dev
hadn't time for it for a half of year? Plus nobody ever explained why
minor bug in testsuite should be a blocker here. Also there are more
security flags to be enabled, trivial to add and blocked only by lack
of time/lack of will, even when other devs explicitly asked for
this.
Failing testsuites mean that real issues will never be discovered, which
means the whole point of running testsuites is nullified. So no, it is
not a minor bug.
I agree with the above but it's not the case here. Packages doesn't
stay in testing for extended period because actual problems are
resolved but because everyone who did his/her job has to wait for
someone who didn't. See
https://www.archlinux.org/todo/openssl-rebuild-take-2/ . Everything
is done except one package and nothing changed for weeks.
I don't know why openssl 1.1 is still in testing. But I do know that
merely assuming it is ready to be moved today except for that package,
is rather naive. I am going to assume that the Devs have actual reasons
for what they do.

Also, if your only point is that testing rebuilds get held up, I am not
sure what you expect us to do about it. Whatever the reason is, that can
only be fixed by the Devs, we have no influence over it in any way.

And if they are deliberately ignoring it for the lulz, your bribes won't
work; I guess we are just doomed by malice...

...

Aside: your emails seem to be wrapped in an over-aggressive manner, why
such short lines?
--
Eli Schwartz
Francisco Barbee via arch-general
2017-04-20 19:51:47 UTC
Permalink
 On 20 April 2017 at 16:21:21, Eli Schwartz via
Post by Eli Schwartz via arch-general
Actually, Allan said he dislikes that concept
entirely and refuses to
Post by Eli Schwartz via arch-general
1) CFLAGS+="-flto" should be set in
makepkg.conf, not libmakepkg
Post by Eli Schwartz via arch-general
2) PGO will not be a thing because "I am not
adding an option to makepkg
Post by Eli Schwartz via arch-general
that does non-deterministic optimisation."
3) PGO that involves makepkg being
context-sensitive between two makepkg
Post by Eli Schwartz via arch-general
runs, is not an option; use a wrapper script
with multiple
Post by Eli Schwartz via arch-general
makepkg.conf's instead.
Lack of time is not the issue, in fact, Allan
has reviewed *lots* of
Post by Eli Schwartz via arch-general
pacman/makepkg patches, and merged lots of them,
in the time he has
Post by Eli Schwartz via arch-general
refused to even consider these.
That was the beginning but it seems you didn't
follow the discussion, see:
https://lists.archlinux.org/pipermail/pacman-dev/2016-April/021028.html
https://bbs.archlinux.org/viewtopic.php?pid=1628371#p1628371
Post by Eli Schwartz via arch-general
Failing testsuites mean that real issues will
never be discovered, which
Post by Eli Schwartz via arch-general
means the whole point of running testsuites is
nullified. So no, it is
Post by Eli Schwartz via arch-general
not a minor bug.
Sorry, but that's pure speculation. Did you asked
upstream if this bug is serious or the actual
maintainer ask them? If one Arch user didn't
report it it would be never fixed.
Post by Eli Schwartz via arch-general
I don't know why openssl 1.1 is still in
testing. But I do know that
Post by Eli Schwartz via arch-general
merely assuming it is ready to be moved today
except for that package,
Post by Eli Schwartz via arch-general
is rather naive. I am going to assume that the
Devs have actual reasons
Post by Eli Schwartz via arch-general
for what they do.
Again you speculate. I've seen to many times
maintainers forget about their packages for months
until other devs name them explicitly in arch-dev
mailinglist.
Post by Eli Schwartz via arch-general
Aside: your emails seem to be wrapped in an
over-aggressive manner, why
Post by Eli Schwartz via arch-general
such short lines?
I'm very sorry. I was annoyed that discussion is
moving out of topic. That was inappropriate
Storm Dragon via arch-general
2017-04-20 20:18:45 UTC
Permalink
Howdy,
I offered once to learn all the stuff needed to become a TU to help out with package maintenance. The offer still stands, if someone is willing to talk with, help with training, and finally sponsor me. The offer still stands. I could work on Arch related stuff several hours per week if needed. I have a few packages I would move from the AUR, but not a ton, so I could addopt things that are orphaned, and help wherever needed. Of course, I'm just as happy maintaining my stuff in the AUR, but if I can help, I will.
Storm
--
Happy 4/20! Puff puff give!
Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html
My blog, Thoughts of a Dragon: http://www.stormdragon.tk/
get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
Twitter and Facebook are so ... yesteryear. Get your 2MB Social account TODAY! http://2mb.social/main/register
Need a safe and easy way to backup and share files? Try Dropbox: http://db.tt/jeY50HR
"with a trunk big enough to fit three bodies in"
Calabrese - Crizila
Jelle van der Waa
2017-04-21 06:57:23 UTC
Permalink
Post by Storm Dragon via arch-general
Howdy,
I offered once to learn all the stuff needed to become a TU to help out with
package maintenance. The offer still stands, if someone is willing to talk
with, help with training, and finally sponsor me. The offer still stands. I
could work on Arch related stuff several hours per week if needed. I have a
few packages I would move from the AUR, but not a ton, so I could addopt
things that are orphaned, and help wherever needed. Of course, I'm just as
happy maintaining my stuff in the AUR, but if I can help, I will. Storm
--
You can start by going through the bugtracker, there are plenty of bugs
which need to be triaged, reported upstream or potential fixes in
packaging which in the form of patches can be created and attached to a
bug.
--
Jelle van der Waa
Eli Schwartz via arch-general
2017-04-20 21:07:38 UTC
Permalink
Post by Eli Schwartz via arch-general
Lack of time is not the issue, in fact, Allan has reviewed *lots*
of pacman/makepkg patches, and merged lots of them, in the time he
has refused to even consider these.
That was the beginning but it seems you didn't follow the discussion,
https://lists.archlinux.org/pipermail/pacman-dev/2016-April/021028.html
https://bbs.archlinux.org/viewtopic.php?pid=1628371#p1628371
I remember that. A badly-written patch for something far more generic,
that Allan agreed he would be potentially willing to merge, but which
really needs to be fixed and which anyway does not implement PGO, LTO,
or anything similar (since Allan continues to believe that libmakepkg
should not do this even if thirdparty libmakepkg extensions do).

Maybe Allan would merge the stub for extending buildenv, if someone who
actually cared would fix it. In the meantime, once again there are
wrapper scripts...
Post by Eli Schwartz via arch-general
Failing testsuites mean that real issues will never be discovered,
which means the whole point of running testsuites is nullified. So
no, it is not a minor bug.
Sorry, but that's pure speculation. Did you asked upstream if this
bug is serious or the actual maintainer ask them? If one Arch user
didn't report it it would be never fixed.
It is completely irrelevant whether upstream thinks testsuite failures
are serious bugs. What matters is, the Arch maintainer for binutils
*absolutely refuses* to enable anything that causes testsuite failures.
It *has* been reported upstream. It hasn't been fixed yet, AFAIK.
Post by Eli Schwartz via arch-general
I don't know why openssl 1.1 is still in testing. But I do know
that merely assuming it is ready to be moved today except for that
package, is rather naive. I am going to assume that the Devs have
actual reasons for what they do.
Again you speculate. I've seen to many times maintainers forget about
their packages for months until other devs name them explicitly in
arch-dev mailinglist.
I am speculating just as much as you are speculating, so how about we
compromise and *both of us* shut up?

:D
Post by Eli Schwartz via arch-general
Aside: your emails seem to be wrapped in an over-aggressive manner,
why such short lines?
I'm very sorry. I was annoyed that discussion is moving out of topic.
That was inappropriate
I am not even sure what the text formatting options of your email
software has to do with your emotional state of mind regarding this
thread. This is a purely software-related matter!

Regardless... you are still doing it. Please fix your software or use
something that isn't broken, because it is difficult to read what you
write when my email software (Thunderbird) renders your email as
completely mangled.

It appears that whatever you are using, is breaking every line in two.
Which is irritating in your replies (because super-short lines are
awkward) and downright broken in your quotes, because every other line
gets *unquoted*.

(I have extensively edited my own quotes, to ensure proper quoting
levels and line-wrapping. This is quite tiresome...)
--
Eli Schwartz
Ivy Foster via arch-general
2017-04-21 01:23:09 UTC
Permalink
Post by Jelle van der Waa
PIE is blocked by upstream because of this bug iirc. [1]
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
Plus nobody ever explained why minor bug in testsuite should be
a blocker here.
Because binutils is a vital system component that it is very, very
important to have working. It's one of those programs whose tests you
absolutely do not want failing, since you're subsequently using it to
link, well, *everything*.

if
Eli Schwartz via arch-general
2017-04-21 02:08:11 UTC
Permalink
Post by Ivy Foster via arch-general
Post by Jelle van der Waa
PIE is blocked by upstream because of this bug iirc. [1]
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
Plus nobody ever explained why minor bug in testsuite should be
a blocker here.
Because binutils is a vital system component that it is very, very
important to have working. It's one of those programs whose tests you
absolutely do not want failing, since you're subsequently using it to
link, well, *everything*.
Excuse me, are we or are we not a distro which prides itself on the fact
that we live on the bleeding (straight) edge???

Just ask phrik:
10:05:03 PM - eschwartz: archlinux
10:05:05 PM - phrik: Livin' life on the hemorrhaging edge!

I've changed my mind -- we should immediately enable PIE.
:p :p
--
Eli Schwartz
Dragon ryu via arch-general
2017-04-21 02:44:37 UTC
Permalink
2017/04/21 午前11:08 "Eli Schwartz via arch-general" <
Post by Ivy Foster via arch-general
Post by Jelle van der Waa
PIE is blocked by upstream because of this bug iirc. [1]
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090
Plus nobody ever explained why minor bug in testsuite should be
a blocker here.
Because binutils is a vital system component that it is very, very
important to have working. It's one of those programs whose tests you
absolutely do not want failing, since you're subsequently using it to
link, well, *everything*.
Excuse me, are we or are we not a distro which prides itself on the fact
that we live on the bleeding (straight) edge???

Just ask phrik:
10:05:03 PM - eschwartz: archlinux
10:05:05 PM - phrik: Livin' life on the hemorrhaging edge!

I've changed my mind -- we should immediately enable PIE.
:p :p

--
Eli Schwartz

lol
Yeah Bug tester and edge-liver is in need.
Insight Thekrab via arch-general
2017-04-22 17:42:02 UTC
Permalink
i thint it should be easier to let people help mantainers in software
packaging.
Post by Ralf Mardorf
Hi,
I would be concerned, if too many security features not everybody needs,
would become default. Why not dropping security features completely and
instead making real-time optimised features the default? This is a
rhetorical question, but actually I would prefer the latter.
In my experiences Arch is very healthy.
I doubt that many packages are outdated.
Right off the bat a few come to mind, e.g.
claws-mail and clawsker
but we had Easter holidays and some packages are already in testing.
Other packages, such as e.g.
ardour
are out of date for a long time, but the maintainer explained why he has
got no time for a while. Apart from this Ardour is niche software.
Each of the outdated packages I noticed still build using ABS or AUR
PKGBUILDs by just changing the version and skipping or changing the
checksums or they require minimal additional editing, if so I
usually drop a note to AUR comments, how to fix the issue.
It's hard to find much more packages I consider really outdated.
I noticed that some packages from official repositories are flagged out
of date, a few minutes after upstream released a new version, so I
wouldn't count those packages.
In my experiences Arch is a healthy rolling release. There are a few
hiccups, but I experience less hiccups using Arch, than I experience
serious issues with other distros.
Regards,
Ralf
Jelle van der Waa
2017-04-20 07:11:33 UTC
Permalink
Post by ITwrx.org
i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.
why am i concerned?
--
Information Technology Works
https://ITwrx.org
@ITwrxorg
Wait, actual question is about PIE?
If you find that package are outdated in community or extra, file a bug rep.
Why not do it?
Can you please fix your client to reply sanely and not append your own
text to the original mail it's confusing and silly.

And again don't file bug reports for out of date packages..
--
Jelle van der Waa
fnodeuser
2017-04-23 08:00:23 UTC
Permalink
ITwrx.org,

health? AL is not an organism, it is an OS. what you meant to say is problems.

yes, it is true. there are a few problems, but these problems were not caused by
a lack of funds.

these are the reasons there are problems:

1. there are a few AL TMs (team members), that wanted to become, became, and still are
AL TMs because they are selfish.

these TMs are here, because they want to indirectly benefit financially from this
membership, and/or for the 'bragging rights', and/or because they want to continue
to have the 'power' that an AL TM has.

the rest of the TMs are here because they care about AL, the community, and progress.

2. both groups of AL TMs have different workloads and not always a lot of free time.
changes in circumstances can and will determine how much work must be done and how
much free time a TM has to do AL work.

3. ignorance and/or stupidity.


now, the good thing is that these problems have solutions.

one of the things we can do to help solve these problems (and make their workloads
smaller), is with user sign-offs.[1]

this way, Tobias Powalowski, for example, will stop placing the linux pkg in testing for
stable minor releases.

_
[1] https://lists.archlinux.org/pipermail/arch-general/2016-June/041510.html
Ralf Mardorf
2017-04-23 09:26:06 UTC
Permalink
Post by fnodeuser
there are a few AL TMs (team members), that wanted to become,
became, and still are AL TMs because they are selfish.
these TMs are here, because they want to indirectly benefit
financially from this membership, and/or for the 'bragging rights',
and/or because they want to continue to have the 'power' that an AL TM
has.
Unlikely that being an Arch Linux team member gains much for an ego in
regards to adorn oneself with plumes, regarding power or that it's very
useful to indirectly benefit financially. It's moreover much
unlikely that not just one, but a few team members suffer from such
bizarre narcissism.

This thread started with questioning the overall health of Arch. So far
this is just based on the emotion of a few users, who consider the
hiccups they experience as dramatic, serious issues. IOW so far it was
just pathetic.

Now you come and claim that there are "problems" and the first reason,
among other reasons are disordered team members. You don't provide any
evidence for this claim. This is the lowest level of polemic.

Could we please stop this thread? IMO it's going too far now.

There's nothing wrong with pointing to real problems. You could do this
by opening a new thread, but please without conspiracy theories. If
there should be bizarre team members, the other team members are likely
able to notice this and to resolve this without a discussion by users.
Loading...