Let me propose something else: Anyone can commit, but changesets must build and pass a full regression test suite before being committed. A couple of +2 reviews in gerrit could override the regression tests if something is broken in the tests.
Since we have no regression tests, everything can go in. And when a new changes completely breaks something, people providing support contracts will be motivated to write and submit better tests, instead of blocking or ignoreing new code, which is what the current system encourages. I'd also propose that this test-driven approach be applied, as much as possible, to major disruptive protocol changes, such as say, wholesale repalcement of all data structures that refer to an IPv4 address. If you can produce a working testcase that will fail with a new rx protocol change, then you have a valid argument. Otherwise we can move ahead with some dramatic data structure changes to simplify getting working ipv6 and rxgk code available for those who don't have an immediate need to interoperate with any 'old' code. On Sun, Sep 09, 2012 at 02:15:11PM +0100, 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! > > 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. > > 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. > > 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. > > 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. > > Thoughts, comments? > > Cheers, > > Simon. > > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
