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