docs/README.new-incoming

   1 [An updated version of the proposal sent to debian-devel-announce@l.d.o.
   2  Debian-specific, but useful as a general overview of New Incoming.]
   3
   4                      New Incoming System
   5                      ===================
   6
   7 This document outlines the new system for handling Incoming
   8 directories on ftp-master and non-US.
   9
  10 The old system:
  11 ---------------
  12
  13   o incoming was a world writable directory
  14
  15   o incoming was available to everyone through http://incoming.debian.org/
  16
  17   o incoming was processed once a day by dinstall
  18
  19   o uploads in incoming had to have been there > 24 hours before they
  20     were REJECTed.  If they were processed before that and had
  21     problems they were SKIPped (with no notification to the maintainer
  22     and/or uploader).
  23
  24 The new system:
  25 ---------------
  26
  27   o There's 4 incoming directories:
  28
  29      @ "unchecked"  - where uploads from Queue Daemons and maintainers
  30                       initially go.
  31
  32      @ "accepted"   - where accepted packages stay until the daily
  33                       dinstall run.
  34
  35      @ "new"        - where NEW packages (and their dependents[1]) requiring
  36                       human processing go after being automatically
  37                       checked by dinstall.
  38
  39      @ "byhand"     - where BYHAND packages (and their dependents[1])
  40                       requiring human intervention go after being
  41                       automatically checked by dinstall.
  42
  43     In addition there's 3 support directories:
  44
  45      @ "reject"     - where rejected uploads go
  46
  47      @ "done"       - where the .changes files for packages that have been
  48                       installed go.
  49
  50      @ "holding"    - a temporary working area for dinstall to hold
  51                       packages while checking them.
  52
  53   o Packages in 'unchecked' are automatically checked every 15 minutes
  54     and are either: REJECT, ACCEPT, NEW or BYHAND.
  55
  56   o Only 'unchecked' is locally world-writeable.  The others are all,
  57     of course, locally world-readable but only 'accepted' and 'byhand'
  58     are publicly visible on http://incoming.debian.org/
  59
  60   o 'accepted' and 'byhand' are made available to the auto-builders so
  61      they can build out of them.
  62
  63   o 'accepted' is processed once a day as before.
  64
  65   o Maintainer/uploader & list notification and bug closures are
  66     changed to be done for ACCEPTs, not INSTALLs.
  67     [Rationale: this reduces the load both on our list server and our
  68      BTS server; it also gives people better notice of uploads to
  69      avoid duplication of work especially, for example, in the case of
  70      NMUs.]
  71     [NB: see [3] for clarifications of when mails are sent.]
  72
  73 Why:
  74 ----
  75
  76   o Security (no more replaceable file races)
  77   o Integrity (new http://i.d.o contains only signed (+installable) uploads[2])
  78   o Needed for crypto-in-main integration
  79   o Allows safe auto-building out of accepted
  80   o Allows previously-prohibitively-expensive checks to be added to dinstall
  81   o Much faster feedback on packages; no more 48 hour waits before
  82     finding out your package has been REJECTed.
  83
  84 What breaks:
  85 ------------
  86
  87   o people who upload packages but then want to retract or replace the
  88     upload.
  89
  90     * solution: mostly "Don't do that then"; i.e. test your uploads
  91       properly.  Uploads can still be replaced, simply by uploading a
  92       higher versioned replacement.  Total retraction is harder but
  93       usually only relevant for NEW packages.
  94
  95 ================================================================================
  96
  97 [1] For versions of dependents meaning: binaries compiled from the
  98     source of BYHAND or NEW uploads.  Due to dak's fascist
  99     source-must-exist checking, these binaries must be held back until
 100     the BYHAND/NEW uploads are processed.
 101
 102 [2] When this mail was initially written there was still at least one
 103     upload queue which will accept unsigned uploads from any
 104     source. [I've since discovered it's been deactivated, but not,
 105     AFAIK because it allowed unsigned uploads.]
 106
 107 [3]
 108              --> reject
 109             /
 110            /
 111 unchecked  -----------------------------[*]------> accepted ---------------> pool
 112            \               ^   ^
 113             |             /   /
 114             |-->   new  --   /
 115             |       |[4]    /
 116             |       V      /
 117             |--> byhand --/
 118
 119 [4] This is a corner case, included for completeness, ignore
 120     it. [Boring details: NEW trumps BYHAND, so it's possible for a
 121     upload with both BYHAND and NEW components to go from 'unchecked'
 122     -> 'new' -> 'byhand' -> 'accepted']
 123