[OpenAFS-devel] Proposal for capabilities support in Unix client 1.4.x

[Marc Dionne]

On Fri, Jun 19, 2009 at 9:24 AM, Derrick Brashear<shadow@gmail.com> wrote:
> I've herd this came as a surprise to some folks. It shouldn't have. Attem=
pts
> to introduce
> anything large into an existing stable series have always=A0 been met wit=
h
> manifold problems,
> complaints from other sites who aren't interested in destabilizing
> influence, and besides, no
> one accepting code has ever said that developing patches for 1.4 with the
> idea that they'd
> go upstream on that branch first or only was a good idea; In general, whe=
n
> patches show up
> there either someone (usually me) has to do the work of merging them to t=
he
> head and 1.5,
> or we have to send them back and ask for a revised version.
>
> The problem really is that 1.5 moved ahead from 1.4 in both client and
> server, and now some folks are stuck.
> We'll help you if you help us. But we can't do all the updating and and
> implementation and integration testing
> ourselves.
>
> Derrick

I think that historically, head and 1.5.x have simply scared
developers into using 1.4 as a base.  I recall a period of close to a
year (maybe more) where head wouldn't even build on Linux when rxtcp
was in there, and 1.5 was usually not that much better.  It's easier
to move to code that works than try to debug or report 5-10 bugs that
have nothing to do with what you're working on, and that's what many
developers did.  The good news is that things have gradually improved,
and of late there shouldn't be a reason not to develop with 1.5/head
and take the time to properly report any bugs that get in the way.

One way to reduce the testing fragmentation we see in 1.5 would be to
move from having every new feature as a compile-time option that is
off by default to a strategy where most options that are deemed worthy
are compiled in and enabled for everyone.  Given the limited
resources, I'm note sure the project has the luxury to support the
wide range of possible configurations that we see today in 1.5/head.
We should aim to get maximum compile-time and runtime exposure for
features so that everyone is compiling and testing other people's work
as much as possible.  This could also have the interesting benefit of
sanitizing the code of the maze of ifdefs we see in there today.

Marc