The work performed under support contracts is driven by the end user organizations that pay for them. Writing unit tests, regressions tests, performance tests, and more are all desirable. However, it is unreasonable to expect support organizations to put the time and energy into developing them without funding.
Support contractors do not have veto on the acceptance of code contributions. The gatekeepers do have a veto but rarely use it. Things that will result in a code rejection are: * changes to the semantics of existing RPCs * submission of individual patchsets to Gerrit that cannot be reviewed in under an hour or which fail to build on supported platforms. * patchsets that violate the rule "one change per patch. One patch per change." * code review objections from significant developers in the community * features that cannot be tested by the gatekeepers. For example, functionality that depends upon hardware or operational environments that are not generally available. * protocol extensions that fall into the category of changes that have agreed to require afs3 protocol standardization. * changes to data formats without providing tools to convert between the old and new formats. Upgrading to a new revision of OpenAFS must not prevent rolling back to a prior release. The general rule is that if you are going to begin a large coding project is discuss your design early and often. Do not hold onto code changes in your local repository. Push changes to OpenAFS master often and frequently rebase again current master HEAD. With regards to IPv6. No one is preventing you from proposing a design, obtaining consensus and sending patchsets to Gerrit that implement the agreed upon design. However, I am unaware of anyone that is volunteering to implement IPv6 support for you. None of the end user organizations that I speak to have indicated that lack of IPv6 support is in fact a showstopper for them today. Nor are any of them prepared to fund the work. Jeffrey Altman On 9/9/2012 1:19 PM, Troy Benjegerdes wrote: > Since we have no regression tests, everything can go in. And when > a new changes completely breaks something, people providing support > contracts will be motivated to write and submit better tests, instead > of blocking or ignoring new code, which is what the current system > encourages. > > I'd also propose that this test-driven approach be applied, as much > as possible, to major disruptive protocol changes, such as say, > wholesale replacement of all data structures that refer to an IPv4 > address. > > If you can produce a working testcase that will fail with a new rx > protocol change, then you have a valid argument. Otherwise we can > move ahead with some dramatic data structure changes to simplify > getting working ipv6 and rxgk code available for those who don't > have an immediate need to interoperate with any 'old' code.
signature.asc
Description: OpenPGP digital signature
