Re: Reconsider defaults for use-package-vc-prefer-newest

[Martin Edström]

On Mon, 16 Sep 2024 20:57:15 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

> > [1] https://github.com/slotThe/vc-use-package
> 
> That's a different package, so I don't see why we should necessarily
> follow its decisions.  When users migrate to use-package :vc, they
> should expect some changes in the default behavior.
> 
> > You cannot rely on users to configure this kind of thing for themselves, 
> > most of them would not know the reason why things broke. It is not a matter 
> > of "liking" the default, since breakage in one direction would be much more 
> > severe than is possible to encounter in the other direction (years out of 
> > date vs. slightly too new).
> 
> Nowadays an Internet search will bring the answers very quickly and
> efficiently.  And if that's not enough, there are enough user-level
> help forums where people could ask questions and get useful answers.
> 
> IOW, "not a catastrophe".
> 
> > It is absolutely Emacs' responsibility, at least as long as stability for 
> > users is desired. Isn't it the reason to favor conservative defaults? 
> > Avoiding breakage? I get this new default comes from a good place, 
> > intending stability, but it is a radical departure from what has been the 
> > norm established by Straight/Quelpa/el-get and their use-package 
> > integrations, and that will work against stability.  
> 
> We can only be responsible for stability when our own implementation
> and decisions are concerned.  We cannot be expected to blindly follow
> someone else's decision in the name of "stability" for users who
> switch from other packages, this kind of expectation is completely
> unreasonable.

I am sorry.  I use the word "responsibility" perhaps different from many 
people, I think of responsibility as basically good, a nice thing to have, but 
as words go it's a powder-keg with different interpretations. I did not mean to 
be entitled nor expect the Emacs volunteers to do any services for me or anyone 
else.

I also have not contributed any core Emacs code (yet), and I am very grateful 
to those who have, such as yourself, Eli.

We are currently enjoying a Golden Age of Emacs, and I see that as being a lot 
about the Emacs Lisp ecosystem wrapped around the Emacs core, and of course, 
Emacs core doing what it can to be friendly to that ecosystem.  To me, Emacs 
*is* the ecosystem.

That frames my opinions about this new default setting.  It does not seem to me 
like the theoretical benefits outweigh the costs to GNU reputation each time a 
GitHub issue is raised to a developer who preferred to just do rolling releases 
(e.g. just today I had to warn someone at 
https://github.com/JuliaEditorSupport/julia-emacs/issues/212).

I believe I've said all I had to say, but to be very clear for the record, I 
consider this default to be radical, not conservative, at least from the 
perspective of causing least breakage.  I also do not think it is good 
stewardship of the ecosystem to say that each user can just Google the solution 
once they face breakage.  It affects developers too, who may not have learned 
about this default, and lose users as a consequence.

Anyhoo. The concept of versioned releases is good, and if git/hg tags are 
checked, that's great. Maybe it's not the end of the world that devs who want 
pure "rolling releases" are forced to adopt some sort of automated toolchain 
that pretends to cut releases for every commit, or insert a warning message to 
their users to upgrade to the master branch. But novice devs and experimental 
packages frequently fit into this box so I have mixed feelings about that.