[OpenAFS] Release Inclusion (was rxk5 Mainline Issues)
Evan Macbeth
emacbeth@sinenomine.net
Mon, 9 Nov 2009 10:15:21 -0500
--_000_C71D9C3911CFAemacbethsinenominenet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
What a great discussion!
To wit:
>
But I don't think Evan
is actually talking about the mechanics of how patches get in, although
maybe he is. I think he's probably talking about a more diffuse set of
topics like how does this fit in with standardization, code quality, code
style, scheduling, testing, priority assessment, managing scope creep,
funding, feature planning, avoiding micromanagement, product release
cycle, and, apparently, whether there exist uniform practices here. Ie,
all the complicated issues no true blood programmer likes to talk about.
But that's just my guess; I'm sure Evan can help clarify that.
We could also ask Evan if he's thinking more release or merely in source
control, and if a release which branch(s) of distribution, (maybe also
if he intends to transplant patches elsewhere.) There is also that
fascinating question, why he wants to know anyways (otherwise known as
"what is the right answer to give him?")
-Marcus Watts
>
Generally, what Marcus said.
I totally understand the Goodness that are code revision and branching syst=
ems. I'm a big fan. That being said, what I was trying to get at were the m=
ore upper-bounded questions around "how do we know something's ready and ab=
le to go into Stable/1.4/Mainline/Whatever We're Calling It This Week," and=
"how do we know something's ready and able to go in Development/1.5/Experi=
mental/Whatever We're Calling It This Week," and "what's the relationship b=
etween Development/1.5... and Planned 1.6, if not everything in 1.5 is goin=
g to be in 1.6, how does that call get made?" and "if everything in 1.5 is =
going to be in 1.6, how does inclusion in 1.5 get decided?" Right now these=
answers are somewhat unclear for folks who are not able to go to each hack=
athon.
I know this is a very difficult question, going to the heart of "What Is Op=
enAFS?" I don't want to create a huge debate, I only want to get some guid=
elines to help me (and others!) plan our work going forward.
I want to thank Derrick, Simon and Jeff for all giving me good pieces of th=
e answer over the past few days. Derrick pointed me to some historically di=
scussion on other lists, Jeff pointed me to the roadmap. Simon's discussion=
was especially useful as an overarching review of the current thinking fro=
m those making the decisions.
Going off on a small tangent, I believe all critical DAFS issues that have =
been reported to OpenAFS.org have been fixed or have fixes publically avail=
able. I know that was important, and it has been a main priority for us.
At this point, I think I know what I needed to know regarding the process. =
Many thanks to everyone on list for helping me out.
Sincerely,
Evan Macbeth
--_000_C71D9C3911CFAemacbethsinenominenet_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Release Inclusion (was rxk5 Mainline Issues)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>What a great discussion!<BR>
<BR>
To wit:<BR>
><BR>
But I don't think Evan<BR>
is actually talking about the mechanics of how patches get in, although<BR>
maybe he is. I think he's probably talking about a more diffuse set o=
f<BR>
topics like how does this fit in with standardization, code quality, code<B=
R>
style, scheduling, testing, priority assessment, managing scope creep,<BR>
funding, feature planning, avoiding micromanagement, product release<BR>
cycle, and, apparently, whether there exist uniform practices here. I=
e,<BR>
all the complicated issues no true blood programmer likes to talk about.<BR=
>
But that's just my guess; I'm sure Evan can help clarify that.<BR>
<BR>
We could also ask Evan if he's thinking more release or merely in source<BR=
>
control, and if a release which branch(s) of distribution, (maybe also<BR>
if he intends to transplant patches elsewhere.) There is also that<BR=
>
fascinating question, why he wants to know anyways (otherwise known as<BR>
"what is the right answer to give him?")<BR>
<BR>
&nb=
sp; =
&nb=
sp; -Marcus Watts<BR>
><BR>
<BR>
Generally, what Marcus said. <BR>
<BR>
I totally understand the Goodness that are code revision and branching syst=
ems. I’m a big fan. That being said, what I was trying to get at were=
the more upper-bounded questions around “how do we know something=
217;s ready and able to go into Stable/1.4/Mainline/Whatever We’re Ca=
lling It This Week,” and “how do we know something’s read=
y and able to go in Development/1.5/Experimental/Whatever We’re Calli=
ng It This Week,” and “what’s the relationship between De=
velopment/1.5... and Planned 1.6, if not everything in 1.5 is going to be i=
n 1.6, how does that call get made?” and “if everything in 1.5 =
is going to be in 1.6, how does inclusion in 1.5 get decided?” Right =
now these answers are somewhat unclear for folks who are not able to go to =
each hackathon. <BR>
<BR>
I know this is a very difficult question, going to the heart of “What=
Is OpenAFS?” I don’t want to create a huge debate, I onl=
y want to get some guidelines to help me (and others!) plan our work going =
forward.<BR>
<BR>
I want to thank Derrick, Simon and Jeff for all giving me good pieces of th=
e answer over the past few days. Derrick pointed me to some historically di=
scussion on other lists, Jeff pointed me to the roadmap. Simon’s disc=
ussion was especially useful as an overarching review of the current thinki=
ng from those making the decisions.<BR>
<BR>
Going off on a small tangent, I believe all critical DAFS issues that have =
been reported to OpenAFS.org have been fixed or have fixes publically avail=
able. I know that was important, and it has been a main priority for us. <B=
R>
<BR>
At this point, I think I know what I needed to know regarding the process. =
Many thanks to everyone on list for helping me out.<BR>
<BR>
Sincerely,<BR>
<BR>
Evan Macbeth<BR>
</SPAN></FONT>
</BODY>
</HTML>
--_000_C71D9C3911CFAemacbethsinenominenet_--