Felix Frank wrote: > I was not actually writing in defense of those who would accuse the > gatekeepers of stalling their efforts, stealing their credits or > whatever.
I didn't feel you were. > I merely felt compelled to comment on the notion of "stable > should be stable except for what I'm running over here", and how we (and > some others, I presume) came to adopt it. I wasn't actually directing it > at you (the gatekeepers) or anyone specifically, as obviously you are > aware of these things a lot more strongly than me myself. What we need are more frequent and regular transitions of the "features" branch to the "maintenance" branch. The 1.2 maintenance series began in Sept 2001. The 1.4 maintenance branch began in Nov 2005. It is now July 2009. Four years between transitions is way too long. We knew that in 2005 and promised that it wouldn't happen again. We wanted to have a 12 to 18 month transition from "features" to "maintenance". So what happened you might ask? Well, up until Sep 2007 all of the work that had been done on the "features" branch for non-Windows platforms had been code cleanup. There was any new big "feature" to drive the release. In fact, if you had been developing your "big new thing" tracking openafs-devel-1_5_x in those days you probably would have been very happy. The code was known to be stable and could be used in production. Then when the 1.5.25 release was issued in 20 Sep 2007 with the Demand Attach File Server code the world changed. The code wasn't stable enough for production use and those that provided the submission were not aggressive about fixing issues. All of the sites that the gatekeepers convinced to test the code found it didn't run well enough to get started, submitted bugs to OpenAFS RT and then went back to their day jobs. The gatekeepers did not have the resources to fix the issues and as a result all subsequent server side testing by the community of the features branch effectively came to a halt. It is almost two years since DAFS was committed and there are open issues that the contributing organization is still working on that I believe must (or at least should) be addressed before the "git master" can become the basis for a new maintenance series. There is a strong sense that pulling DAFS from the master at this point in order to start a new maintenance series would not be beneficial. It would put organizations that deploy OpenAFS at risk for little functional gain. That is not to say it wouldn't help the developers. :-) > Also, you have laid out very well why it basically couldn't be helped in > the past. I fully agree with Derrik that as things are, all efforts > should be concentrated on eliminating all divergences as soon as possible. We cannot stress it enough. Small incremental changes are much easier to review and incorporate than big ones. You have made an incredible effort refactoring and breaking up the code base you are working with to ease our efforts. We appreciate that. Combined with the new tools from gerrit it is much easier not only for the gatekeepers but for the entire community of developers to review and chime in. Especially with gerrit the rate of change in the code base is only going to accelerate. We have seen it already. The rate of collisions between development efforts is only going to get worse. Keep things small and contribute often. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
