[OpenAFS-devel] Moving Forwards

[Derrick Brashear]

=46rom a standpoint other than implementation of this I agree; my sole real i=
ssue is how RT accounts get managed, because right now it's effectively 'by h=
and', 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> wrot=
e:

> Hi all,
>=20
> Following on from last weeks plethora of resignations and negativity, I wa=
nt to propose some ways that we can move forwards, and hopefully reduce the i=
nertia 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 p=
otential 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 in=
put into what follows!
>=20
> We should dramatically increase the number of people who can provide +2 re=
views in gerrit. My proposal here is that this would be open to anyone who h=
as demonstrated an interest in OpenAFS and an understanding of some of the c=
ode. Say anyone who has contributed more than 2 patches. The understanding w=
ould 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 knowle=
dge of.
>=20
> We should increase the number of people who can submit code. I'd propose g=
ranting submit access to anyone who has a deep understanding of a particular=
 area of the code, with the understanding being that they only submit change=
s to areas that they understand, and are as "responsible" for any breakage c=
aused by that change as the original author. For example, Andrew for the fil=
eserver, Marc for the Linux cache manager and so on. Whilst this hugely open=
s up the flow of changes into the tree, I don't think it will be particularl=
y destabilising - I'd expect folk to use their submit powers responsibly, an=
d we can always revert changes that shouldn't have made it through.
>=20
> 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 o=
f 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.
>=20
> We should open up RT to all comers. For most projects, commenting on issue=
s in the bug tracking system is the first way that newcomers get started. Bu=
t in OpenAFS, commenting on bugs is restricted to a select few. I believe th=
at we should turn this on its head, and give access to everything (bar delet=
e) to anyone who wants to be able to comment. We're an open source project, n=
ot a commercial endeavour, and people who are reporting bugs should understa=
nd that some of the responses may be more useful than others. Again, I would=
 expect this to be self policing.
>=20
> Thoughts, comments?
>=20
> Cheers,
>=20
> Simon.
>=20
>=20
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20