On Tue, Nov 3, 2009 at 3:05 PM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Obviously, we are still waiting on the final patch for 0.47 before it can be released. When we were wanting to release 0.46, we had a similar issue with a Win32 specific issue holding up the release. This brings up something that needs to be addressed before the 0.48 cycle begins.
Is this patch being worked on? It's been my impression that the issue is at least hard to reproduce, to start with.
I may be wildly off the mark, but I would vote to release right now.
It would be really helpful if for 0.48 we have a temporary policy, please comment on this if you agree, disagree, or have suggestions. For 0.48, it would be nice if anything that is a major change (aside from our GSoC projects) is NOT put into trunk until it has been well tested in a branch and/or privately by other devs/testers (I am willing and excited to test!). It would also be nice if we decide on an open committing period (time before Feature Freeze). For open committing, I would think 8-12 weeks should be sufficient to not break things too badly, yet still give enough time to flesh features out.
How do we define "major"?
Generally I'm in favor of making 0.48 more restrictive, because otherwise we won't be able to do it fast. I'd suggest that people start working on patches already, so they are ready to commit when we reopen!
I know this is much more restrictive than our normal development process, but for 0.48 to be as good and solid as possible (as soon as possible), this route makes the most sense. Obviously, once 0.48 gets out the door and we are onto 0.49, people can go back to committing responsibly... but, it would be nice if we had a policy moving forward of "if you break it, you must fix it".
Such policy is an absolute must, and mostly we adhere to it. I think it only gets violated when the damage is discovered too late when the original author is no longer available.