From a standpoint other than implementation of this I agree; my sole real issue 
is how RT accounts get managed, because right now it's effectively 'by hand', 
which is poor.

But for the rest, and actually for that as well, I think this is a good plan.

Derrick

On Sep 9, 2012, at 9:15 AM, Simon Wilkinson <[email protected]> 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

Reply via email to