[OpenAFS-devel] warnings fix

Jeffrey Altman jaltman@secure-endpoints.com
Fri, 17 Jul 2009 10:38:43 -0400


Felix Frank wrote:
> I was not actually writing in defense of those who would accuse the
> gatekeepers of stalling their efforts, stealing their credits or
> whatever. 

I didn't feel you were.

> 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.

What we need are more frequent and regular transitions of the "features"
branch to the "maintenance" branch.  The 1.2 maintenance series began in
Sept 2001.  The 1.4 maintenance branch began in Nov 2005.  It is now
July 2009.  Four years between transitions is way too long.  We knew
that in 2005 and promised that it wouldn't happen again.  We wanted to
have a 12 to 18 month transition from "features" to "maintenance".

So what happened you might ask?

Well, up until Sep 2007 all of the work that had been done on the
"features" branch for non-Windows platforms had been code cleanup.
There was any new big "feature" to drive the release.  In fact, if you
had been developing your "big new thing" tracking openafs-devel-1_5_x in
those days you probably would have been very happy.  The code was known
to be stable and could be used in production.

Then when the 1.5.25 release was issued in 20 Sep 2007 with the Demand
Attach File Server code the world changed.  The code wasn't stable
enough for production use and those that provided the submission were
not aggressive about fixing issues.  All of the sites that the
gatekeepers convinced to test the code found it didn't run well enough
to get started, submitted bugs to OpenAFS RT and then went back to their
day jobs.  The gatekeepers did not have the resources to fix the issues
and as a result all subsequent server side testing by the community of
the features branch effectively came to a halt.

It is almost two years since DAFS was committed and there are open
issues that the contributing organization is still working on that I
believe must (or at least should) be addressed before the "git master"
can become the basis for a new maintenance series.

There is a strong sense that pulling DAFS from the master at this point
in order to start a new maintenance series would not be beneficial.  It
would put organizations that deploy OpenAFS at risk for little
functional gain.  That is not to say it wouldn't help the developers.  :-)

> 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.

We cannot stress it enough.  Small incremental changes are much easier
to review and incorporate than big ones.  You have made an incredible
effort refactoring and breaking up the code base you are working with to
ease our efforts.  We appreciate that.  Combined with the new tools from
gerrit it is much easier not only for the gatekeepers but for the entire
community of developers to review and chime in.   Especially with gerrit
the rate of change in the code base is only going to accelerate.  We
have seen it already.  The rate of collisions between development
efforts is only going to get worse.  Keep things small and contribute often.

Jeffrey Altman