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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
