Re: sqlite3

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 17 Dec 2021 23:42:07 -0500
> Cc: kfogel@red-bean.com, qhong@mit.edu, eric@ericabrahamsen.net,
>  cesar.mena@gmail.com, emacs-devel@gnu.org, luangruo@yahoo.com, eliz@gnu.org
> 
>   > Normally, potential new features spend more than just a few days on a
>   > git branch, allowing people the chance to try them out and spot any
>   > problems.  That didn't happen with this new sqlite feature.
> 
> That is where I see a problem, too.

Which problem is that?

According to Git logs, the sqlite branch was created on Dec 6, and
merged to master on Dec 11.  That's almost a week.

We ask people to try a branch when it provides a significant feature
that could affect everyday use of Emacs, or if we have reasons to
believe it could mis-compile or break on some platforms or
configurations, or if it has some significant user-facing aspects for
which we'd like feedback.  That's why the bidirectional display was
originally on a branch.  That's why the PGTK build is on a branch now.

In all other cases, we use feature branches to allow the developer to
work on a feature without affecting people who track the master
branch, as long as the feature isn't mature enough to land on master.
We then merge to master when the branch is mature enough.  Which is
exactly what happened here: this is a minor feature that is almost
orthogonal to anything else in Emacs, so there was no reason to keep
it on a branch longer than it took to make it mature and stable.  We
have enough examples of features that were merged when they were less
stable than this one, we have merged stuff that broke the Emacs build
on one or more platforms.  This is normal in development, not
something to worry about.

Sorry for being blunt, but I suspect that people who demand features
to be left on branches for prolonged periods of time want to delay
those features or prevent their merge in the first place.

> sqlite3 has problematic implications.  There may be a good solution
> but we have not determined that.  Meanwhile, other solutions were
> there to be considered.

Frommy POV, the problematic implications of sqlite3, such as they are,
were adequately addressed.  Other solutions were considered in due
time, and one of them is now in the codebase.  I see no problem here.

> We should not have rushed the decision on what to do.  We should have
> taken it slow, leaving time for people to study various solutions and
> make a thoughtful decision.

We didn't rush.  There was a discussion with many participants that
took several days, opinions were heard and considered.  The decision
process was sound.  I understand that people who disagree with the
decision might feel the process was lacking, but it is not so.

> Perhaps that decision would have included installing sqlite3.  I won't
> say it wouldn't.  But we should not repeat the way that decision was
> made.

Since I see no problem with the decision-making process in this case,
I don't think I understand what exactly should not be repeated.  It
was a relatively simple decision to make, there's no reason to make a
mountain out of a molehill.