>> Hint to alsa-enthusiasts: suggest your alsa-tested switch arrangement 
>> directly to the relevant maintainers. I'm sure such suggestions would mostly 
>> be adopted provided They don't adversely affect normal systems.

Isn't that exactly what Hunter has done?

On May 9, 2018 5:53 PM, Christoph Willing <chris.will...@iinet.net.au> wrote:

On 10/05/18 06:53, Richard Narron wrote:
> On Tue, 8 May 2018, Matteo Bernardini wrote:
>
>> 2018-05-07 23:36 GMT+02:00 or...@fredslev.dk <or...@fredslev.dk>:
>>> That assumption is irrelevant and if a maintainer is not willing to
>>> respond to bug reports then it should be possible to implement fixes
>>> without the maintainer.
>>>
>>> The bottom line is that this patch would make the qt5.SlackBuild more
>>> fail proof and the only reason to not accept it is to spite people who
>>> do not use pulseaudio. This can only have a negative effect on the
>>> usefulness and reliability of SBo...
>>
>> we have different opinion on what is a bug an what are legit
>> maintainer decisions.
>> optional pulseaudio support is surely not a bug: pulseaudio is not
>> optional at all in slackware 14.2 and I explained why we cannot
>> consider it optional even in the next Slackware release: stuff in
>> /extra is not part of a Slackware full installation and we support
>> just that.
>> that said, is up to the maintainer if they want to add a switch in
>> their SlackBuilds to make pulseaudio optional (with pulseaudio enabled
>> by default, of course), and it's up to the users to use it (under
>> their own responsibility) or not.
>
> I would suggest that the alsa files in /extra are not actually "extra".
> They are replacements for standard pulseaudio Slackware current packages.
>
> It would be hard for someone with with pulseaudio to test the alsa side of
> things and hard for someone with alsa to test the pulseaudio side of
> things.
>
> So instead of an alsa-pulseaudio switch perhaps we should allow two sets
> of packages, the standard ones with pulseaudio and another set with alsa.
>

How would that make testing any easier for a maintainer - or are you
suggesting having multiple maintainers too? It sounds like a lot of
complication just for the sake of the few SlackBuilds that would
actually be involved.

No doubt alsa enthusiasts are smart enough to make their own changes in
cases where the maintainer hasn't adopted some pulseaudio/alsa switch
arrangement.

Hint to alsa-enthusiasts:
    suggest your alsa-tested switch arrangement directly to the relevant
maintainers. I'm sure such suggestions would mostly be adopted provided
they don't adversely affect normal systems.

chris

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/


_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Reply via email to