[Foundation-discuss] Fwd: Open AFS development model proposal

Daria Phoebe dariaphoebe@gmail.com
Sat, 23 Apr 2016 00:02:15 -0400


--001a114016c24b536505311f02aa
Content-Type: text/plain; charset=UTF-8

I don't think this was ever published, incidentally, but this is what we
started from.

---------- Forwarded message ----------
From: *$deadname* Brashear <shadow@andrew.cmu.edu>
Date: Mon, Oct 2, 2000 at 4:14 PM
Subject: Open AFS development model proposal
To: Laura Stentz/Pittsburgh/IBM <stentz@us.ibm.com>
Cc: ted@mit.edu, honey@citi.umich.edu, shadow@andrew.cmu.edu, Craig
Everhart/Pittsburgh/IBM <craigev@us.ibm.com>


Basically this is just an idea, presented so some though can be given the
matter. It's not particularly detailed and is not intended to be.

Basically, the model I'm proposing is 3 interlocking groups. The groups
can have overlapping members but it's not a requirement.

The three groups would be:

Advisory board
Code gatekeeper(s)
Developers

These groups would be constitituted thusly:
-board has been bootstrapped, and would provide additional and replacement
members through means internal to the board but not yet defined
-one or more, probably not more than 3, and preferably not more than 2,
code gatekeepers, would be selected by the board.
-any number of developers could exist, and would essentially register
interest/existance with the gatekeeper(s) if they so desired

Responsibilities:
-board is responsible for making decisions directing development path of
the code
-gatekeeper is responsible for incorporating bug fixes, making sure the
code continues to work in the face of necessary changes, and potentially
interfacing between developers and the board. gatekeeper unit has autonomy
for making bug fixes, usability changes, and other non-major updates to
the code.
-developers may simply be code contributors, or may be people who are
interested in hacking in general and "register interest" and can then pick
among requested features to be incorporated into a mainline openafs
distribution

Interfaces:
-board provides direction to gatekeeper on new feature inclusion for major
changes
-gatekeeper summarizes major development efforts received or known to the
board for consideration of inclusion
-developers feed changes to the gatekeeper
-gatekeeper offers desired features to interested developers for
implementation
-public bug submissions are coordinated through the gatekeeper
-public feature requests are coordinated through the board

Definitions:
-for purposes of this proposal, "inclusion" in the openafs mainline can be
read as "enabled and tested in the mainline release" and not necessarily
as "the code will be included in the release" as code can be included but
not enabled or considered "supported"

Basically this is just a model I constructed as potentially workable; I'm
just sharing so we might discuss a direction.

-D





-- 
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--001a114016c24b536505311f02aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t think this was ever published, incidentally, b=
ut this is what we started from.<br><br><div><div class=3D"gmail_quote">---=
------- Forwarded message ----------<br>From: <b>$deadname</b><b class=3D"g=
mail_sendername"> Brashear</b> <span dir=3D"ltr">&lt;<a href=3D"mailto:shad=
ow@andrew.cmu.edu">shadow@andrew.cmu.edu</a>&gt;</span><br>Date: Mon, Oct 2=
, 2000 at 4:14 PM<br>Subject: Open AFS development model proposal<br>To: La=
ura Stentz/Pittsburgh/IBM &lt;<a href=3D"mailto:stentz@us.ibm.com">stentz@u=
s.ibm.com</a>&gt;<br>Cc: <a href=3D"mailto:ted@mit.edu">ted@mit.edu</a>, <a=
 href=3D"mailto:honey@citi.umich.edu">honey@citi.umich.edu</a>, <a href=3D"=
mailto:shadow@andrew.cmu.edu">shadow@andrew.cmu.edu</a>, Craig Everhart/Pit=
tsburgh/IBM &lt;<a href=3D"mailto:craigev@us.ibm.com">craigev@us.ibm.com</a=
>&gt;<br><br><br>Basically this is just an idea, presented so some though c=
an be given the<br>
matter. It&#39;s not particularly detailed and is not intended to be.<br>
<br>
Basically, the model I&#39;m proposing is 3 interlocking groups. The groups=
<br>
can have overlapping members but it&#39;s not a requirement.<br>
<br>
The three groups would be:<br>
<br>
Advisory board<br>
Code gatekeeper(s)<br>
Developers<br>
<br>
These groups would be constitituted thusly:<br>
-board has been bootstrapped, and would provide additional and replacement<=
br>
members through means internal to the board but not yet defined<br>
-one or more, probably not more than 3, and preferably not more than 2,<br>
code gatekeepers, would be selected by the board.<br>
-any number of developers could exist, and would essentially register<br>
interest/existance with the gatekeeper(s) if they so desired<br>
<br>
Responsibilities:<br>
-board is responsible for making decisions directing development path of<br=
>
the code<br>
-gatekeeper is responsible for incorporating bug fixes, making sure the<br>
code continues to work in the face of necessary changes, and potentially<br=
>
interfacing between developers and the board. gatekeeper unit has autonomy<=
br>
for making bug fixes, usability changes, and other non-major updates to<br>
the code.<br>
-developers may simply be code contributors, or may be people who are<br>
interested in hacking in general and &quot;register interest&quot; and can =
then pick<br>
among requested features to be incorporated into a mainline openafs<br>
distribution<br>
<br>
Interfaces:<br>
-board provides direction to gatekeeper on new feature inclusion for major<=
br>
changes<br>
-gatekeeper summarizes major development efforts received or known to the<b=
r>
board for consideration of inclusion<br>
-developers feed changes to the gatekeeper<br>
-gatekeeper offers desired features to interested developers for<br>
implementation<br>
-public bug submissions are coordinated through the gatekeeper<br>
-public feature requests are coordinated through the board<br>
<br>
Definitions:<br>
-for purposes of this proposal, &quot;inclusion&quot; in the openafs mainli=
ne can be<br>
read as &quot;enabled and tested in the mainline release&quot; and not nece=
ssarily<br>
as &quot;the code will be included in the release&quot; as code can be incl=
uded but<br>
not enabled or considered &quot;supported&quot;<br>
<br>
Basically this is just a model I constructed as potentially workable; I&#39=
;m<br>
just sharing so we might discuss a direction.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-D<br>
<br>
<br>
</font></span></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_si=
gnature"><div dir=3D"ltr"><span><div><div dir=3D"ltr">Daria Phoebe Brashear=
<br></div><div>AuriStor, Inc<br></div><div><a href=3D"http://dariaphoebe.co=
m" target=3D"_blank">dariaphoebe.com</a><br><br></div></div></span></div></=
div>
</div></div>

--001a114016c24b536505311f02aa--