Ticket #10248: 10248-developers-guide.patch

doc/en/developer/inclusion.rst

@@ -7 +7 @@
 - **License**. The license must be a GPL version 2+ compatible
   license.
 
-- **Build Support**. The code must build on the following supported
-  architectures and compilers (and intended port targets):
 
-  - Linux: x86, x86_64, Itanium, ppc, ppc64, Sparc (gcc 3.4--4.3)
+- **Build Support**. The code **must** build on all the `fully supported platforms <http://wiki.sagemath.org/SupportedPlatforms#Fullysupported-SageisALWAYScheckedonALLtheseplatformsBEFOREareleaseismade/>`_. 
 
-  - Apple Mac OS X: ppc, ppc64, x86, x86_64 (Xcode 2.5+)
+  A standard package should also work on all the platforms where Sage is 
+  `expected to work <http://wiki.sagemath.org/SupportedPlatforms#Expectedtowork-Sagewillprobablywork.2Cbutitisnotalwaystested.>`_, but since we don't fully 
+  support these platforms and often lack the resources to test on them, you 
+  are not expected to confirm your packages works on those platforms. 
+  However, if you can, it is better to do so. As noted 
+  `here <http://wiki.sagemath.org/SupportedPlatforms#Expectedtowork-Sagewillprobablywork.2Cbutitisnotalwaystested.>`_, a failure of Sage to work on a 
+  platform where it is expected to work, will be considered a bug. 
 
-  - Microsoft Windows: x86, x86_64 MSVC 2005/Intel Fortran (MinGW or
-    Cygwin support is insufficient!)
-
-  - Solaris 10: Sparc, x86, x86_64 (Sun Forte 12)
+  There is no need to worry too much about platforms where Sage will 
+  `probably not work <http://wiki.sagemath.org/SupportedPlatforms#Probablywillnotwork-Portingworkmaybeongoing>`_ though if it's clear that there is 
+  significant effort taking place to port Sage to a platform, then you should 
+  aim to ensure your package does not cause unnecessary headaches to those 
+  working on the port. 
+  
+  If it's clear that a port is stagnent, with nobody working on 
+  it, then you can safely ignore it. 
 
   Remarks:
 
@@ -26 +34 @@
     expected to do the heavy lifting and also support those ports
     upstream if there is no Sage developer who is willing to share the
     burden.
+  - One of the best ways to ensure your code works on multiple platforms
+    is to only use commands which are defined by `POSIX.1-2008 <http://www.opengroup.org/onlinepubs/9699919799/>`_ and only use options which are defined 
+    in the POSIX standard. For example, do not use the -p option to `uname <http://www.opengroup.org/onlinepubs/9699919799/utilities/uname.html>`_ as 
+    the '-p' option is not defined by the POSIX standard, so is not portable. 
+    If you must use a non-POSIX command, or a option which is not defined
+    by POSIX, then ensure the code only gets executed on the platform(s)
+    where that command and/or option will be acceptable. 
 
-  Potential future ports include FreeBSD (x86, x86_64), OpenBSD (x86,
-  x86_64), HPUX (Itanium), AIX (PPC64), and ARM (OS X).
 
 - **Quality**. The code should be "better" than any other available
   code (that passes the two above criteria), and the authors need to
@@ -45 +58 @@
 
   - Maintainable
 
+  - Portability
+
   - Reasonable build time, size, dependencies
 
+
+- **Previously an optional package**. Usually a new standard package must have spent some time as an optional package. However, sometimes this is not possible, if for example a new library is needed to permit an updated version of a standard package to function. 
+
 -  **Refereeing**. The code must be refereed, as discussed in
    :ref:`chapter-trac`.