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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
