Software Development and Integration Policies for OS-Net ========================================================= # # Copyright 2003 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # These are the GOLDEN RULES for software development and integration for all OS-Net releases. This message does not describe the integration processes or the integration criteria which may vary slightly from release to release. Simple rules ============= For developers, when integrating code into an i-team workspace or an integration workspace, it is your responsibility to follow these rules: 1. Make sure that all affected code compiles after the final bringover but before integration. 2. Test it after the final bringover but before integrating it. 3. If appropriate, make sure that your changes work on all supported reference architectures. 4. Make sure that the "make" and "make install" rules operate properly. Follow the Makefile Standards and Guidelines document. 5. Check that new libraries have been versioned properly (see Policy for Shared Library Version Names and Interface Definitions). All libraries should be installed by the appropriate Makefiles. All headers under usr/src/uts should also be installed by the 'make install_h' target. 6. Files which are cstyle clean should remain cstyle clean. New files must be cstyle clean. 7. Understand the performance impact of your change. No change should degrade performance. 8. Supply meaningful and helpful SCCS comments, including any relevant bugids. 9. Update the various bug databases to indicate that the bug is fixed. If you are a gatekeeper, update the bug databases to indicate which bug fixes your gate has integrated. 10. Tell the documentation people about any customer visible changes that may need to be documented in the relevant guides, the release manual or the man pages. Follow the instructions for updating ON man pages. 11. All source files must be under SCCS control. 12. All integration will occur via SparcWorks/TeamWare. 13. All source files must include appropriate SCCS keywords. 14. All SCCS comments should follow some basic rules of etiquette since we now share SCCS histories with our Hardware Partners; we do not want to risk offending our business partners. 15. All source files created or significantly modified by Sun must include appropriate SMI copyright notices such as the ones below. Never remove another company's copyright without the approval of management. When a source file is significantly updated, the year or range of years in the copyright should be replaced with just the current year at the time of modification. Significant updates do not include formatting changes. However, if you prefer not to think about whether your change constitutes a significant update or if you don't trust your judgement, erring on the side of always updating the year is acceptable. When a source file is modified after October 1994, be sure to add the 'All rights reserved' notice, as shown in the new format of the copyright notice below. REALLY OLD format: /* * Copyright (c) 1994 by Sun Microsystems, Inc. */ LESS OLD format: /* * Copyright (c) 1998 by Sun Microsystems, Inc. * All rights reserved. */ Starting in January 2002, a newer format has been mandated. The "(c)" has been removed, as has the "by", the reserved line has been moved up to be on the same as as the copyright (with two spaces in between the sentences), and the new "Use is subject to license terms." sentence has been added on a new line. NEW format: /* * Copyright 2002 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ Starting in September 2003, the policy of retaining previous years in the copyright notice has been changed. Now you have to replace all the previous years with just the current year. 16. If introducing new source files into the ON source, have you addressed the source product concerns that should have been posed by any of PSARC, OSSC, or the ON C-team? Any new sources that are proprietary or that cannot be shipped with the source product require special architecture into the ON build. 17. Once there exists a combined x86/sparc OS-Net source base, all changes should comply with the Combined Source Engineering Guide. 18. Any new or modified header files should be hdrchk clean. For details re hdrchk, see the "codemgr update #23 -- hdrchk utility" message in the Codemanager Announcements archive. 19. You have the following additional responsibilities when integrating changes to the kernel: o Your changes must not introduce any lint errors. See tips on keeping the kernel lint clean at /shared/ON/general_docs/lint_tips.txt. o For the kernel, changes must conform to the C coding style. o Your changes must not break boot, including diskless boot, or kadb. o You must update any "kmem readers" (e.g., crash, ps, vmstat) if you change any kernel data structures. 20. The 2.6 release of Solaris has the support for Large Files, files whose size can exceed the current limit of 2GB. If you are modifying/creating utilities or libraries that manipulate files, you must make them large file safe or aware. Please check out a white paper at /XXXXXX/XX/XXXXXXXXXXX/whitepaper.ps. Also see LargeFiles homepage on http://XXXXXXXX.XXX/XXXXXX/XX/XXXXXXXXXX. In summary, 1) To ensure that your application is compatible i.e.,"large file safe" for Solaris-2.6+, you must examine your application's source code to ensure that existing interfaces behave appropriately and have the correct error handling characteristics when it encounters a large file. 2) In order for your application to work with Large Files i.e., "large file aware", you must examine and modify your source code to either use 64-bit version of functions or use LARGEFILE compilation environment. 21. The entire build has been warning clean since early in 2.6. Please keep it this way. Any new warning needs to be cleaned up prior to integration.