[OpenAFS-devel] mdw @ google - what I did

[Derrick Brashear]

On Thu, Nov 6, 2008 at 5:16 PM, Marcus Watts <mdw@umich.edu> wrote:
> "Derrick Brashear" <shadow@gmail.com> had replied:
> ...
>> > 82 distinct "changes".  So, I estimate this will encompass about 500-1000
>> > changes at the level requested.
>>
>> I suspect you overrate the granularity desired here. 1000 patches is
>> only marginally better than having to review a 10000 line blob.
> ...
>
> I'm pretty sure it's not the "desired" granularity.  It was the
> "requested" granularity however.  As it happened, "aklog" was a useful
> example: besides rxk5 specific changes, it also had an "-unwrap" option
> which isn't particularly rxk5 specific, but was useful for testing.
> That was specifically suggested as a separate patch.
>
> I think once I go through this exercise, it will be possible to take
> that list of patches and do some combining.  A fair number of these
> patches are going to look pretty repetitive.  There will also be many
> patches that are logically dependent on each other in various ways.
> I think there will be more than one way to combine these changes, so I
> am very open to any ideas folks have on how they would like to see these.
>
> There will also be a set of changes that for various reasons can
> just be eliminated.  For instance, one change I just got rid of was
> "AC_DEFINE([FOO],".  For some reason, when I origionally looked at the
> autoconf documention, I thought they were strongly recommending the
> use of [FOO] over plain FOO.  When I reread it (might have been updated
> meanwhile), they were saying FOO was sufficient.  Argh!
>
> Once I have this list, I'll post it.  It will be basically a one-line
> description per diff, with hopefully enough detail that folks can see
> where there might be an opportunity to combine things.  I don't plan
> to split out the actual diffs until I know more how people would like
> things combined.

Actually, the desire is "be reasonable".

A "for instance" would be one patch which changes Rx to have whatever
new hooks a new auth type needs, another that adds a new auth module,
and a third which makes changes to the parts of AFS which might use
it.

Something that's reviewable.

gerrit will make this review easier, of course.

Derrick