Policy for commits to master

[Scott Kostyshak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221031/6ad59f47/attachment.asc>