Re: Feature freezes and Emacs 25

[Xue Fuqiao]

On Wed, Nov 11, 2015 at 1:50 AM, Eli Zaretskii <address@hidden> wrote:

Hi Eli,

> Please grep all the repository for references to FOR-RELEASE.  At
> least admin/notes/bugtracker still does.

Fixed, thanks.

I removed the reference to FOR-RELEASE in admin/notes/bugtracker,
because I think all bugs found should be in the bug tracker, instead of
having some of them in the RELEASE-PROCESS file.

>> 1. Document when to remove obsolete features.  For example, "if a
>>    feature is declared obsolete in version `major.minor', it will
>>    continue to work in versions `major.minor' and `major+1.minor' but
>>    raise warnings, and it will be removed in version `major+2.minor'".
>>    I don't think we have a policy for removing obsolete features
>>    currently, but IMHO it would be good to have one.
>
> I'm not sure a fixed policy of this kind is possible.  Minor features
> can be removed quickly, not-so-minor ones not so quickly.

OK.

>> 2. Document what to do if a bug needs to be addressed in the next
>>    release (a.k.a. release-critical bugs).  For example, how to set the
>>    bug meta-data for release-critical bugs, what meta-data to set, the
>>    criteria for release-critical bugs, etc.  I didn't write this because
>>    I don't know how.  Patches/suggestions are very welcome.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00226.html

Thanks.  I've made some changes about this in the new patch (attached).
Furthermore, I hope we can get rid of the BUGS section in
RELEASE-PROCESS and move it entirely to Debbugs.

(BTW, I hope we can file a meta-bug, listing all release-tracking bugs
like #19758 and #19759, and update it in each release, so that we don't
have to update the RELEASE-CRITICAL BUGS section in every future
release, and we can see our previous release-tracking bugs more
conveniently.)

>> * IMHO the current status of Emacs development should be present
>>   somewhere, for those who don't follow emacs-devel closely.  Something
>>   like this would be a good start:
>>   https://wiki.documentfoundation.org/ReleasePlan/5.1#5.1.0_release
>
> That's not status, that's plan.  See the discussion about cadence
> model for what I think about that in conjunction with Emacs.

OK, I'll see.

>> * I think we need to encourage developers to prioritize bugs during
>>   phase two and/or phase three in the release cycle (see my patches for
>>   the three phases).  It will make the quality of the new release
>>   better, or at least give developers an overview of the general
>>   development (bugfix) direction.
>
> Not sure what you mean by "prioritize bugs".

I mean, adding severity level for bugs and adding blocking bugs.  So
the chance of important bugs missed in the new release will be reduced.
This needs to be done in every phase, but is even more important in the
bugfix phase.

>> [1] My `pre-commit' hook won't let me commit if I don't remove the
>> trailing whitespace ;-)
>
> There's the --no-verify switch to "git commit".

Thanks for the hint Eli - you are right as usual.

>> +** Phase two: feature freeze
>
> I think we should discuss this and understand better why this is
> needed and what are its entry and exit conditions.

I agree.  John (and others)?  Any comment on this?

>> +Shortly before the feature freeze, Emacs developers will be devoted to
>> +figuring out what features to include in the next release and what
>> +features to defer to a later release.
>
> If the feature is already on master, we don't have any easy way of
> removing it.  Nor should we, IMO.

That's not what I meant.  I meant the long-term feature branches
(concurrency/dynamic-modules/xwidget), and features still under
discussion (xref/project?).

>> +After we cut the release branch, we’ll make pretest and release
>> +candidate (RC) releases.  For pretest releases, the "devel" component
>> +changes to 90, 91, ...
>
> The number of the first pretest version is not carved in stone.  It
> depends on the developers' estimation of how close we are to the
> release.  E.g., Emacs 21.1 had its first pretest called 21.0.70,
> AFAIR.

But IMHO having a consistent versioning scheme for pretests should
better in the future.  The estimation is somewhat subjective.

Thanks for your review!

0002-Document-the-release-process.patch
Description: Binary data