[arch-general] signoff kernel26-2.6.24.3-6

[RedShift]

Simo Leone wrote:
> On Mon, Mar 24, 2008 at 07:28:13PM +0100, Tobias Powalowski wrote:
>> Users are happy with the new ISOs, just read the Forum thread about it.
>>
> You know what. I don't care if the users are happy with the new ISOs. 
> That's right, I finally said it.
> _I DON'T CARE_ 
> 
> I don't care because _I_ am not happy with them. As someone who can see
> that from a technological standpoint, it's a marvel that they even work,
> that is, as a software developer, I'm ashamed to be associated with such
> a shoddy product. 
> 
> I've offered alternatives, hell I've spent a lot of time offering 
> alternatives, built on more solid software enginerring principles
> than "Users are Happy", but no one around here, save Dan and Aaron, who
> just happen to be code contributors, seems to give a damn. What's up 
> with that?
> 

*** Prelude ***
This discussion was started when tpowa was asking for a signoff on the
kernel26 package, which includes patches for an out-of-tree kernel
module for a certain wireless card.


*** What Dan McGee said ***

I have an Eee, I managed to pull off an FTP install just fine.

I compiled the driver by hand, just as has always been the case for
out-of-tree driver with Arch if there is not already a separate
package for it.

I did this 22 months ago for my zd1211 wireless stick before it was in
the mainline kernel, and I had *0 days of desktop linux experience* at
that time (on my own machine). 0 days. And now we bend over backwards
for someone needing a driver? Ugh. I thought April fools and the
rename to Newb Linux wasn't for another week.

-Dan

*** My response ***

I find myself in 100% agreement on Simo's and Dan's opinion. I've warned
for this situation before (see the bug tracker). An example should be
taken from CRUX, they've held true to their principles and said screw
those who don't agree. And they're right, otherwise we're just on the
road to the next Ubuntu.

Lots of software is patched nowadays, even for very stupid things most
of the old user base wouldn't have cared about. And when PKGBUILDs
starts to grow to the point they need scrolling and comments to be
clarified, that's just going the wrong way. (Hint, kernel26 PKGBUILD).

I wanted to steer clear of personal attacks but unfortunately, tpowa has
been a large contributer to the "lets adapt to the community"-style. I'm
sorry to say it, but that's how I experience it (because of his work on
kernel26 and qt) - and it needs to be said! Arch used to be different. I
wouldn't be very surprised if Judd raised eyebrows on what's been going
on lately.

Notice the large influx of new users. The fact alone that a topic has
been started for a stable package repository *and people are willing to
contribute to this*, shows the kind of users we're getting: the wrong
ones. There has been an ongoing discussion on the bug tracker whether or
not post uninstall scripts should stop daemons upon removal. These ideas
come from users that are either inexperienced, or trying to mold Arch in
something its not. And what about dependencies in initscripts... wtf?
Any sane user can find them out for themselves and put them in the right
order in rc.conf. What if someone doesn't want this behaviour? For
example I don't want dbus and hal started, but what if the kdm rc.d
script will do this for me? It ends up with a pretty big mess. Let alone
the complexity that is added to the initscripts.

What Arch needs, is to say NO to things. There will always be users that
disagree, can't use some package because it doesn't fit them. Especially
the kernel, all these half-baked largely untested patches for things
only a few people (or even just 1) use is a threat to the stability of
the kernel package. I've had my share of hardware that didn't work for
me, these issues are solved by either compiling your own kernel,
replacing the hardware or simply waiting for the next kernel release.
But adding largely untested and nobody-knows-where-it-came-from patches
to the kernel is *evil*.

Another example is the addition of the uucp group by default to
/etc/groups. The number of users that use dailup and faxing is *so
limited*. And they can just as well addgroup themselves. But meanwhile,
all the other users have to take this uucp crap on a default install.
And don't say they can groupdel afterwards, Arch is supposed to be slim
BY DEFAULT. If people need to start removing crap after they've
installed Arch, then something is definitely wrong.

What Arch needs is to have strict guidelines on PKGBUILDs and kick out
any developers that don't have the same idea. A proposition:
* Patches are unacceptable unless in the case the software wouldn't work
*at all* (Hint, qt PKGBUILD)
* Pre and post install/remove actions should be kept at a minimum.
Assume the user is smart (quite the opposite of the current trend).
Everybody can read the manpage to adduser and addgroup. Post install
echos pointing out small hints to get going quickly is acceptable
* Stress the fact that users must read pacman's output and the news.
Alot of problems on IRC are related to the fact that people are lazy and
don't read pacman's output _at all_. That's their own damn fault
* No handholding (like, no automatic stopping of daemons upon pre
remove, adding of groups, etc...)
* Bugs and other issues that come from upstream, _should be fixed
upstream_. If people do have problems with a certain issue, they can abs
and makepkg themselves. (See rule 1)
* No branding or "Arch defaults". It only makes the PKGBUILDs more
complex, and ruins the idea of the software coming in its original form
from the authors

Another point of interest may be that many people used to find gnome
coming "ugly" by default (I don't know if this still the case). So what?
  Selecting your own theme is just a few mouse clicks away. Arch should
never come with a fscked up KDE or Gnome profile like Ubuntu and others
do. In fact, packages should *always* come with the defaults shipped by
upstream.

That being said, there's no such thing as one size fits all. There will
*always* be users that "fall out of the boat" (a Dutch expression). But
the fact is, because of Arch's simplicity, Arch can be made to work for
these people in a very easy way. But when you have a kernel26 PKGBUILD
that's 320 lines long, that simplicity is gone.

The users should adapt to Arch, not the other way around.

Glenn