[OpenAFS-devel] warnings fix

[Felix Frank]

Jeffrey Altman wrote (Fri Jul 17 2009 15:10:38 GMT+0200 (CEST) )
> Felix Frank wrote:
>> Granted. Speaking only for myself, I would have liked to see a model
>> that left the stable branch as just that, but allowed for additional
>> branches off stable (such as, say, rxk5, rxosd etc.) that would have
>> allowed
>> a) interested sites to perform testing if they choose to and
>> b) the community to observe and guide the evolution of such development
>> endeavors
> 
> One of the primary reasons we started the work to switch to "git" in Feb
> 2008 was to permit sites to do so.  With git you can publish your own
> tree and make it available to others to review.  We simply could not do
> this with cvs.  The security model simply did not permit it.  We had to
> know we could trust the developers first because we could give commit
> access.
> 
> That being said, there has been an rxk5 development branch in the
> cvs repository for many years.  There was also an rxtcp development
> branch.  A disconnected development branch.  Etc.
> 
> However, they cannot be branches off of stable.  We have said this many
> times.  "stable" is for bug fixes and new platform support only.  No new
> development work is going to end up on the "stable" branch.  All that
> putting this work on the "maintenance" branch does is provide further
> incentive for sites to avoid using the "development" or "features" branch.
> 
> The point that the gatekeepers have made over and over again is that
> the maintenance branch is expected by sites that use it to be stable.
> It should not change from release to release except for fixing known
> bugs or supporting new kernel versions.  The vast majority of sites
> do not want to be handed new "feature" code when they install a security
> update.

Ah, but this scenario implies an actual merge of the feature before a 
maintenance release. This is not at all what I was thinking of.

However, below you apparently make the likely suggestion that, instead, 
even *if* code would have lived in OpenAFS branches, without being 
merged, it would have been just as dead as it has been in the cvs age, 
outside of OpenAFS.

> The large gap between the "maintenance" and "feature" releases of comes
> from the fact that (except on Windows which doesn't have a choice) there
> simply are no organizations that are willing to run their storage
> systems on the "features" release.  Without that there is not sufficient
> testing in real world conditions.
> 
> When a new pile of code gets delivered to OpenAFS that was developed
> in-house the gatekeepers were forced to make a hard choice.  Do we throw
> the code into a new branch where it will rot or put it onto the
> "features" branch and force sites that are tracking that branch to use
> it.  (Assuming of course there were any.)  Because we do not want code
> to rot, the code often ends up on the "features" branch.  Pthreaded ubik
> is on the features branch even though it doesn't work correctly and by
> "work correctly" I mean it will destroy your data.  Its there so it
> doesn't bit-rot and we feel is it ok to remain only because we do not
> compile anything that uses it.

The attitude of rather including features than sorting them away is 
commendable I think. However, by rendering the feature branch largely 
unusable, a lesser form of bitrot emerges (imho). More specifically: If 
a contributing party is unable to deploy the OpenAFS branch that 
includes their feature, they cannot efficiently continue 
testing/development.

This is not me complaining, but pointing out an issue that boils down to 
organizational problems as pointed out by you farther above, as this was 
the only conceivable way for you to go about this.

> There is no blame to go around when there are simply no resources
> available to do anything else.  I appreciate the need for individuals to
> vent but when individual developers (in general) put the blame on the
> existing leadership it is really insulting.

I was not actually writing in defense of those who would accuse the 
gatekeepers of stalling their efforts, stealing their credits or 
whatever. I merely felt compelled to comment on the notion of "stable 
should be stable except for what I'm running over here", and how we (and 
some others, I presume) came to adopt it. I wasn't actually directing it 
at you (the gatekeepers) or anyone specifically, as obviously you are 
aware of these things a lot more strongly than me myself.

Also, you have laid out very well why it basically couldn't be helped in 
the past. I fully agree with Derrik that as things are, all efforts 
should be concentrated on eliminating all divergences as soon as possible.

Sincerely
  - Felix