On Tue, Nov 16, 2004 at 10:43:15PM -0600, William A. Rowe, Jr. wrote: > I entirely agree - stability of the already-done version 2.0 is > paramount to me. However we need to make some edge case expections > for that code which only one or two voulenteers are familiar with. > e.g. Win32 service code is only known by 4 members, Novell by only > one, and ldap only three of us ever pay attention. > > 'Platform maintainers' should have some way to get measurable and > tested code improvements back into 2.0.
I'd be fine with us defining some exceptions to the 'RTC' area (and making it CTR and hence lazy consensus): stuff like platform specific code, or experimental modules. But, remember, experimental modules as a concept disappears in 2.2: the only way to introduce a new module is to roll it into the next minor release branch. However, I strenuously object to core code changes being merged into stable without 3 +1s first. The real solution to Brad's problem of not having enough code visibility for your changes is to push out more frequent branches *not* making stable turn into unstable. Pushing out a new 2.(x+2).0 release every few months (or even 6 months!) would go a long way to solving the 'black hole' dilemma. Yet, I don't believe that lapsing back into CTR is the right solution. -- justin
