[OpenAFS-devel] AFS + Object Storage

[Jeffrey Hutzelman]

On Tuesday, May 08, 2007 10:18:59 AM +0200 Hartmut Reuter 
<reuter@rzg.mpg.de> wrote:

> Of course, you are right that this change will not go into 1.4.x, but to
> have a stable reference and a base which can immediately be used in
> production I always put my changes into the current stable release.

Sure; there's nothing wrong with that.


> Of course the changes are large. If the gate-keepers prefer I could
> create a version based on another CVS branch. But it takes a while (it's
> a manual port, anyway) and I must be sure this branch doesn't change too
> much in the meantime.
>
> Which one would you suggest?

Well, I'm not a gatekeeper, so suggesting is about all I can do.  I would 
start by picking a specifc version, either a 1.5.x release or one of the 
daily CVS snapshots, and making all of your changes relative to that.  If 
this is going to appear in 1.5.x, then it doesn't much matter whether you 
port to 1.5 or to the head, because it will have to be committed in both 
places eventually, so someone will have to do the conversion.

I guess the choice depends on how things are going to proceed from here. 
If you want to get other people running this, or you want to be able to run 
it yourself and upgrade OpenAFS without a major porting effort each time, 
then I'd suggest distributing patches based on 1.5.x for a while, and not 
worrying about porting to the head until it is ready to be committed. 
There are often significant changes between successive 1.5.x releases, but 
I think that work going on now (that I know about) is unlikely to produce 
serious conflicts with your code, so porting from one 1.5.x to the next 
should not be too hard.  Of course, the 1.5 branch also has the advantage 
that it can actually be expected to compile and run most of the time, which 
is not always true of the trunk.

On the other hand, if your main goal is getting the patches into the CVS 
tree in some form, even if it takes quite a while before they appear in a 
release, then you're better off porting to the CVS trunk.  It's relatively 
easy to get the gatekeepers to commit things there, even with minimal 
review and even if they're clearly not ready for inclusion in a release 
branch.  That's because OpenAFS releases are never done from the trunk, and 
our practices don't require it to be stable or even compile -- it's all 
about getting the code where people can look at it.


BTW, I would suggest when you prepare patches that you split them into 
multipe pieces where appropriate.  For example, you might have one patch 
that adds support for your extensions to the fileserver, and another to the 
cache manager.  Similarly, if you have multiple features that are logically 
separate, they should be in separate patches.  Smaller patches are easier 
to understand and review.

In a similar vein, new or modified code should be consistent with the 
existing style.  Avoid making changes in formatting or whitespace to 
existing code that you are not modifying; for example, don't reindent 
entire source files -- that makes the patches large and the changes 
difficult to identify.  If you do make large formatting or style changes, 
do it in a separate patch which makes _no_ substantive changes.  (BTW, note 
that I haven't looked at your code yet, and much of this is general advice 
not aimed specifically at you).


>> In general, submitting patches to OpenAFS is not the way to modify the
>> AFS wire protocol.  Instead, protocol changes should first be brought up
>> on the afs3-standardization mailing list, which is the official forum
>> for discussing changes to the AFS protocols.  Again, it is best to bring
>> up proposed changes before getting too far with the implementation, to
>> limit the amount of wasted effort if the mailing list has objections or
>> suggestions for improvement.
>
> That was the reason why I came to the Hackathon last year to inform the
> AFS developers early about our project.


Sure; that was definitely a good idea, and hopefully it was helpful to you. 
That advice was intended largely for anyone else who might be thinking 
about working on AFS.  The idea is that if there had been something 
controversial about your approach, or a major issue you were overlooking, 
you would have found out about it early instead of after wasting months of 
effort.

Anyway, I look forward to reviewing your stuff, just as soon as I dig 
myself out from under this giant pile of work.  :-(

-- Jeff