On Tuesday, May 08, 2007 10:18:59 AM +0200 Hartmut Reuter
<[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
