Policy for commits to master

[Thibaut Cuvelier]

On Mon, 31 Oct 2022 at 18:49, Scott Kostyshak <skostysh at lyx.org> wrote:

> 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.
>

Is this about making commits or pushing them? It usually makes sense to
split changes into commits, for instance for ease of review. (I totally
agree that master should remain more stable when nearing a release.)


> - 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.
>

More generally, what about bug fixes that imply larger-scale changes, like
updating the format? Should they be treated like features and undergo
serious local testing before pushing them?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221101/f17baeac/attachment-0001.html>