Re: Merging native-comp and pgtk

[Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> BTW,
>
> Where are we w.r.t merging those two branches into `master`?
>
> IIUC the plan is to include those features as "experimental" in
> Emacs-28.1, right?  If so, I think it's becoming urgent that we merge
> them into `master`.

Hi Stefan,

my take on the native-comp branch status and some retrospective:

  - This is under development in the emacs.git since more than a year
    (~2y of total dev time, most of my holidays evenings and weekends,
    ~1350 commits).

  - Is, at present, used by literally hundreds of users (see Emacs
    survey).  I believe this should be prove of its stability usability
    and maturity.  I think we can say (seeing the quantity and content
    of feed-backs on the web) that at least on GNU/Linux the experience
    is typically quite slick.

  - Runs on a variety of OSes other than GNU/Linux including: MacOS,
    Windows, various BSDs.

  - A surprising number of packages, configuration kits, distros or other
    members of the ecosystem already provide some kind of integration
    with it.

  - No miscompilation bugs has been found since a while.  IOW
    native-comp is not reported to fail running or compiling any
    specific package.

  - ~6 months ago I was asked by Eli to open a bug [1] to handle code
    review and merge process.  As of today ~3 months more passed since
    my last try to ping this, unfortunately no progress was made.

    Each day the code is not on master we lose some verification
    opportunity.

  - I'm regularly hit by the burden of maintaining an out of tree
    feature branch, not only by conflicts in merge commits (that I do on
    a regular basis) but also by functional breakages.

    Ex: this week my hobby development time budget was wiped-out by
    having to manually bisect the commit that once merged from master
    was breaking the build plus writing the fix.  At least the first
    step was avoidable with the code on master and the emba CI.

This is indeed very demotivational for me and if I can say IMHO probably
not even completely respectful for all the effort that was spent into.

Aside from my personal feelings I'm sorry to report this my other
opinion: I'm convinced that if a Free Software project cannot review new
features is just *not* showing a good health status.

With all the respect, I'm convinced that if the maintainer has no time
for reviewing just means more maintainers are needed.  Not that
development should stop, slow down or the burden should be paid by
contributors.  This is just not an efficient development model.

Best Regards

  Andrea

[1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43725>