all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Releasing small, not critical features as bugfixes
@ 2022-04-10  6:16 emacsq
  2022-04-10 11:45 ` Po Lu
  0 siblings, 1 reply; 6+ messages in thread
From: emacsq @ 2022-04-10  6:16 UTC (permalink / raw)
  To: emacs-devel@gnu.org

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

I checked if show-paren can show context from off screen and it can, in Emacs 29:

*** New user option 'show-paren-context-when-offscreen'.

When non-nil, if the point is in a closing delimiter and the opening

delimiter is offscreen, shows some context around the opening
delimiter in the echo area.

Emacs 28.1 was just released. Judging from the previous release history Emacs 29 is 1.5/2 years away.

Such small, useful improvements which don't cause critical errors could be released along with Emacs 28 bugfixes, so users can get them earlier, instead of waiting for them for two years.

Of course, there are bigger, more complex improvements which have to be tested thoroughly, but features like the above could be released sooner with the bugfixes, because they are pretty safe improvements.

Or maybe there could be a branch like emacs-future where these small useful improvements could be put, so there is the stable banch (28), this low risk future branch (between 28 and 29) and the bleeding edge (29).

[-- Attachment #2: Type: text/html, Size: 2739 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Releasing small, not critical features as bugfixes
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Po Lu @ 2022-04-10 11:45 UTC (permalink / raw)
  To: emacsq; +Cc: emacs-devel@gnu.org

emacsq <laszlomail@protonmail.com> writes:

> Emacs 28.1 was just released. Judging from the previous release
> history Emacs 29 is 1.5/2 years away.
>
> Such small, useful improvements which don't cause critical errors
> could be released along with Emacs 28 bugfixes, so users can get them
> earlier, instead of waiting for them for two years.
>
> Of course, there are bigger, more complex improvements which have to
> be tested thoroughly, but features like the above could be released
> sooner with the bugfixes, because they are pretty safe improvements.

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

> Or maybe there could be a branch like emacs-future where these small
> useful improvements could be put, so there is the stable banch (28),
> this low risk future branch (between 28 and 29) and the bleeding edge
> (29).

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

I think we already have enough trouble keeping the two actively
developed branches synchronized.  (When was the last time emacs-28 was
merged to master, for example?)

Adding a third to the mix is just asking for trouble, IMHO.

Thanks.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Releasing small, not critical features as bugfixes
  2022-04-10 11:45 ` Po Lu
@ 2022-04-10 16:37   ` emacsq
  2022-04-10 18:31     ` Corwin Brust
  2022-04-11  3:20     ` Po Lu
  0 siblings, 2 replies; 6+ messages in thread
From: emacsq @ 2022-04-10 16:37 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Releasing small, not critical features as bugfixes
  2022-04-10 16:37   ` emacsq
@ 2022-04-10 18:31     ` Corwin Brust
  2022-04-10 20:00       ` emacsq
  2022-04-11  3:20     ` Po Lu
  1 sibling, 1 reply; 6+ messages in thread
From: Corwin Brust @ 2022-04-10 18:31 UTC (permalink / raw)
  To: emacsq; +Cc: Po Lu, emacs-devel@gnu.org

On Sun, Apr 10, 2022 at 11:38 AM emacsq <laszlomail@protonmail.com> wrote:
>
> 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.
>

If your goal is to convince Emacs developers that it would be a small
amount of effort to maintain a separate branch that is Release plus
"simple improvements and fixes from trunk", perhaps creating a "fork"
that introduces the proposed new branch could be a way to demonstrate
that it is "low risk" and "no additional work".



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Releasing small, not critical features as bugfixes
  2022-04-10 18:31     ` Corwin Brust
@ 2022-04-10 20:00       ` emacsq
  0 siblings, 0 replies; 6+ messages in thread
From: emacsq @ 2022-04-10 20:00 UTC (permalink / raw)
  To: Corwin Brust; +Cc: Po Lu, emacs-devel@gnu.org

>
> If your goal is to convince Emacs developers

My goal was just floating this idea for discussion, because I as user see value in releasing small quality of life improvements in Emacs sooner than the usual 2-year cycle.

In the end it is up to emacs developers who contribute code to core emacs to decide if they see value in it, because they are the ones who can judge which commits are suitable for such earlier release, and if the extra decision required is worth the effort.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Releasing small, not critical features as bugfixes
  2022-04-10 16:37   ` emacsq
  2022-04-10 18:31     ` Corwin Brust
@ 2022-04-11  3:20     ` Po Lu
  1 sibling, 0 replies; 6+ messages in thread
From: Po Lu @ 2022-04-11  3:20 UTC (permalink / raw)
  To: emacsq; +Cc: emacs-devel@gnu.org

emacsq <laszlomail@protonmail.com> writes:

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

A feature as low risk as changing a few lines in `shell-resync-dirs' for
it to handle whitespace was recently discovered to cause hangs.  What
would happen with an infinitely larger feature such as the change in
show-paren to display offscreen context?

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

I would want to see such an automatic process.  Would you please work on
it?  That should make it possible to automatically merge emacs-28 to
master as well.

Thanks.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-04-11  3:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2022-04-10 18:31     ` Corwin Brust
2022-04-10 20:00       ` emacsq
2022-04-11  3:20     ` Po Lu

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.