Differences between revisions 17 and 18
Revision 17 as of 2006-04-14 10:08:59
Size: 6763
Editor: ?SteffenJoeris
Comment: add small exception
Revision 18 as of 2006-04-14 10:12:14
Size: 6679
Editor: ?SteffenJoeris
Comment: fix some stuff
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
 * The sarge* suites can be touched if a security fix or a critical bug fix is made. For official DESA (DebianEduSecurityAnnouncement) updates only the security team is allowed to upload them. Packages with critical bugfixes can be uploaded by every Uploader.
One acception are backports which are really needed in the sarge suite and might be very useful for our users
 * The sarge* suites can be touched if a security fix or a critical bug fix is made. For official DESA (DebianEduSecurityAnnouncement) updates only the security team is allowed to upload them. Packages with critical bugfixes can be uploaded by every Uploader. One acception are backports which are really needed in the sarge suite and might be very useful for our users
Line 34: Line 33:
For the woody* and the sarge* suites it is not allowed to add real new packages.

Debian-Edu/Skolelinux Archive Policy

  1. Every Uploader has to accept the DFSG and the Debian Social Contract in order to have the same base for our work.
  2. DISCLAIMER: Although the ftpmasters are trying to do a great job *we* are making mistakes. Please notice that the developers and *not* the ftpmasters are responsible for the packages, although the ftpmasters feel a little bit responsible for every package in the archive. So for instance if a fix by a developer was not correct, but the package is moved into the stable pool it is not the fault of the ftpmasters.
  3. The work on the three main packages (debian-edu, debian-edu-install and debian-edu-config) is done in Subversion, so only versions which can be found there are allowed to be uploaded in order to guarantee the team maintenance on these packages.
  4. Normally we accept only packages which are also part of Debian. If for some reasons the package is not yet in Debian please write some notes into the changelog. If the package won't go into Debian for some reasons it is necessary to write a mail with a description and the reasons to ML (ftpmasters@skolelinux.org or debian-edu@lists.debian.org) to get your package accepted, but the general intention should be to get the package into debian one day.

  5. Please keep the number of backports to a minimum. If the backport is really needed for our system to run (e.g. new initrd-tools) it will be accepted. If the backport is optional (e.g. a new kde application) you get a better chance for acceptance if you write some comments into the changelog. (This is recommended but not needed). If the package will be rejected you have to discuss it with the ftp-team, their intention is to have a minimum of backports. Change their opinion about your backport and the package will be accepted. Please make sure that your backport is mostly bug free and already in Debian testing. Only by security fixes you should backport a package from unstable.
  6. If you intend to become a Debian-?EduDeveloper with upload rights yourself please write a mail to drift@skolelinux.org . In this case it makes no sense to write a mail to the ftp-team, although they can/will add you later to the keyring the permission to decide it only has drift. We don't recommend further skills in any area and you do not need to be an official Debian Developer to get upload rights. Please decide on your own if you should get upload rights and write the mail with your intentions and maybe some explanations. (Keep in mind with great power comes great responsibility). If you are not sure and you want to contribute and commit to Subversion and upload packages but you need some introduction/training in packaging you can ask for some help with writing it into the explanation to drift@skolelinux.org. Then drift will assign a Developer to you which helps you a bit in getting knowledge about Subversion, the Debian-Edu Development, packaging and uploading to the archive. (Maybe this is one of the ftp-team). This Developer tries to help you as fast as he/she can, please don't be angry if it takes some time he/she might be right busy but tries his/her very best to help you.

  7. If you upload a package you want to have it on the CD Image. We try to get our whole distribution on one CD and use the official Debian mirrors for any other package. If your package is not good enough to make it on the CD please drop it until it is good enough.
  8. We have currently five suites, woody, sarge-test, sarge, etch-test and etch. Every suite generates a CD Image which should be tested. We seperate the suites into "normal" and "test". If you want to upload a package you have to upload it to the -test pool. After the package made it into the archive you can test the daily build image from the -test pool carefully. If your package/fix is working you should contact the ftp-team and request that the package will be moved into the "normal" pool. With this procedure we guarantee a kind of stable development. If you work on the main packages please try to coordinate your work with the others the best way is to ask/talk about an upload of them on IRC first. Then you have most of the others informed and all can wait with a new upload until the fix is tested and the package made it into the stable pool. For the package move just write a mail to ftpmaster@skolelinux.org and include the package name and new version number and the changelog and if you want some additional explanations.

  9. In order to see the bugzilla interaction it is recommended that you write down in your changelog if you close a Debian-Edu/Skolelinux Bug (e.g. * foo bar (Closes Skolelinux Bug #007) ) but keep in mind that you have to close the bug manually in bugzilla!
  10. In addition to these rules we try to follow the normal Rejection-FAQ written by the Debian ftpmasters to make sure we keep the archive legal and keep the packages in good quality. You find their rejection-FAQ at http://ftp-master.debian.org/REJECT-FAQ.html

  11. The Uploaders are not anonymous. A current list can be found at http://wiki.debian.org/DebianEdu/Uploaders

  12. This list is not complete and some new points might be added. So please make sure that you read it again from time to time.

Some explanations abouth the suites

  • The woody* suites will only touched if a security update is available. For that purpose only the security team is able to upload to these pools.
  • The sarge* suites can be touched if a security fix or a critical bug fix is made. For official DESA (?DebianEduSecurityAnnouncement) updates only the security team is allowed to upload them. Packages with critical bugfixes can be uploaded by every Uploader. One acception are backports which are really needed in the sarge suite and might be very useful for our users

  • The etch* suites are the unstable suites where the normal development takes place. Here it is also important that you test your new implementations/packages, so we follow the procedure described above.

As a special case, it is possible to upload identical packages into both debian/unstable and debian-edu/etch-test by using the 'unstable' suite. This should only be done with arch:all packages, to avoid dependency skew between the debian and debian-edu repositories for the binary packages.

Current ftp-team

The ftp-team is not anonymous. The current members are:

  • Morten Werner Olsen
  • Holger Levsen,
  • Martin Zobel-Helas and
  • Steffen Joeris

If you want to get in contact with them or if you just have some questions write a mail to:debian-edu@lists.debian.org or ftpmasters@skolelinux.org