Harald Barth wrote: > Ehm, 1.5/Linux is not fit for production, so according to be useful in > production, the OSD stuff must be made against 1.4.
People said exactly the same thing about 1.2 when we were trying for years to get 1.4 stable. If you spend all of your effort focused on the past we will never get to the future. I understand your desire to deploy RxOSD today. In fact you are deploying RxOSD on 1.4 today with private patches. So why do you care of OpenAFS ships it in 1.4 when we are attempting to migrate stable to 1.6? Why do you want a 1.6? Well for starters it contains three years of effort focused on improving code quality by adding prototypes almost everywhere and (mostly thanks to Simon Wilkinson) reducing the number of compile time warnings from over 30,000 to under 1,500. Now 1,500 is still too many but most of these are 64-bit time_t related or signed vs unsigned comparisons which are much less concerning than the wide variety of "uninitialized variable" and "pointer vs int" and "pointer to wrong struct" warnings that exist in 1.4. If you the 1.5 code base is buggy, file bug reports against it so that they can be fixed. If you believe that 1.5 code base is so bad that you can never ever deploy it, please explain why you think that is the case and how you think we need to change it. The situation the gatekeepers find ourselves in is that we have one group of users on the left saying that they want DAFS but don't want RxOSD, another group that says they want RxOSD but not DAFS, another group that says they want Disconnected Mode but neither RxOSD nor DAFS, another group that says they are happy with 1.4 and do not want to risk any breakage in their environment caused by any of these large new features. It is impossible for everyone to get exactly what they want. The compromise is that OpenAFS has a set of policies that govern releases. The stable series which is currently 1.4 does not get significant quantities of new code. All new code goes into the development series (currently 1.5) which then matures and becomes the next stable series. This has been true since OpenAFS began in 2000. You take for granted that the OpenAFS Windows clients are built off of the development branch. Why is that? It is because all of the "extremely stable" code that has been deployed on tens of thousands of systems over the last three years to support 64-bit Windows, Vista and Server 2008 is still considered too risky to pull into the 1.4 series. Everyone thinks their situation is a special case or that their source code is better written and tested than anyone else's. The reality is that isn't true. OpenAFS is a community effort. We all play by the same rules and we all work together to develop a better product. Continuing attempts to pull everything into 1.4 is only going to cause 1.4 to be 1.5 and cause everyone to be unhappy. The way forward to develop on 1.5 and test 1.5 and file bugs against 1.5. Anything else will simply result in deadlock. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
