Dear all, My schedule will clear up a bit in mid-January and I will try to help push the 2.4.0 release out. I will not spend much time before January, but I hope to at least dedicate some time to coming up with a plan.
One immediate issue is whether we can commit features. I think there is support for "opening" master up and allowing features to be committed. I think this makes sense because so much time has gone by, and also I will not have much time until January anyway so the final stages of the release are not near. However, I think it's important we're a bit more conservative than usual. I think everyone agrees that master is not a sandbox, but I think we should be even more careful. I propose the following general guidelines: - Please only commit to master features that you have tested very well, and that do not have any *known* issues. Occasionally we make commits to master that we know will need smoothing out or various follow-up commits. I suggest we avoid doing that, and only commit to master when we are (reasonably) confident in something. - Of course, features almost necessarily imply bugs, and that is understandable. I just ask for careful testing before pushing. If you have doubts, please ask and hopefully another developer/user has time to try to break your new feature. - For non-trivial features, I tend to favor merging a branch to master rather than rebasing on master. I'd be curious on other thoughts though if there is disagreement. - Please only push to master if you will have time to fix something if a bug is found. - If a regression is found because of your commit, I propose that if the bug is not fixed quickly, you revert your feature. We should keep master in a state that at least developers can accept the risk to consider daily driving it. Similarly, by keeping master as "stable" as possible, we can make a pre-release whenever convenient. In fact, getting a pre-release out will be one of my main priorities before January. Several developers and users are using the latest pre-release, which is already quite old, and it would be nice to know which issues are still relevant. I need to think some more before I propose a timeline (that will be open to feedback), such as a specific date for feature freeze. Scott
signature.asc
Description: PGP signature
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
