doc/procedures.txt

   1                     MIT Kerberos Development Team
   2                               Procedures
   3
   4 This is a draft of current procedures used by the MIT Kerberos
   5 Development Team.  They will be refined at some later point.
   6
   7 ---Tom
   8
   9 RELEASE BRANCH HYGIENE
  10 ======================
  11
  12 No changes should be committed to a release branch except by the
  13 release engineer or other approved person.  Changes to be included on
  14 the release branch must first be committed to the trunk, and must have
  15 an associated RT ticket.  This ticket should have its "target_version"
  16 keyword set to the release that the change is targeted at, and should
  17 have the "pullup" tag set.  This ticket should clearly document the
  18 changes that are to be pulled up to the release branch; the
  19 recommended way to do this is to ensure the the subversion  commit operations
  20 corresponding to the changes have automatically updated the ticket --
  21 see the following section.  The release engineer will pull up the
  22 change to the release branch and set the "version_fixed" keyword on
  23 the ticket.
  24
  25 USING Subversion COMMITS TO CREATE/UPDATE RT TICKETS
  26 =============================================
  27
  28 The following instructions were written for cvs but also work for Subversion.
  29
  30 To: krbdev@mit.edu
  31 Subject: Important: handling commit interactions with bug database
  32 Message-Id: <20020917204852.4AEFE151FEF@industrial-algebra.mit.edu>
  33 Date: Tue, 17 Sep 2002 16:48:52 -0400 (EDT)
  34 From: hartmans@MIT.EDU (Sam Hartman)
  35
  36 Hi.  I've just deployed the integration between the RT bug tracking
  37 system and our CVS repository.
  38
  39 Per previous discussion, we're moving to a model where any non-trivial
  40 functionality change needs to be accompanied by a ticket open in the
  41 bug database.  This will allow us to generate better release notes.
  42 To accomplish this we have created a syntax for manipulating tickets
  43 along with commits.  If you are someone who has commit access but is
  44 not at MIT your commits MUST create or update a ticket.
  45
  46 To manipulate tickets you add some header lines to the top of your log
  47 message.  The lines can be of the form header: value or rt-header:
  48 value.  I'll show them without the rt-prefix.
  49
  50 Updating a ticket
  51 =================
  52
  53 To update a ticket, you include a
  54  ticket: or rt-ticket: line  in your log.  For example:
  55
  56 ticket: 1164
  57
  58 Return errno not retval when getpeername fails.
  59
  60 By default when you update a ticket:
  61
  62 * the ticket is assigned to you
  63 * The ticket is closed
  64
  65 If these defaults are not appropriate for your action you can override
  66 them; see below.
  67
  68 Creating a ticket
  69 =================
  70
  71 You can also create a ticket at the same time as you commit. All you
  72 have to do is use new instead of a ticket number in a ticket line.
  73 However you almost certainly want to at least set the  subject.
  74
  75 ticket: new
  76 subject: Add AES support
  77
  78 Add an implementation of AES to libk5crypto.
  79
  80 In addition to closing the ticket and marking you as the owner of a
  81 ticket, creating a new ticket makes you the requester of the ticket.
  82
  83 OTher Things to Change
  84 ======================
  85
  86
  87 The following additional commands are supported:
  88
  89 * subject: changes the subject of ticket
  90 * status: [open|resolved|new|stalled]
  91 * owner: [username|nobody]
  92 * cc: [email address]
  93 * Component: change component of ticket [krb5-libs etc]
  94 * Version_Reported:
  95 * Target_Version:
  96 * Tags: [enhancement|nochange|noresource|pullup]
  97
  98 You could set version_fixed, but it is wrong to do so.
  99
 100
 101 Also, note that you can update multiple tickets in one log message;
 102 updates apply to the most recent ticket: command.
 103
 104 MEANINGS OF RT TAGS AND VERSIONS
 105 ================================
 106
 107 To: krbdev@mit.edu
 108 Subject: Meaning of RT tags and versions
 109 Message-Id: <20020821205804.5764E151FEF@industrial-algebra.mit.edu>
 110 Date: Wed, 21 Aug 2002 16:58:04 -0400 (EDT)
 111 From: hartmans@MIT.EDU (Sam Hartman)
 112
 113 We're in the middle of migrating away from Gnats for bug tracking and
 114 to RT.  I sent out some mail describing the bug tracking process we
 115 were going to use at the beginning of the summer and wanted to follow
 116 up on that with definitions of fields in the  tickets.
 117
 118 Tickets have three version numbers associated with them:
 119 version_reported, version_fixed, and target_version.  The
 120 version_reported should be filled in by the submitter if they are
 121 using the web interface or by the first person  to edit the bug with
 122 the web interface; it is the version of Kerberos the bug first
 123 appeared in.
 124
 125 The version_fixed field is set during the release process; you should
 126 never change this field  unless you are a release engineer and even
 127 then you'll probably be using automated scripts.
 128
 129 The target_version field is the version of the software we plan to fix
 130 a bug in.  It is generally updated after release planning meetings,
 131 although it is reasonable for people with commit access to update this
 132 if they believe a particular issues should be considered for the
 133 specified target version.  If we notice a lot of issues we don't have
 134 time to deal with, we will drop the target versions as the release
 135 approaches.
 136
 137 There are several tags that can be set on a ticket as well.
 138
 139 The first tag is the enhancement tag; this roughly corresponds to the
 140 Gnats classification as change-request, distinguished from sw-bug.
 141
 142
 143 The next tag is the nochange tag.  This indicates that the ticket has
 144 been (or will be) closed with no code change and thus should not be
 145 processed by the next round of release scripts.  This is appropriate
 146 for tickets where the requester is mistaken or where no bug/change
 147 exists.
 148
 149 The final tag is the noresource tag; this indicates that MIT does not
 150 have resources to dedicate to the problem/feature.  We'll set this tag
 151 on tickets when we evaluate them in release planning discussions so
 152 that we do not have to continue thinking about then at each
 153 consecutive release.  In general, if we feel an issue is not a
 154 problem, we'll just close the ticket.  However if we agree that in an
 155 ideal world the issue would be fixed but don't ever expect to be able
 156 to fix it ourselves, we'll set the noresource tag and forget the issue
 157 unless someone replies to it with a patch or proposed solution.
 158
 159 --Sam