unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: emacsq <laszlomail@protonmail.com>
To: Po Lu <luangruo@yahoo.com>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Releasing small, not critical features as bugfixes
Date: Sun, 10 Apr 2022 16:37:55 +0000	[thread overview]
Message-ID: <DVdyZnJB2ym2hIuDAW0XASGrtY8md4BgxvXuzDfEdIswpgLgrBkDe_7JgZK8HKKVgWb_pr8xtJSlPV-mfMOoUrFe_t_uFcsDP7VG5WL0lUs=@protonmail.com> (raw)
In-Reply-To: <87tub19n7m.fsf@yahoo.com>

>
> Famous last words. You'd be surprised at how much trouble seemingly
> innoculous changes can cause.

A change in show paren, for example, has some risk, but much less risk than changes in native compilation, for example.

People using this lower risk future branch would know they still use a testing branch, so they would expect occasional hiccups, of course.

> So that means we will have 3 branches actively diverging at the same
> time. Who will do the merges in between?

Code committers could tag their commits with some marker like "low risk" or such if they know their commits can work well as separate changes and and automatic process could merge these tagged changes automatically into this low risk future branch.

So practically this branch could be kept up to date automatically by a script, there would be no additional work for developers aside from optionally marking commits for this low risk branch if they think their changes can also go for early release.



  reply	other threads:[~2022-04-10 16:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-10  6:16 Releasing small, not critical features as bugfixes emacsq
2022-04-10 11:45 ` Po Lu
2022-04-10 16:37   ` emacsq [this message]
2022-04-10 18:31     ` Corwin Brust
2022-04-10 20:00       ` emacsq
2022-04-11  3:20     ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='DVdyZnJB2ym2hIuDAW0XASGrtY8md4BgxvXuzDfEdIswpgLgrBkDe_7JgZK8HKKVgWb_pr8xtJSlPV-mfMOoUrFe_t_uFcsDP7VG5WL0lUs=@protonmail.com' \
    --to=laszlomail@protonmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).