[arch-general] signoff kernel26-2.6.24.3-6

[Roman Kyrylych]

2008/3/24, RedShift <redshift at pandora.be>:

[skipped]

>  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)

Disagree. *buggy* software needs patches too, and also "wouldn't work
*at all*" is different depending on configurations (Hint: xorg)
(yes, there is a chance to broke something else, so this should be
done carefully)

IMO patches for better hardware support are not bad if unintrusive.
It's ok that people have different opinions on this.

>  * 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

Agree.
Please report bugreports for those packages that you think should be improved,
because it's hard to track them down and fix all in one step.

>  * 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

Agree completely.

>  * No handholding (like, no automatic stopping of daemons upon pre
>  remove, adding of groups, etc...)

The feature request for autostopping daemons was denied AFAIR,
if some packages do this - please file a bugreport.

>  * 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)

(Dis)agree partially.
Then 95% of users will have to fix a lot of upstream bugs on every
major kernel/udev/dbus/xorg/etc. upgrade.
I see it as a plus to save people's time for more interesting things
by fixing those issues in one place (official packages).
However, things like "OMG! Pidgin's tray icon is disappearing in some
situations. Please fix ASAP!" should be sent to upstream by users, and
those reports should (and actually are) closed as "Won't fix".

>  * 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

This was discussed in past. IIRC it was decided to do some branding
while trying to make it optional (separate addon packages where
possible). (and I feel OK with that)
Things are still inconsistent though and I cannot say I am happy with
the inconsistency.

>  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?

Ugly? I never hear that, but people's tastes are so different...
I actually find it looking pretty nice.
So I totally agree with "So what?" here. :-)

>  But when you have a kernel26 PKGBUILD
>  that's 320 lines long, that simplicity is gone.

It's fun that the kernel is the most often questioned part, and not,
say, xorg-server which have tons of patches too, but I haven't heard
complaints about it.

-- 
Roman Kyrylych (Роман Кирилич)