[OpenAFS-devel] Moving Forwards

[Troy Benjegerdes]

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
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel