[Slackbuilds-users] Plex version too old

[Jeremy Hansen]

On Fri, May 4, 2018, 12:42 PM JCA <1.41421 at gmail.com> wrote:

> On Fri, May 4, 2018 at 10:50 AM, Matteo Bernardini <
> matteo.bernardini at gmail.com> wrote:
>
>> 2018-05-04 18:40 GMT+02:00 JCA <1.41421 at gmail.com>:
>> > Fair enough. Now make sure to enter the gist of this in the Slackbuilds
>> home
>> > page, in a big font, so nobody will be led to think that packages are
>> > properly maintained throughout.
>>
>> it's not that finding a limited number of not maintained SlackBuilds
>> means that all of 7000 of them are unmaintained: just calculate the
>> percentage and you can see they are a very small part.
>>
>
> The fact still remains that poorly maintained packages exist. Why not say
> so, if it is true?
>
> 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.
>
>
>> >> Meanwhile, thanks for the report.
>> >
>> >
>> > Any time. My hope is that will do something to improve things for this,
>> and
>> > other packages in similar situations of abandonment.
>>
>> IMHO is only maintaining stuff yourself that helps in these cases.
>>
>
> 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.
>
>
>>
>> 2018-05-04 18:44 GMT+02:00 JCA <1.41421 at gmail.com>:
>> > <matteo.bernardini at gmail.com> wrote:
>> >> ...and this exposes the real issue: pretty much nobody reads the
>> >> READMEs or the scripts they run in the first place.
>> >
>> >
>> > Precisely. Which is why I was suggesting the Slackbuilds home page, in
>> a big
>> > font. In obnoxiously flashing text, if you want. That does not guarantee
>> > that people will read it, but it is far more difficult to miss. This
>> aside,
>> > that's boilerplate, legalese stuff. What matters is what can be
>> reasonably
>> > expected.
>>
>> I think you got this completely wrong: if you don't read the READMEs
>> and the scripts you run, it's just your fault and you shouldn't blame
>> nobody else.
>>
>
> 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.
>
> 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.
>
>
>> Matteo
>> _______________________________________________
>> SlackBuilds-users mailing list
>> SlackBuilds-users at 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 at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/


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?

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

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.

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.

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.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20180504/006f2f45/attachment.html>