From 2271286079397b8f9f1adc23e36c35a5d8ea35e2 Mon Sep 17 00:00:00 2001 From: Will Kahn-Greene Date: Sat, 30 Jul 2011 19:52:19 -0400 Subject: 270, 459. extlib policy, JS -> lgpl, ... * adds README to extlib/ * changes javascript to lgpl * also fixes the agplv3 text so that it says "agplv3 or later" * moves license files into licenses/ * adds lgplv3 license --- extlib/README | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 extlib/README (limited to 'extlib/README') diff --git a/extlib/README b/extlib/README new file mode 100644 index 00000000..c23da6e6 --- /dev/null +++ b/extlib/README @@ -0,0 +1,71 @@ +========================= + External Library README +========================= + +DO NOT "FIX" CODE IN THIS DIRECTORY. + +ONLY UPSTREAM VERSIONS OF SOFTWARE GO IN THIS DIRECTORY. + +This directory is provided as a courtesy to our users who might be +unable or unwilling to find and install libraries we depend on. + +If we "fix" software in this directory, we hamstring users who do the +right thing and keep a single version of upstream libraries in a +system-wide library. We introduce subtle and maddening bugs where +our code is "accidentally" using the "wrong" library version. We may +unwittingly interfere with other software that depends on the +canonical release versions of those same libraries! + +Forking upstream software for trivial reasons makes us bad citizens in +the Open Source community and adds unnecessary heartache for our +users. Don't make us "that" project. + + +FAQ +=== + +:Q: What should we do when we find a bug in upstream software? + +:A: First and foremost, REPORT THE BUG, and if possible send in a patch. + + Watch for a release of the upstream software and integrate with it + when it's released. + + In the meantime, work around the bug, if at all possible. Usually, + it's quite possible, if slightly harder or less efficient. + +:Q: What if the bug can't be worked around? + +:A: If the upstream developers have accepted a bug patch, it's + undesirable but acceptable to apply that patch to the library in + the ``extlib/`` dir. Ideally, use a release version for upstream or a + version control system snapshot. + + Note that this is a last resort. + +:Q: What if upstream is unresponsive or won't accept a patch? + +:A: Try again. + +:Q: I tried again, and upstream is still unresponsive and nobody's + checked on my patch. Now what? + +:A: If the upstream project is moribund and there's a way to adopt it, + propose having the StatusNet dev team adopt the project. Or, adopt + it yourself. + +:Q: What if there's no upstream authority and it can't be adopted? + +:A: Then we fork it. Make a new name and a new version. Include it in + ``lib/`` instead of ``extlib/``, and use the GMG_* prefix to change + the namespace to avoid collisions (or something like that). + + This is a last resort; consult with the rest of the dev group + before taking this radical step. + + +Thanks +====== + +This policy originally copied from Status.net. Many many thanks to them +for working out such a nice system for doing things. -- cgit v1.2.3 From 8a20ee349ffdc76b6de7cde8a43c4714fcc034af Mon Sep 17 00:00:00 2001 From: Christopher Allan Webber Date: Sun, 31 Jul 2011 15:51:55 -0500 Subject: Renaming "StatusNet" -> MediaGoblin in the extlib policy --- extlib/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'extlib/README') diff --git a/extlib/README b/extlib/README index c23da6e6..c690beac 100644 --- a/extlib/README +++ b/extlib/README @@ -51,7 +51,7 @@ FAQ checked on my patch. Now what? :A: If the upstream project is moribund and there's a way to adopt it, - propose having the StatusNet dev team adopt the project. Or, adopt + propose having the MediaGoblin dev team adopt the project. Or, adopt it yourself. :Q: What if there's no upstream authority and it can't be adopted? -- cgit v1.2.3 From 0d656f44a1252cc8cdc8ec05be33187db3470e5d Mon Sep 17 00:00:00 2001 From: Christopher Allan Webber Date: Wed, 10 Apr 2013 16:08:08 -0500 Subject: Open Source -> Free Software from the borrowed extlib repositories We're a GNU project, gotta get with the GNU world order ;) --- extlib/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'extlib/README') diff --git a/extlib/README b/extlib/README index c690beac..a2cc6ec0 100644 --- a/extlib/README +++ b/extlib/README @@ -17,7 +17,7 @@ unwittingly interfere with other software that depends on the canonical release versions of those same libraries! Forking upstream software for trivial reasons makes us bad citizens in -the Open Source community and adds unnecessary heartache for our +the Free Software community and adds unnecessary heartache for our users. Don't make us "that" project. -- cgit v1.2.3 From 3cadb4a6cd1d5cfdef8712d00e4594345a15b4a7 Mon Sep 17 00:00:00 2001 From: Alon Levy Date: Wed, 10 Apr 2013 01:30:01 +0300 Subject: document submodule usage Signed-off-by: Alon Levy --- extlib/README | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'extlib/README') diff --git a/extlib/README b/extlib/README index a2cc6ec0..45ee5b46 100644 --- a/extlib/README +++ b/extlib/README @@ -63,6 +63,19 @@ FAQ This is a last resort; consult with the rest of the dev group before taking this radical step. +:Q: What about submodules? + +:A: pdf.js is supplied as a submodule, and other software may use that too, + to add a new submodule: + git submodule add extlib/fun-project + + Use it just like a snapshotted extlib directory. When a new clone of mediagoblin + is made you need to run + + git submodule init + git submodule update + + As noted in HackingHowto Thanks ====== -- cgit v1.2.3