[OpenAFS-devel] Moving Forwards

[Jason Edgecombe]

I like the plan as well.

I can help with RT stuff. I would like to mark most of the bugs as 
stalled or closed, because the 5 year old bugs should probably be closed.

Would having more account creators help? Should we let people 
self-register for RT?

Jason

On 09/09/2012 09:21 AM, Derrick Brashear wrote:
>  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 <simonxwilkinson@gmail.com> 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
>>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>