[OpenAFS-devel] Road map, was Proposal for capabilities support in Unix client 1.4.x

Simon Wilkinson sxw@inf.ed.ac.uk
Mon, 22 Jun 2009 16:04:30 +0100


I can't help but feel that there's a need for a more general  
discussions about the timescales that people require from 1.6.

 From deciding to ship 1.6, to release, there's probably a good couple  
of months of release candidiates and testing in order to be able to  
create a credible 1.6.0. That requires that the input into that  
process is a reasonable source tree (The current 1.5.x / HEAD sadly  
doesn't class as reasonable due to the problems with demand attach).

So, what can be in 1.6 largely falls down to how soon people want it.  
If the above process was to start today, my opinion is that demand  
attach would have to be removed to do so. But, we could do that, if  
there's a desire to get the other features in 1.5 out to an audience  
promptly. So, I think there's an equation that looks something like:

Today: current 1.5 without demand attach
Later: current 1.5
Later still: current 1.5 with rxosd
Even later: current 1.5 with rxosd and rxk5

I suspect that at which point an individual believes the 1.6 release  
line should be drawn probably depends very much upon their sites  
priorities. In a world with no guaranteed effort, of course, there is  
the chance that the ordering of these might also change. My gut  
feeling is that if we were to decide that there definitely will not be  
a 1.6 this year, then rxosd has a chance of making it in. But where  
does that leave people who want the other things that could be in an  
earlier 1.5?

My personal view is that there is more than enough code in 1.5 to make  
stabilising for 1.6 a difficult task. It think we should draw a line  
and get 1.6 out of the door as soon as possible (without demand  
attach, if fixes aren't forthcoming), and then consider a considerably  
more rapid release cycle for 1.8 with rxosd.

Cheers,

Simon.