[Slackbuilds-users] A question about maintaining perl/* slackbuilds.

[Heinz Wiesinger]

On Saturday 19 July 2014 13:42:51 Zachary Storer wrote:
> On Sat, Jul 19, 2014 at 01:52:38PM -0500, Erik Hanson wrote:
> > It's fine if you'd like to send us a patch to change the download links to
> > whatever is working/recommended, but taking over or updating scripts on
> > behalf of someone else requires their permission.
> 
> Ok, the problem is this: If we decide to use the freenode #perl's
> recommended www.cpan.org as the cpan link, then we will have to upgrade
> many of the perl/ slackbuilds, because, as far as I know,
> www.cpan.org doesn't provide some of the older versions for those
> slackbuilds.
> 
> Therefore, our options would be to email every perl/ slackbuild
> maintainer asking them to upgrade their slackbuild, use
> metacpan.org as the download link for the slackbuilds, or I could
> submit a patch that upgrades all of the slackbuilds at once, while also
> switching from search.cpan.org as the download link to use www.cpan.org,
> without the permission of the individual slackbuild maintainers.

You're jumping to conclusions here. *Some* SlackBuilds might have outdated 
links. That does not lead to anyone emailing *all* perl SlackBuild 
maintainers. At most this affects the maintainers of SlackBuilds where the 
current versions are not hosted at www.cpan.org.

> To me, it initially seems that in the future if we were to automate the
> upgrading of perl/ slackbuilds it would be nice to not have to ask each
> and every maintainer for permission to do this.

Mass updates are an exception, not a rule. And we haven't yet established that 
what is required to do at this point qualifies as a mass update at all. Before 
talking about bending rules, first focus on creating an actual overview of the 
fixes that need to be performed.

> For example, for my recent
> patch to fix perl/perl-IO-Tty I didn't hear back from the maintainer at
> all. This could make mass updates slow. Although, perhaps you guys have
> a good reason for having one maintainer per perl slackbuild.

First, there is no such thing as "one maintainer per perl slackbuild", it's 
"one maintainer per SlackBuild". And yes, it can be slow, but that's the 
nature of email conversation. Sometimes you can speed things up by talking to 
people on IRC.
The philosophy here is that maintainers know their application best and are 
presumably most suited to judge the impact of a change. Remember, that the 
SlackBuilds within perl are not self-contained. There are outside dependencies 
that need to be considered as well.

Grs,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20140719/3c62d518/attachment.asc>