[OpenAFS-devel] RT, Gerrit, Release Management changes

[Derrick Brashear]

With the changes in whom is currently volunteering for both the elders
and the gatekeepers and in recognition of the workload people, both
those groups and others, are realistically doing these days, I'd like to
outline some changes which will be coming along as soon as we can
actually make them.

OpenAFS RT (https://rt.central.org/rt)

Our incident tracking system is shared with other organizations and
has had a long history of being nigh-impossible for people who are
neither central.org site maintainers nor OpenAFS gatekeepers to deal
with. Even primary platform builders have had limited access. Primarily
this was not due to policy so much as the fact that sufficient
customization had not been done to RT to allow delegation of the
relevant powers, let alone what would be needed to prevent it from
falling prey to the same issues which beset our wiki with spam for quite
some years. The first steps have been taken to provide additional
privileges to known users and more will be coming.

As Simon Wilkinson proposed:

  guest:
         At present, can view tickets in the openafs-bugs queue,
         but can't update them

  commenter:
         Can do anything to a bug, but can't delete it, or merge it with
         another bug, (these are potentially irreversible steps in RT)

  developer:
         Can do anything to a bug

The powers granted to current developer-users have been expanded and
should cover this. Mechanisms to grant additional users(*) developer or
commenter status will be coming, as will a mechanism to verify people
creating RT accounts are "real users".

* Anyone who has contributed five accepted patches in the previous year
  will be added to the "developer" group, not to be revoked except by
  the Gatekeepers in case of problems.  Any contributor may be a
  commenter.


OpenAFS Gerrit (http://gerrit.openafs.org)

Currently, de facto action is that substantial changes will not be
merged without multiple reviewers, but +1s are not cumulative and so
only a gatekeeper +2 will allow a patchset to be merged.

Once "Approval" guidelines have been written, individuals who have
contributed five accepted patches in the previous year will be granted
the ability to +2/-2 patchsets.  A +2 vote will be an indication that a
substantial review has been completed by someone with appropriate
expertise to evaluate the patchset.

The granting of +2/-2 permissions will be performed on a semi-regular
basis by the Gatekeepers until such time as an automated mechanism for
approval is designed and implemented.


Release Management

The Gatekeepers are seeking qualified volunteers to take on the
responsibility of release management for the 1.4 and 1.6 branches.
Release managers will be responsible to coordinating release schedules
for these branches with the Gatekeepers, performing pullups, generating
release notes, and certifying when pre-release and final releases are
ready for tagging and distribution.


The Gatekeepers believe that these steps will increase the participation
by the community and speed up the rate of stable releases.

-- 
Derrick
for the gatekeepers