Re: Release process (was Re: Move to a cadence release model?)

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 11 Nov 2015 04:45:18 -0600
> 
> >> From: Stephen Leake <address@hidden>
> 
> >> Which is precisely why we have a feature freeze phase; it enforces this
> >> desire.
> >
> > We cannot enforce it.
> 
> Well, the feature freeze encourages developers to work on the release
> more than a non-feature freeze model does. At least, it works that way
> for me.

Alternatively, someone else could simply take a break from working on
Emacs until the freeze is over.

> >> I know I would be _very_ tempted to ignore the release branch, to keep
> >> working on my latest Cool Feature instead.
> >> 
> >> If I know I have to wait for a release before I can merge to master
> >> again, I'll work on the release as much as I can.
> >
> > These considerations will become valid only when we have enough
> > developers paying attention to bugs that are reported.  (That includes
> > you, Stephen, btw.)  

(Upon re-reading, I apologize for being so blunt.  It just feels too
lonely there, at times.)

> Yes. I don't scan the bug tool for bugs that I might be able to work on;
> sometimes it seems I should. For now, I rely on someone interested in
> the bug emailing me if they think I could help.

I don't thibk this will work efficiently.

> Is there a way to get an email for every new bug?

Yes, subscribe to bug-gnu-Emacs mailing list.

> I'm curious how much traffic that would be.

You can see that in the archives.  About 30 messages per day on the
average, maybe.

> During the last feature freeze, there were reminders on this list of the
> bugs that were deemed release-critical.

That's the last resort.  There are gobs of bugs that don't block
anything, and some of them are left alone for far too long.

Even a prompt response that just says the bug was reproduced (or not),
and ideally also with results of some initial investigation and/or
request from the OP to provide more details or try something -- even
this would be progress.

And then there are small patches submitted there -- review and comment
will be appreciated.  Patches that are no-brainers, e.g., fixing a
typo or some other obvious mistake, should be pushed if there are no
comments after a week, say.

> There may be other release-critical bugs that I can usefully work on.

The problem IMO is not the release-critical bugs, it's all the rest.

> I don't have statistics on how well the feature-freeze model works in
> getting release-critical bugs fixed.

It doesn't work at all.  Release-critical bugs normally appear near
the end of the pretest.  Or at least they become important only then.

By contrast, I'm not talking about bug fixing during the pretest, I'm
talking about routine attention to the reported bugs.