Policy for commits to master

[Scott Kostyshak]

On Tue, Nov 01, 2022 at 02:23:26AM +0100, Thibaut Cuvelier wrote:
> 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.)

I agree smaller commits are better, although it is nice when they are
atomic commits. In the case you describe, where you essentially do an
"atomic push" rather than atomic commits, I think it's especially
helpful to have the feature merged from a branch, rather than rebased.
That way, when bisecting, it will avoid a lot of potential
"git bisect skip". Does that work?

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

It depends how serious the bug is that's being fixed (if the bug is
minor and the fix is major, then I think that should be treated similar
to a feature), and also the code that's being touched (e.g., if the big
changes are restricted to docbook-only code).

On the other hand, if you're trying to fix a tricky release-blocking
regression, it is more understandable if you break something on master.

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/a97c3aad/attachment.asc>