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