[OpenAFS-devel] Re: OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_65-15-ge5cf14b

[Andrew Deason]

On Tue, 06 Oct 2009 12:07:28 -0400
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> Steven Jenkins wrote:
> > My query is asking around about consensus.  Who is for/against at
> > this point.  And for those against, are the objections/concerns
> > strategic (i.e., 'I'll never support this idea") vs tactical (i.e.,
> > 'I'll support it once X is available/happens/etc'), and what are
> > those concerns/objections?
> 
> You appear to be contradicting yourself with what you say below.
> On one hand you want the person who submitted the code change to
> be responsible for submitting the docs.  On the other you want the
> community to collaborate to fill in the missing pieces.

Nowhere do I see Steven saying the documentation contributor must be the
same as the code contributor. If you receive a code contribution without
documentation updates (that requires documentation updates), you don't
include it until documentation has been written by /someone/.

As to Steven's question of "for/against", I don't see any problems, as
long as you're not requiring the same person who submitted it to write
the docs. If nobody understands the change enough to document it and is
willing to... I'd say that's problematic enough to block inclusion until
that situation changes.

> > I guess I misunderstood the situation: for example, I thought that
> > if I propose a new on-disk format for the fileserver, that the
> > discussion would need to go through afs3-standardization.

As has been said, this isn't a wire protocol change, so it doesn't
require afs3-std discussion. I would think any on-disk format change for
any OpenAFS stuff needs at least a mention on the openafs lists, though.

-- 
Andrew Deason
adeason@sinenomine.net