On Fri, Jun 19, 2009 at 9:24 AM, Derrick Brashear<[email protected]> wrote: > I've herd this came as a surprise to some folks. It shouldn't have. Attempts > to introduce > anything large into an existing stable series have always been met with > 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, when > patches show up > there either someone (usually me) has to do the work of merging them to the > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
