<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="auto">
<div>>> <span style="font-family: sans-serif;">Hint to alsa-enthusiasts:</span><span style="font-family: sans-serif;"> suggest your alsa-tested switch arrangement directly to the relevant maintainers</span><span style="font-family: sans-serif;">. I'm sure such
suggestions would mostly be adopted provided T</span><span style="font-family: sans-serif;">hey don't adversely affect normal systems. </span></div>
<div dir="auto"><font face="sans-serif"><br>
</font></div>
<div dir="auto"><font face="sans-serif">Isn't that exactly what Hunter has done?<br>
</font>
<div class="gmail_extra" dir="auto"><br>
<div class="gmail_quote">On May 9, 2018 5:53 PM, Christoph Willing <chris.willing@iinet.net.au> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">On 10/05/18 06:53, Richard Narron wrote: <br>
> On Tue, 8 May 2018, Matteo Bernardini wrote: <br>
> <br>
>> 2018-05-07 23:36 GMT+02:00 orbea@fredslev.dk <orbea@fredslev.dk>: <br>
>>> That assumption is irrelevant and if a maintainer is not willing to <br>
>>> respond to bug reports then it should be possible to implement fixes <br>
>>> without the maintainer. <br>
>>> <br>
>>> The bottom line is that this patch would make the qt5.SlackBuild more <br>
>>> fail proof and the only reason to not accept it is to spite people who <br>
>>> do not use pulseaudio. This can only have a negative effect on the <br>
>>> usefulness and reliability of SBo... <br>
>> <br>
>> we have different opinion on what is a bug an what are legit <br>
>> maintainer decisions. <br>
>> optional pulseaudio support is surely not a bug: pulseaudio is not <br>
>> optional at all in slackware 14.2 and I explained why we cannot <br>
>> consider it optional even in the next Slackware release: stuff in <br>
>> /extra is not part of a Slackware full installation and we support <br>
>> just that. <br>
>> that said, is up to the maintainer if they want to add a switch in <br>
>> their SlackBuilds to make pulseaudio optional (with pulseaudio enabled <br>
>> by default, of course), and it's up to the users to use it (under <br>
>> their own responsibility) or not. <br>
> <br>
> I would suggest that the alsa files in /extra are not actually "extra". <br>
> They are replacements for standard pulseaudio Slackware current packages. <br>
> <br>
> It would be hard for someone with with pulseaudio to test the alsa side of <br>
> things and hard for someone with alsa to test the pulseaudio side of <br>
> things. <br>
> <br>
> So instead of an alsa-pulseaudio switch perhaps we should allow two sets <br>
> of packages, the standard ones with pulseaudio and another set with alsa. <br>
> <br>
<br>
How would that make testing any easier for a maintainer - or are you <br>
suggesting having multiple maintainers too? It sounds like a lot of <br>
complication just for the sake of the few SlackBuilds that would <br>
actually be involved. <br>
<br>
No doubt alsa enthusiasts are smart enough to make their own changes in <br>
cases where the maintainer hasn't adopted some pulseaudio/alsa switch <br>
arrangement. <br>
<br>
Hint to alsa-enthusiasts: <br>
suggest your alsa-tested switch arrangement directly to the relevant <br>
maintainers. I'm sure such suggestions would mostly be adopted provided <br>
they don't adversely affect normal systems. <br>
<br>
chris <br>
<br>
_______________________________________________ <br>
SlackBuilds-users mailing list <br>
SlackBuilds-users@slackbuilds.org <br>
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users <br>
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ <br>
FAQ - https://slackbuilds.org/faq/ <br>
<br>
</p>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</body>
</html>