mirror of the now-defunct rocklinux.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

56 lines
1.9 KiB

  1. Policy for Stable Tree Maintainance
  2. ===================================
  3. The Stable Tree Project has three defined goals:
  4. 1. Fixing bugs and security issues
  5. 2. Updating packages to newer versions
  6. 3. Creation of reference build binaries
  7. The set of changes in the stable tree should be kept to an absolute minimum.
  8. There is one single maintainer for the ROCK Linux Stable tree. Nobody else
  9. may write to the source tree, but everybody is free to send patches to the
  10. maintainer.
  11. 1. Fixing bugs and security issues
  12. ----------------------------------
  13. Whenever there is a security problem reported, the required updates or
  14. bug-fixes should be performed in the stable tree and an advisory should be
  15. send to the mailing list.
  16. Bugfixes should be applied unless fixing the bug would introduce more new
  17. troubles than it solves (e.g. requires redesignes of core build scripts). In
  18. this case, it should be considered to drop the feature or marking it as
  19. broken instead of fixing it.
  20. 2. Updating packages to newer versions
  21. --------------------------------------
  22. Package updates should be performed unless the newer version of a package
  23. introduces new problems or breaks compatibility with the old package and so
  24. would require rebuilding a large part of the system.
  25. 3. Creation of reference build binaries
  26. ---------------------------------------
  27. The stable tree maintainer is responsible for creating and distributing
  28. ISOs of an un-optimized x86 reference build and also creates and distributes
  29. update gem packages for updated packages. That includes maintaining an
  30. ftp or http archive with the ISO images and the GEM package files.
  31. A. Release and Sourcecode Management
  32. ------------------------------------
  33. The source-code must be available via an open-source versioning-system like
  34. cvs or subversion and via ftp or http.
  35. Major releases should be done after important security of bug-fixes.