I'm what I consider to be a user that doesn't "stress" the editor, so
therefore I'm unlikely to see the sorts of bugs I can usefully test and
report. I also don't install the kitchen sink, so there are far less
chances for bad interaction between things. The most chance I've had to
test something that might (vaguely) have affected me was with the recent
dired-killing-frame-on-start bug (#65277), and I don't normally start emacs
with a dired session anyhow.

In regard to release cadence, I'm not really bothered how long the product
(in this case, the new version of an editor with new functionality) takes
to produce. I just want it to be stable enough to work when I compile and
run it. I'm not honestly sure how you'll get useful aggregated information
out of my class of users, any hints here? (Aside from that of simply
getting more involved).

Regards, brickviking



On Wed, 30 Aug 2023 at 04:12, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 29 Aug 2023 16:14:22 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> >
> > And, btw, the last 3 major releases took 1.25 to 1.5 years, so already
> > quite close to the 1-year mark.  Not 2 years, as you say.
>
> Btw, if we want to make more frequent releases, we should start from
> making sure each code change is accompanied by a suitable change to
> our manuals.  The NEWS file on master is once again full of entries
> with neither "---" nor "+++" markings, and going through all such
> entries and documenting them (or deciding not to) is a job that takes
> quite some time if delayed to before the first pretest.  I'd
> appreciate if people who want to push for more frequent releases would
> either work on documenting changes that their authors didn't, or at
> least would remind those authors to maybe provide some documentation.
>
> IOW, making our releases more frequent will take a serious effort from
> everyone, otherwise it will simply not work for any number of good
> reasons.
>
>