[OpenAFS-devel] Moving Forwards

[Jeffrey Altman]

On 9/9/2012 9:15 AM, Simon Wilkinson wrote:
> Hi all,
> 
> Following on from last weeks plethora of resignations and negativity, I want to propose some ways that we can move forwards, and hopefully reduce the inertia that has built up in our development process. One of my key aims here is to reduce the workload on the remaining Gatekeepers, and to remove any potential for them becoming road blocks in the process. I should add that I'm proposing all of this in an individual capacity - my employer has had no input into what follows!

While I appreciate your desire to remove the gatekeepers from being
roadblocks, in some respect that is exactly what the gatekeepers are
supposed to be.  The gatekeepers have a responsibility to ensure that
the distribution that is "OpenAFS" maintains interoperability with IBM
AFS and does not introduce code changes that destabilize existing
deployments or result in data loss.

While I understand that there are a significant number of developers
that believe the OpenAFS Elders are an anachronism and have no role to
play.  The fact is that the OpenAFS Elders are the recognized board of
directors of the unincorporated association that is OpenAFS.  If there
is ever a fight over the "OpenAFS" mark, IBM will back the position that
the OpenAFS Elders are the only entity that has the right to distribute
software under that mark.

IBM holds the view that the "AFS" mark and derivatives may only be used
to describe products that are compatible with IBM AFS.  What the
specific requirements of compatibility have never been put down in
writing by IBM.  However, the Elders are the body that has worked with
IBM via IBM's representatives on the Elders to determine when a proposed
change is permissible.

> We should dramatically increase the number of people who can provide +2 reviews in gerrit. My proposal here is that this would be open to anyone who has demonstrated an interest in OpenAFS and an understanding of some of the code. Say anyone who has contributed more than 2 patches. The understanding would be that people only provide +2 reviews for code that they are confident is correct, in a section of the codebase that they have a reasonable knowledge of.

I have no specific objection to permitting all recognized experts (as
determined by the Gatekeepers) to be given "+2 Approved" status on
Gerrit submissions to the master branch.

However, what I believe we need much more than additional levels of +1
and +2 for code review is a +1 and +2 for verified.  At the moment we
have verified to build but it would be very useful for us to have a +2
verified that also means that it was tested.

If the implication of Code Review +2 is that any verified vote also
means "tested" and confirmed not to break, then I am definitely in favor
of making the Code Review +2 available to trusted developers.

> We should increase the number of people who can submit code. I'd propose granting submit access to anyone who has a deep understanding of a particular area of the code, with the understanding being that they only submit changes to areas that they understand, and are as "responsible" for any breakage caused by that change as the original author. For example, Andrew for the fileserver, Marc for the Linux cache manager and so on. Whilst this hugely opens up the flow of changes into the tree, I don't think it will be particularly destabilising - I'd expect folk to use their submit powers responsibly, and we can always revert changes that shouldn't have made it through.

There are not significant delays when it comes to the submission of code
that has been reviewed by a significant portion of the developer
community.  Instead, the big problem we sometimes have is that even
under the current model patchsets are submitted too soon.

That being said.  I believe the Gatekeepers can extend "Submit"
privileges to additional individuals that accept additional
responsibility in the community.  For example, documentation and web
site changes do not need review by the Gatekeepers and individuals
responsible for pushing forward those efforts certainly can be given
"Submit" privileges.

Release Managers for specific branches should have the ability to
Approve and Submit pullups for those releases.

The best way to reduce the work load on the Gatekeepers is for more
developers to take an active role in reviewing code submissions.  After
the last round of discussion on the subject of code reviewers there has
been a slight increase in the number of reviewers.  However, the
increase has not been substantial.

> We should appoint release managers (other than the gatekeepers) for the 1.4 and 1.6 stable branches. 1.4 has stagnated for years, and there are a lot of changes backed up that some people will probably be interested in. I think there's a danger of 1.6 stagnating in the same way, especially if we're all off writing new code. Having one, or more, people take on a release manager role should hopefully help unblock the flow of releases.

OpenAFS used to have release managers for the non-current stable branch.
 We certainly should have a release manager for 1.4 but I agree that
even 1.6 could have a release manager.  The role of the release manager
would be to propose patchsets for pullups that fix bugs, do not
introduce significant change in behavior, etc. and assist in the
packaging and documentation of the release.

> We should open up RT to all comers. For most projects, commenting on issues in the bug tracking system is the first way that newcomers get started. But in OpenAFS, commenting on bugs is restricted to a select few. I believe that we should turn this on its head, and give access to everything (bar delete) to anyone who wants to be able to comment. We're an open source project, not a commercial endeavour, and people who are reporting bugs should understand that some of the responses may be more useful than others. Again, I would expect this to be self policing.

The reason RT is not open has little to do with a lack of desire.  As a
gatekeeper, I don't have the ability to approve accounts and alter
permissions.  Those that do have those permissions are trusted by the
central.org system administrators.

RT is not open to all primarily due to limitations of the software and
the time availability of the central.org system administrators who
manage it, the mailing lists and DNS for OpenAFS.  Another factor that
Jeffrey Hutzelman has raised in the past is that the OpenAFS community
has not asked for specific changes and I believe that is true.

Creating our own RT instance on openafs.stanford.edu or migrating to a
different request tracker package is certainly a possibility if the
resources necessary to make the changes become available.  The
Gatekeepers do not want to be system administrators and OpenAFS does not
have the option of hiring one.

Jeffrey Altman