<div class="gmail_quote"><div dir="ltr">On Fri, May 4, 2018, 12:42 PM JCA <<a href="mailto:1.41421@gmail.com">1.41421@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 4, 2018 at 10:50 AM, Matteo Bernardini <span dir="ltr"><<a href="mailto:matteo.bernardini@gmail.com" target="_blank">matteo.bernardini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-05-04 18:40 GMT+02:00 JCA <<a href="mailto:1.41421@gmail.com" target="_blank">1.41421@gmail.com</a>>:<br>
> Fair enough. Now make sure to enter the gist of this in the Slackbuilds home<br>
> page, in a big font, so nobody will be led to think that packages are<br>
> properly maintained throughout.<br>
<br>
it's not that finding a limited number of not maintained SlackBuilds<br>
means that all of 7000 of them are unmaintained: just calculate the<br>
percentage and you can see they are a very small part.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The fact still remains that poorly maintained packages exist. Why not say so, if it is true?</div><div><br></div><div>This aside, my own experience is that I have to massage things often to get them to work - admittedly mostly in straightforward ways, although the plexmediaserver fiasco is not a first. Also bear in mind that package that has not been updated in a long time might still work, but might be missing important patches, security upgrades and improvements. Again, something that a good maintainer should be on top of.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> Meanwhile, thanks for the report.<br>
><br>
><br>
> Any time. My hope is that will do something to improve things for this, and<br>
> other packages in similar situations of abandonment.<br>
<br>
IMHO is only maintaining stuff yourself that helps in these cases.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>True. However, like I said, I, and many like me, are not interested in maintaining, but on using. Again, this may be something frowned upon in this forum, and not in the spirit of Slackbuilds. This would be completely legitimate - just make it obvious in the home page that, if you want to make sure that a package is really functional, you should maintain it yourself, for it is neither the purview nor the responsibility of the Slackbuilds team to guarantee that maintainers of Slackbuilds packages are doing what they committed to do. This is what is already happening; it is just that, as a new Slackware/Slackbuilds user, one may not be aware of that initially. I think that not making this clear to such users amounts to making them a disservice.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2018-05-04 18:44 GMT+02:00 JCA <<a href="mailto:1.41421@gmail.com" target="_blank">1.41421@gmail.com</a>>:<br>
> <<a href="mailto:matteo.bernardini@gmail.com" target="_blank">matteo.bernardini@gmail.com</a>> wrote:<br>
>> ...and this exposes the real issue: pretty much nobody reads the<br>
>> READMEs or the scripts they run in the first place.<br>
><br>
><br>
> Precisely. Which is why I was suggesting the Slackbuilds home page, in a big<br>
> font. In obnoxiously flashing text, if you want. That does not guarantee<br>
> that people will read it, but it is far more difficult to miss. This aside,<br>
> that's boilerplate, legalese stuff. What matters is what can be reasonably<br>
> expected.<br>
<br>
I think you got this completely wrong: if you don't read the READMEs<br>
and the scripts you run, it's just your fault and you shouldn't blame<br>
nobody else.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>And I think that you are not being realistic. Since probably the vast majority of freely distributed software packages contain similarly-worded disclaimers, those words mean very little. A very conspicuous warning in the Slackware home page would command more attention. And would kill discussions like this before they are even born, for everybody who has visited the Slackbuilds page even once would have no choice but to see the warning. </div><div><br></div><div>Just make it clear in that page that Slackbuilds is for enthusiasts, by enthusiasts; that packages may, or may not, work; that they may, or may not, be maintained; that the vast majority of them seem to be maintained and work, although nothing can be guaranteed; that, if you want to make sure, just maintain yourself the packages that you are interested in. That's the way it is. And it may be intentional. Which would, again, be completely legitimate.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Matteo<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div></div></div>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a></blockquote></div><div><br></div><div>So, we have a project that you're using, but refuse to contributing to (other than bug reports and complaints) and yet you complain that it isn't being run the way *you* want? Even when the admins all state it's been run the way *they* want?</div><div><br></div><div>You seem to think that the frontpage will be read, but most people probably use tools to interact with SBo (sbotools, sbopkg, slackrepo, etc), so a notice on the frontage would go unnoticed. We already know that a lot of READMEs go unread based on reports here and on LQ. If anything belongs anywhere, it'd probably be an entry in the FAQ on if a package isn't working as expected and what to do (which may already be there, but I'm on mobile and too lazy to look).</div><div><br></div><div>Why is it so hard to just contact the maintainer when something is broken (especially since there's a link on that SlackBuild's page)? You can even CC this list in case the maintainer doesn't respond.</div><div><br></div><div>The amount of scripts that are broken are probably quite small, and if the maintainers aren't quick to respond or it's an easy fix, the admins will usually fix it relatively quick.</div><div><br></div><div>Long story short, the current prices works great for almost everyone but you. Since you refuse to take up the mantle of maintainership, you lose a lot of credibility when you complain how others, who have stepped up at some point, handle their SlackBuilds. And it isn't always trivial to get a SlackBuild generated, especially when you need to create patches, rc files, or other tweaks that may be required.</div><div><br></div><div>Jeremy</div>