[AFS3-std] Re: IBM will not re-license OpenAFS .xg files

[Tom Keiser]

On Wed, Aug 29, 2012 at 3:22 PM, Derrick Brashear <shadow@gmail.com> wrote:
> On Wed, Aug 29, 2012 at 12:03 PM, Andrew Deason <adeason@sinenomine.net> wrote:
>> On Tue, 28 Aug 2012 17:28:46 -0700
>> Russ Allbery <rra@stanford.edu> wrote:
>>
>>> There is considerably more that needs to happen with AFS than there
>>> are currently time and resources available to do it.  Standardization
>>> is one of those things.  There are many.  The primary reason why any
>>> specific thing does not get done in AFS, whether that be major new
>>> functionality work or protocol specification work, is "not enough
>>> time/resources."
>>
>> I don't see how this could possibly be true, regardless of the little
>> details of actual AFS development. "Not enough time" is a reason why we
>> don't get _everything_ done, but as to why any one particular "task X"
>> doesn't get done, the reason is that it is prioritized lower than
>> everything else. The only way that "Not enough time" would be the reason
>> for task X not getting completed is if task X could not be done even if
>> myself, Derrick, Simon, et al were working on nothing but task X full
>> time. There are no tasks where that is true, that I am aware of.
>>
>> I think why I don't like your phrasing of this is that to me, it sounds
>> like saying "the _only_ way standards work will proceed is if there are
>> 25 hours in a day, or more people are brought on to the process" (that
>> is, the only way is if more time/resources are obtained). Whereas my
>> opinion is that it is more true to say "standards work will proceed if
>> we work on it instead of working on other things A, B, and C" (that is,
>> if we reprioritize tasks).
>
> The problem is actually that there is no "we", we are but a loose
> confederation of folks.
>

Indeed.  However, I wonder if we could at least partially overcome
this quandary by tentatively agreeing to cooperate a bit more closely.
 Andrew's idea of focusing on one document at a time, rather than the
current free-for-all, is intriguing.

Let me raise an issue: from my perspective, part of the malaise
seemingly stems from the authors--particularly of the big
documents--lacking time to incorporate feedback (I reluctantly stalled
rxrpc-sec-clear for that reason).  Would it help if, on a best-effort
basis, reviewers submitted proposed xml diffs with their critiques?
Moreover, if we were to stick the xml files somewhere that permitted
collaborative editing (e.g., git.openafs, github, gerrit.openafs),
would folks take advantage of that ability?

-Tom