[Slackbuilds-users] movgrab

[Willy Sudiarto Raharjo]

>> It seems a recurring SBo theme is that some former maintainer gives up
>> on maintaining one or more given slackbuilds, and it becomes orphaned.
>> I know some people are doing great amounts of work maintaining
>> slackbuilds, and so it doesn't make sense to expect these active
>> people to do even more work.
>>
>> What might be nice is for volunteers who have limited time to be able
>> to help out on an as-able basis.
>>
>> One possible solution would be to let "anyone" (or maybe some people
>> on a "B Team" list) submit updates to any slackbuild at all.  If it is
>> not orphaned, the maintainer could "bless" the update and push it
>> through the system.  This might take a load off people who maintain a
>> lot of slackbuilds, which would be a good thing.
>>
>> If the slackbuild is orphaned, some "A Team" person could give it a
>> very quick look to make sure that the "B Team" person hasn't messed
>> up, and then submit it, marking the slackbuild as "orphaned, use at
>> your own risk (even more than usual)".
>>
>> As a recent example, Didier points out that a only a very trivial
>> change to the movgrab slackbuild is required (and probably an equally
>> trivial change to the download link).  He doesn't want to maintain it,
>> and nor do I.  Maybe someone who cares enough will volunteer, maybe
>> not.
>>
>>
>> As a concrete example, I'd be happy to submit such an update to
>> packages I use whenever I find something is out of date, but I don't
>> necessarily want to become the maintainer.  Having some middle ground
>> might improve the whole SBo experience.
> 
> IMO that would just complicate things and overall need more work for the
> admins.
> 
> Just following answer #14 n the FAQ:
> http://slackbuilds.org/faq/#version_update
> is simpler.
> 
> Whilst if a maintainer is no longer active it's good to search a
> volunteer to take over, I guess that till then it's easier for the
> admins to just make the version change (for instance and only if they
> want to) themselves, than to rely on a "B team". And I am pretty sure
> that "use at your own risk" is a no-go for SlackBuilds.org anyway as
> they have build their reputation on users' trust.
> 
> Eager to read one of the admins' opinion, though ;)

This is my opinion as a maintainer, not as an admin :)

It's the maintainer's job to make sure a package is working well because
normal people will not care about who's updating it and they rarely see
cgit interface to see the history. All they see is the individual files
or tarball from our website if they use automatic tool.
if they found any problem, they will contact the maintainer's first, not
the last person updating them.

my suggestion is to follow the guidelines.
Contact the maintainer and if no response in reasonable time, feel free
to take over maintainership.
If you are a maintainer and no longer wanted to keep the package or
probably having no time to update or even worse, no longer use
Slackware, please let others know in this mailing list so others can
take over.


-- 
Willy Sudiarto Raharjo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20150727/c3ac9272/attachment.asc>