Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote:
> 3. provides a handy reference of key combos you can use to get help,
> save the file, and exit. Yes, you have to know that ^O means "ctrl+O",
> but figuring that out is a lot easier than working out how to drive vi
> from scratch.

After starting 'vi' there is:
~type  :help  orfor on-line help

And after :help there is:
Close this window:  Use ":q".
   Get out of Vim:  Use ":qa!" (careful, all changes are lost!).
  WHAT  PREPENDEXAMPLE
  Normal mode command  :help x
  Visual mode command v_   :help v_u
  Insert mode command i_   :help i_

Isn't that even more helpful than the '^' means 'ctrl' magic?


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
> But, if you don't like our offerings that are targetted that way, I suggest
> you make a spin or remix that has all of defaults _you_ want.

So FESCo has decided and there is no point of discussing this Change, that is
how it will be and any resistance is futile? The subject even says it is
a "Change _proposal_".

Some replies also do not like this change, I am not alone. Still it looks like
there area really more votes for this change than against it. Fine with me.

BTW this change (contrary to other ones I mentioned) is not such a problem as
it is overridable in $HOME/.bashrc so it does not really need a distro spin.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote:
> I agree with your points, but pressing ESC only reverses the "rhgb" part,
> the kernel output is still "quiet".

If the kernel really locks up it is locked up and no keys work anymore.
Without "rhgb quiet" one can make a photo of the screen.

A better solution would be to use serial console all the time but the ethernet
one does not work during crashes and physical serial hardware is no longer
available in modern computers.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 12:30 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote:

I agree with your points, but pressing ESC only reverses the "rhgb" part,
the kernel output is still "quiet".


If the kernel really locks up it is locked up and no keys work anymore.
Without "rhgb quiet" one can make a photo of the screen.


Is this something that happens to you often?  The only very rare times 
that I've had to deal with this, it's been a consistent lockup, so I 
just need to remove the "quiet" on the next boot.  No need to be spammed 
for the 99.999% of boots that have no problem.  That's a terrible thing 
for users to see.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 12:27 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:

But, if you don't like our offerings that are targetted that way, I suggest
you make a spin or remix that has all of defaults _you_ want.


So FESCo has decided and there is no point of discussing this Change, that is
how it will be and any resistance is futile? The subject even says it is
a "Change _proposal_".

Some replies also do not like this change, I am not alone. Still it looks like
there area really more votes for this change than against it. Fine with me.


From all the replies here, yours is the only one I've seen that's 
really against it.



BTW this change (contrary to other ones I mentioned) is not such a problem as
it is overridable in $HOME/.bashrc so it does not really need a distro spin.


It's even easier than that.  If you read the details, there will be a 
specific package that you can uninstall to remove the config.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 12:20 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote:

3. provides a handy reference of key combos you can use to get help,
save the file, and exit. Yes, you have to know that ^O means "ctrl+O",
but figuring that out is a lot easier than working out how to drive vi
from scratch.


After starting 'vi' there is:
~type  :help  orfor on-line help


That's only if you start vi without a file.  Otherwise, you just get the 
text of the file on the screen and the bottom line with the filename and 
cursor position.  No info at all about what just happened.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
> But regardless, that's something to fix in the dnf bash completion scripts,
> not a reason to completely disable completion as the earlier poster said.

TL;DR it regresses the original bash completion feature.

This will be always a catch up play. To make it working each completion script
would need to be part of the package it is implementing completion for.
Additionally it would need to be integrated into the program's commandline
parsing as otherwise it will never be 100% matching. There were efforts to
unify commandline parsing between programs but that never happened:
GNU getopt_long, glib GOption, 
https://en.wikipedia.org/wiki/Getopt#In_other_languages

I have shown just 'dnf' but if you really want I can find arbitrary number of
other such programs and bugs where the completion script implements things
differently than the program itself.

This is why IMHO bash-completion is only an experimental unfinished feature
and it should not be the default.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote:
> On 6/26/20 12:27 AM, Jan Kratochvil wrote:
> > Some replies also do not like this change, I am not alone. Still it looks 
> > like
> > there area really more votes for this change than against it. Fine with me.
> 
> From all the replies here, yours is the only one I've seen that's really
> against it.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6OPZA57OBV3FPJPGNRYWBROL3WR2B4NG/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 09:36:05 +0200, Samuel Sieb wrote:
> Is this something that happens to you often?

It was happening often on an Athlon computer which I retired recently.
So no longer.

Or rather it still happens for me (X1 carbon 6th with docking station) but
during switching to X when the screen remains black even when I am not using
"rhgb quiet".


> No need to be spammed for the 99.999%
> of boots that have no problem.  That's a terrible thing for users to see.

I feel blind when I do not see what is happening and I feel scared it will
lock up again and I will be unable to debug it. Besides that it is much more
pretty to see what is happening and it makes the waiting time shorter.

All pros and no con. Yes, it is a personal preference. Yes, I understand most
of computer users prefer "rhgb quiet". I have some doubts most of _Fedora_
users really prefer it.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 12:42 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:

But regardless, that's something to fix in the dnf bash completion scripts,
not a reason to completely disable completion as the earlier poster said.


TL;DR it regresses the original bash completion feature.

This will be always a catch up play. To make it working each completion script
would need to be part of the package it is implementing completion for.
Additionally it would need to be integrated into the program's commandline
parsing as otherwise it will never be 100% matching. There were efforts to


I have no idea what you're talking about.  The bash completion scripts 
are generally supplied by the package that they are for:

# rpm -qf /usr/share/bash-completion/completions/dnf
dnf-4.2.21-1.fc31.noarch


I have shown just 'dnf' but if you really want I can find arbitrary number of
other such programs and bugs where the completion script implements things
differently than the program itself.


The dnf one works fine.  But if you don't like how specific ones work, 
then file bugs.



This is why IMHO bash-completion is only an experimental unfinished feature
and it should not be the default.


It's a very useful feature for most people.  If you don't like it, then 
uninstall it.


Btw, in the case of dnf or similar situations, you can force file 
completion by pressing ALT-/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 03:40, Sergio Belkin  wrote:
>
> Well, I strongy disagree whit this move.
> In fact on of the things that I hate of Debian/Ubuntu is the choice of nano 
> and the poor version that they offer by default of vi.
> More friendly for end-users? Really?
> Please thinking so, the end-user use GUI's. Nano has no any significative 
> advantage over vi and even lesser over vim. What's the wrong with vim? Really 
> I don't understand.
> If one end-user wants to use a text editor, he will find kate, gedit and the 
> like better options.

Your argument works best the other way around: if a developer wants to
use another text editor, they'll know the options, they'll know how to
change it much better than an end-user.

As a vim user for many years, my +1000 to this change proposal.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote:
> That's only if you start vi without a file.  Otherwise, you just get the
> text of the file on the screen and the bottom line with the filename and
> cursor position.  No info at all about what just happened.

OK, I agree. So what about instead of nano to do:

cat >>~/.vimrc <:x\'\ to\ save\ 
file,\ \':q!\'\ to\ quit.
EOH

It is the most user friendly solution (plus the system still remains to be
a UNIX!).


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Leigh Scott]

> https://fedoraproject.org/wiki/Changes/UseNanoByDefault

> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to, and therefore doesn't require specialist
> knowledge to use. It is already installed across most Fedora Editions
> and Spins. This proposal will make Nano the default editor, while
> continuing to install vim-minimal (which provides vi, but
> not Vim). People will still be able to call vi if they
> want to edit a file. It will also obviously be possible to change the
> default editor to vi or Vim, for those who want it.
> 

Please don't make this universal for all the spins, it should be optional.
TBH I don't give a damn if you do it to the workstation spin, please keep your 
grubby hands off the cinnamon spin :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 12:44 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote:

On 6/26/20 12:27 AM, Jan Kratochvil wrote:

Some replies also do not like this change, I am not alone. Still it looks like
there area really more votes for this change than against it. Fine with me.


 From all the replies here, yours is the only one I've seen that's really
against it.


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6OPZA57OBV3FPJPGNRYWBROL3WR2B4NG/


That was a pretty mild one, but yes, I see there was another much 
stronger one against it.  But still, there are far more that approve of 
this change, even the vim users.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/26/20 1:13 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote:

That's only if you start vi without a file.  Otherwise, you just get the
text of the file on the screen and the bottom line with the filename and
cursor position.  No info at all about what just happened.


OK, I agree. So what about instead of nano to do:

cat >>~/.vimrc <:x\'\ to\ save\ file,\ 
\':q!\'\ to\ quit.
EOH

It is the most user friendly solution (plus the system still remains to be
a UNIX!).


If you're going to say that you have to use vim for it to be unix, 
you're going to start another war with the emacs users. :-)


The most user friendly solution is to have nano by default with a very 
easy way to revert to vim for anyone that knows what they are doing.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 09:50, Jan Kratochvil  wrote:
>
> On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
> > But regardless, that's something to fix in the dnf bash completion scripts,
> > not a reason to completely disable completion as the earlier poster said.
>
> TL;DR it regresses the original bash completion feature.
>
> This will be always a catch up play. To make it working each completion script
> would need to be part of the package it is implementing completion for.
> Additionally it would need to be integrated into the program's commandline
> parsing as otherwise it will never be 100% matching. There were efforts to
> unify commandline parsing between programs but that never happened:
> GNU getopt_long, glib GOption, 
> https://en.wikipedia.org/wiki/Getopt#In_other_languages
>
> I have shown just 'dnf' but if you really want I can find arbitrary number of
> other such programs and bugs where the completion script implements things
> differently than the program itself.
>
> This is why IMHO bash-completion is only an experimental unfinished feature
> and it should not be the default.

This is completely off-topic. But anyway, try sending messages over
D-Bus using dbus-send. Then try using busctl with bash-completion, and
you tell me which one you prefer. Are there some quirks and issues? Of
course. Sometimes annoying, such as the dnf example. But also
solvable, as the dnf example with ./, as someone pointed out. And
overall it's muuuch much more useful than annoying, and for some tools
you simply cannot do any useful work without it (see my initial
example).

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
> On 6/26/20 12:42 AM, Jan Kratochvil wrote:
> > This will be always a catch up play. To make it working each completion 
> > script
> > would need to be part of the package it is implementing completion for.
> > Additionally it would need to be integrated into the program's commandline
> > parsing as otherwise it will never be 100% matching. There were efforts to
> 
> I have no idea what you're talking about.  The bash completion scripts are
> generally supplied by the package that they are for:
> # rpm -qf /usr/share/bash-completion/completions/dnf
> dnf-4.2.21-1.fc31.noarch

$ rpm -qlp bash-completion-2.8-8.fc32.noarch.rpm|grep 
^/usr/share/bash-completion/completions/|wc -l
652


> The dnf one works fine.

It does not as I have shown. Moreover it takes so much time to do dnf command
completion and one always has to ctrl-c it anyway. That is because dnf should
use cached results updated by cron and do not contact network during
interactive cache queries. If one really wants most fresh data there is
--refresh for that.


> But if you don't like how specific ones work, then file bugs.

The bug is bash-completion itself, I do not see what does it try to solve, the
best fix is just to remove it.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 10:20, Leigh Scott  wrote:
>
> Please don't make this universal for all the spins, it should be optional.
> TBH I don't give a damn if you do it to the workstation spin, please keep 
> your grubby hands off the cinnamon spin :-)

That escalated quickly. :)

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jan Kratochvil]

On Fri, 26 Jun 2020 10:23:31 +0200, Iñaki Ucar wrote:
> On Fri, 26 Jun 2020 at 10:20, Leigh Scott  wrote:
> > Please don't make this universal for all the spins, it should be optional.
> > TBH I don't give a damn if you do it to the workstation spin, please keep 
> > your grubby hands off the cinnamon spin :-)
> 
> That escalated quickly. :)

And MATE and XFCE spin. Maybe it really matches best the user base?


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Panu Matilainen]

On 6/26/20 4:30 AM, Sergio Belkin wrote:


Well, I strongy disagree whit this move.
In fact on of the things that I hate of Debian/Ubuntu is the choice of 
nano and the poor version that they offer by default of vi.

More friendly for end-users? Really?
Please thinking so, the end-user use GUI's. Nano has no any 
significative advantage over vi and even lesser over vim. What's the 
wrong with vim? Really I don't understand.


For the uninitiated, nano has the very distinctive benefit over vi(m) 
that you have prayer of a chance of successfully making changes and 
exiting the thing gracefully ;)


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Robinson]

On Fri, Jun 26, 2020 at 9:14 AM Leigh Scott  wrote:
>
> > https://fedoraproject.org/wiki/Changes/UseNanoByDefault
>
> > In contrast, Nano offers the kind of graphical text editing experience
> > that people are used to, and therefore doesn't require specialist
> > knowledge to use. It is already installed across most Fedora Editions
> > and Spins. This proposal will make Nano the default editor, while
> > continuing to install vim-minimal (which provides vi, but
> > not Vim). People will still be able to call vi if they
> > want to edit a file. It will also obviously be possible to change the
> > default editor to vi or Vim, for those who want it.
> >
>
> Please don't make this universal for all the spins, it should be optional.
> TBH I don't give a damn if you do it to the workstation spin, please keep 
> your grubby hands off the cinnamon spin :-)

If it's set as a default across the distribution there's nothing
stopping the cinnamon spin changing it for them.

One thing that's required of all spin maintainers, and everyone else,
is to be nice, there's no need to describe people as grubby.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bundled compiler conundrum

[Vitaly Zaitsev via devel]

On 26.06.2020 05:01, Michael Cronenworth wrote:
> I know bundled libraries are allowed, but what about bundled compilers?

Pre-compiled binaries are strictly forbidden by Fedora guidelines. All
binaries must be built on Fedora infra.

If you have cyclic dependencies, you should use bootstrapping[1].

[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Robinson]

On Fri, Jun 26, 2020 at 8:30 AM Jan Kratochvil
 wrote:
>
> On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
> > But, if you don't like our offerings that are targetted that way, I suggest
> > you make a spin or remix that has all of defaults _you_ want.
>
> So FESCo has decided and there is no point of discussing this Change, that is
> how it will be and any resistance is futile? The subject even says it is
> a "Change _proposal_".

I don't see where Matthew suggested that FESCo was being subverted in
that reply. The process for changes is they're sent to the list for
discussion, and that's what's happening right now, and then FESCo
allegedly takes this discussion into account when they vote for the
feature in a (I think it's 2 weeks) meeting post the allotted time.
Matthew was simply pointing out that if you don't like the change
there's alternative options you can follow by making the vim4EVAH
Fedora spin or remix or what ever you like!

> Some replies also do not like this change, I am not alone. Still it looks like
> there area really more votes for this change than against it. Fine with me.

And I see a lot of replies that are very positive for the change.

> BTW this change (contrary to other ones I mentioned) is not such a problem as
> it is overridable in $HOME/.bashrc so it does not really need a distro spin.

There's numerous ways to change the default editor, this is purely for
the default so new users have a more positive experience. While I am
personally a vim user I can fully understand the change. I'm sure
regular vim users can work out how to change the default back, emacs
users are unaffected, they're use to having to change the default ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Robinson]

> > I agree with your points, but pressing ESC only reverses the "rhgb" part,
> > the kernel output is still "quiet".
>
> If the kernel really locks up it is locked up and no keys work anymore.
> Without "rhgb quiet" one can make a photo of the screen.
>
> A better solution would be to use serial console all the time but the ethernet
> one does not work during crashes and physical serial hardware is no longer
> available in modern computers.

While I use a serial console all the time, after all low level Arm
early boot process practically mandates it, I don't see what this has
to do with this thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Kamil Dudka]

On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
> On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:
> > ...snip...
> > 
> > Gentoo Linux uses the /etc/env.d tree to globally set environment
> > 
> > variables:
> > https://devmanual.gentoo.org/tasks-reference/environment/index.html
> > 
> > It worked there long time before systemd was invented.  But clearing this
> > up in Fedora would ask for a separate system-wide change I guess...
> > 
> > Kamil
> 
> Isn't /etc/profile.d more inline with the FHS though?

Could you please provide any reference?

> The FHS calls out
> /etc/profile as being the "systemwide initialization file for sh shell
> logins," so the profile.d directory would be the natural extension to that.
> I don't see a mention of an env or evn.d in the FHS at all.

I see no mention of profile.d in FHS 3.0 either.

Kamil

> -Ian

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vitaly Zaitsev via devel]

On 25.06.2020 20:50, Jan Kratochvil wrote:
> setenforce 0

Do not disable SELinux! Configure it.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vitaly Zaitsev via devel]

On 25.06.2020 23:38, Jan Kratochvil wrote:
> $ dnf install som
> 

dnf install ./som

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ian McInerney]

On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka  wrote:

> On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
> > On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:
> > > ...snip...
> > >
> > > Gentoo Linux uses the /etc/env.d tree to globally set environment
> > >
> > > variables:
> > >
> https://devmanual.gentoo.org/tasks-reference/environment/index.html
> > >
> > > It worked there long time before systemd was invented.  But clearing
> this
> > > up in Fedora would ask for a separate system-wide change I guess...
> > >
> > > Kamil
> >
> > Isn't /etc/profile.d more inline with the FHS though?
>
> Could you please provide any reference?
>

As I mentioned, the FHS calls out the "profile" file in /etc as being the
"Systemwide initialization file for sh shell logins" [1]. While not in the
FHS, it is custom to append ".d" to directories containing multiple
configuration files to parse (as you have even suggested with env.d). That
is why I said it would be /more inline/ with the FHS (I never said it was
in the FHS currently), since it would then gather the files used by the
"profile" script into the directory "profile.d".


> The FHS calls out
> > /etc/profile as being the "systemwide initialization file for sh shell
> > logins," so the profile.d directory would be the natural extension to
> that.
> > I don't see a mention of an env or evn.d in the FHS at all.
>
> I see no mention of profile.d in FHS 3.0 either.


 But there is no mention of an "env" file that is a systemwide environment
file either. So where does the initial "env" name fit into the FHS better
than the "profile" name?

-Ian

[1]
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSystemConfiguration
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Alejandro Saez Morollon]

If the only case is git... which by the way behaves in that way even
on Windows... isn't it a git problem?
I like not having a default editor and a more user-friendly approach
would be to ask the user what they want on the installation or on the
first run.

I don't consider git a layman application, neither open a terminal to do stuff.

On Thu, Jun 25, 2020 at 7:20 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
>
> == Summary ==
>
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.
>
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email:  chrismur...@fedoraproject.org
>
>
> == Detailed Description ==
>
> Users are exposed to the default editor when they use commands that
> call it. The main example here is something like git
> commit.
>
> Fedora does not currently have a default terminal text editor, because
> the $EDITOR environment variable is unset by default. But a common
> scenario where users wind up in a terminal text editor is when using
> 'git commit'. By default, git picks vi. You need to spend time
> learning how to use it, for even basic editing tasks. This increases
> the barrier to entry for those who are switching to Fedora and don't
> know how to use vi. It also makes things hard for those who don't
> particularly want to learn how to use vi. (These arguments would apply
> just as well if git picked Vim. vi is like hard mode for Vim, with
> fewer features, missing syntax highlighting, and no indication of what
> mode you are in. Even Vim users may feel lost and bewildered when
> using vi.)
>
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to, and therefore doesn't require specialist
> knowledge to use. It is already installed across most Fedora Editions
> and Spins. This proposal will make Nano the default editor, while
> continuing to install vim-minimal (which provides vi, but
> not Vim). People will still be able to call vi if they
> want to edit a file. It will also obviously be possible to change the
> default editor to vi or Vim, for those who want it.
>
> Why make Nano default and vi optional, rather than the other way
> round? Because Nano is the option that everyone can use.
>
> == Feedback ==
>
> Pending ...
>
> == Benefit to Fedora ==
>
> * Makes the default editor across all of Fedora more approachable.
> * Nano is also mostly self-documenting, by displaying common keyboard
> shortcuts on-screen.
> * More in line with the default editor of other distributions.
>
> == Scope ==
> * Proposal owners:
> ** Modify comps to include nano Fedora wide.
> ** Create a new subpackage of nano, called
> nano-editor.
> ** nano-editor to include
> /usr/lib/environment.d/10-nano.conf, which sets
> $EDITOR to nano.
>
> With this approach, if nano is uninstalled, the
> configuration will be removed with it. At the same time, installing
> nano on its own won't install the conf.
>
> * Other developers: N/A
>
> * Release engineering: [https://pagure.io/releng/issue/9522 #9522]
>
> * Policies and guidelines: N/A
>
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
>
> Will not apply to upgrades.
>
> == How To Test ==
>
> Run export EDITOR="/usr/bin/nano".
>
> == User Experience ==
>
> Users running git commit will be able to just type their
> commit message, rather than having to learn about insert mode, and
> they'll be able to cut and paste without having to learn special
> shortcuts.
>
> == Dependencies ==
>
> No additional dependencies are required.
>
> == Contingency Plan ==
> The contingency plan is to revert the change by removing the
> nano-editor package.
>
> * Contingency deadline: probably the beta? It's an easy change to revert.
> * Blocks release? If the change breaks the redirection to an editor,
> it should block the release. However, this is unlikely.
> * Blocks product? Potentially all.
>
> == Documentation ==
> As part of this change, it would be good to add instructions for
> changing the default editor to the
> [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fe

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ian McInerney]

>
>
> If the only case is git... which by the way behaves in that way even
> on Windows... isn't it a git problem?
> I like not having a default editor and a more user-friendly approach
> would be to ask the user what they want on the installation or on the
> first run.
>
>
git is not the only program that uses the EDITOR variable. Some
configuration tools on the command-line, such as crontab, will use the
editor set in the environment variable if there is one.

-Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Kamil Dudka]

On Friday, June 26, 2020 12:07:46 PM CEST Ian McInerney wrote:
> On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka  wrote:
> > On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
> > > On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:
> > > > ...snip...
> > > > 
> > > > Gentoo Linux uses the /etc/env.d tree to globally set environment
> > 
> > > > variables:
> > https://devmanual.gentoo.org/tasks-reference/environment/index.html
> > 
> > > > It worked there long time before systemd was invented.  But clearing
> > 
> > this
> > 
> > > > up in Fedora would ask for a separate system-wide change I guess...
> > > > 
> > > > Kamil
> > > 
> > > Isn't /etc/profile.d more inline with the FHS though?
> > 
> > Could you please provide any reference?
> 
> As I mentioned, the FHS calls out the "profile" file in /etc as being the
> "Systemwide initialization file for sh shell logins" [1].

/etc/profile may in general contain arbitrary shell code that conditionally 
sources other configuration files etc. whereas /etc/env.d on Gentoo is used 
solely to initialize environment variables.

> While not in the
> FHS, it is custom to append ".d" to directories containing multiple
> configuration files to parse (as you have even suggested with env.d).

I did not suggest it for Fedora really.  I just mentioned that the problem 
that _this_ change proposal is facing was already solved in another distro
10+ years ago.

> That
> is why I said it would be /more inline/ with the FHS (I never said it was
> in the FHS currently), since it would then gather the files used by the
> "profile" script into the directory "profile.d".

That is what you say.  But the specification itself does not say it at all.

Kamil

> > The FHS calls out
> > 
> > > /etc/profile as being the "systemwide initialization file for sh shell
> > > logins," so the profile.d directory would be the natural extension to
> > 
> > that.
> > 
> > > I don't see a mention of an env or evn.d in the FHS at all.
> > 
> > I see no mention of profile.d in FHS 3.0 either.
> 
>  But there is no mention of an "env" file that is a systemwide environment
> file either. So where does the initial "env" name fit into the FHS better
> than the "profile" name?
> 
> -Ian
> 
> [1]
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSys
> temConfiguration

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Alejandro Saez Morollon]

100% true. That would be a nice addition to the proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi too eager to push updates to stable?

[Tomasz Torcz]

On Thu, Jun 25, 2020 at 11:21:57AM -0700, Adam Williamson wrote:
> On Thu, 2020-06-25 at 20:18 +0200, Tomasz Torcz wrote:
> > On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> > > Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> > > if doesn't get negative karma, it gets pushed - no matter if it's an
> > > enhancement, or a bugfix, or a security update.
> > 
> >   I don't think so. I remember my updates sitting in testing for weeks.
> > Not that I find it worrisome. If my package is so niche that no one tests
> > it, then no one will be impacted if the update is now or month later.
> 
> It hasn't "always" been like this, it was added I think two or three
> years back, in response to one of the periodic long arguments about
> whether the rules and defaults are too strict or not strict enough.

  Thanks for all the explanations, it's clear to me now.

  For the record, this feature was added a year ago:
  https://pagure.io/fesco/issue/2048
  https://github.com/fedora-infra/bodhi/pull/3090


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Christopher Engelhard]

On 26.06.20 12:20, Ian McInerney wrote:

> git is not the only program that uses the EDITOR variable. Some
> configuration tools on the command-line, such as crontab, will use the
> editor set in the environment variable if there is one.

visudo is also a good spot for a beginner to be stuck in vi.

Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Leigh Scott]

> On Fri, Jun 26, 2020 at 9:14 AM Leigh Scott  wrote:
> 
> If it's set as a default across the distribution there's nothing
> stopping the cinnamon spin changing it for them.
> 
> One thing that's required of all spin maintainers, and everyone else,
> is to be nice, there's no need to describe people as grubby.

Maybe you should learn the meaning before launching an attack!

https://www.ldoceonline.com/dictionary/grubby-hands-paws-mitts#:~:text=From%20Longman%20Dictionary%20of%20Contemporary,your%20grubby%20paws%20to%20yourself!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Alejandro Saez Morollon]

Also true. Although visudo is probably not a good example because the
command itself warns you haha :),

Nevertheless, I still think that the user-friendly approach here is to
ask the users what they want, not to impose something.

On Fri, Jun 26, 2020 at 12:35 PM Christopher Engelhard  wrote:
>
> On 26.06.20 12:20, Ian McInerney wrote:
>
> > git is not the only program that uses the EDITOR variable. Some
> > configuration tools on the command-line, such as crontab, will use the
> > editor set in the environment variable if there is one.
>
> visudo is also a good spot for a beginner to be stuck in vi.
>
> Christopher
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jaroslav Skarvada]

- Original Message -
> El jue., 25 jun. 2020 a las 21:45, Qiyu Yan (< yanq...@fedoraproject.org >)
> escribió:
> 
> 
> What about to provide a prompt to the user telling them the difference
> between editors?
> For example, when a new user to fedora first invokes git commit
> without $EDITOR set, a program named fedora-default-editor comes up
> and asks: Which editor do you like?
> User can do his or hers choice and the choice will be remembered by
> setting $EDITOR in his or hers ~/.bashrc
> 
> The fedora-default-editor can be a small script that shows user all
> the difference and set $EDITOR for the user.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> Well, I strongy disagree whit this move.
> In fact on of the things that I hate of Debian/Ubuntu is the choice of nano
> and the poor version that they offer by default of vi.
> More friendly for end-users? Really?
> Please thinking so, the end-user use GUI's. Nano has no any significative
> advantage over vi and even lesser over vim. What's the wrong with vim?
> Really I don't understand.
> If one end-user wants to use a text editor, he will find kate, gedit and the
> like better options. If you don't like a modal editor, propose a better
> option not a mediocre one. For example, micro is a non-modal editor but more
> powerful that nano.
> If has no real benefit, please could you reconsider it and let the community
> give his voice?
> Thanks in advance.
> SB
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-1 for the change. If the so called 'end-user' (whatever does it mean)
can learn git, she or he can also learn 'vi' or at least how to enable
the preferred editor. Personally, I can see nothing special on the
nano, for me it qualifies as very poor editor

thanks & regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ankur Sinha]

On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
> On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> > I'm not sure why you think end-users can't use a free OS.
> 
> First steps of end-users is to install Chrome, Spotify and VirtualBox.
> So there is left no advantage of a Free OS.

That's anecdotal generalisation at best. I know enough people to
disprove this statement using my set of anecdotal evidence---and it
won't get us any where.

We are a FOSS community and we will keep promoting FOSS as much as
we can. It is our First Foundation:
https://docs.fedoraproject.org/en-US/project/

So, let's keep the discussion on topic: about the default editor.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vitaly Zaitsev via devel]

On 25.06.2020 19:18, Ben Cotton wrote:
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.

-1 for this change. Vi is much better than nano.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vitaly Zaitsev via devel]

On 26.06.2020 12:34, Christopher Engelhard wrote:
> visudo is also a good spot for a beginner to be stuck in vi.

Use sudoedit instead.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 00:57 -0700, Samuel Sieb wrote:

On 6/26/20 12:42 AM, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:

But regardless, that's something to fix in the dnf bash completion scripts,
not a reason to completely disable completion as the earlier poster said.


TL;DR it regresses the original bash completion feature.

This will be always a catch up play. To make it working each completion script
would need to be part of the package it is implementing completion for.
Additionally it would need to be integrated into the program's commandline
parsing as otherwise it will never be 100% matching. There were efforts to


I have no idea what you're talking about.  The bash completion scripts 
are generally supplied by the package that they are for:

# rpm -qf /usr/share/bash-completion/completions/dnf
dnf-4.2.21-1.fc31.noarch


I have shown just 'dnf' but if you really want I can find arbitrary number of
other such programs and bugs where the completion script implements things
differently than the program itself.


The dnf one works fine.  But if you don't like how specific ones work, 
then file bugs.


Right, poor completion experiences are just bugs, and can be fixed,
e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=1398373
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 10:19 +0200, Jan Kratochvil wrote:

On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:

The dnf one works fine.


It does not as I have shown. Moreover it takes so much time to do dnf command
completion and one always has to ctrl-c it anyway. That is because dnf should
use cached results updated by cron and do not contact network during
interactive cache queries. If one really wants most fresh data there is
--refresh for that.


That sounds like a good idea, and could be filed as a bug against
dnf. I'd prefer if it's optional though, because for me 'sudo dnf
install foo' only takes seven seconds, not minutes, and
that seems reasonable to me.


But if you don't like how specific ones work, then file bugs.


The bug is bash-completion itself, I do not see what does it try to solve, the
best fix is just to remove it.


And you have that choice. Please don't claim to speak for all
developers when you say the entire package is a bug or makes Fedora
hostile to developers.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Qiyu Yan]

Adam Williamson  于 2020年6月26日周五 上午9:32写道：

> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> > What about to provide a prompt to the user telling them the difference
> > between editors?
> > For example, when a new user to fedora first invokes git commit
> > without $EDITOR set, a program named fedora-default-editor comes up
> > and asks: Which editor do you like?
> > User can do his or hers choice and the choice will be remembered by
> > setting $EDITOR in his or hers ~/.bashrc
> >
> > The fedora-default-editor can be a small script that shows user all
> > the difference and set $EDITOR for the user.
>
> It's a nice idea, but the problem with things like this is they
> *always* introduce bugs, and often wind up being unmaintained, because
> keeping them working is kind of a thankless task.
>
> IMHO it's better to keep things simple and just pick a default. And the
> default should definitely be nano. :D
>
Then I will +1 for this proposal. Yes, this certainly will make Fedora
easier use for beginners. And for those who would like to use vi as
default, we should make this as easy as possible.

I has been asked "how to exit this hell?" multiple times by my new-to-Linux
friends, that time I would always suggest them to set nano as default. Vim
is great though, it is not for beginners.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[David Kaufmann]

On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:
> The most user friendly solution is to have nano by default with a very easy
> way to revert to vim for anyone that knows what they are doing.

No, it is not. It is user friendly to the users only using the command
line a few times or the users who prefer nano.

For users having to edit files on a lot of different systems this is
actually harmful and leads to bad behavior.

On a lot of systems I manage new users don't get a default shell - which
is reasonable for service users - which led to the behavior that I only
edit files as root - I think the reason is that switching to a service
user ends up in /bin/sh and tab completion often does not work anymore.

Maybe it is an option to limit this change to Fedora Workstation and
non-root accounts only? Or even better to put it as default only for
users created via GUI?
This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc
from /etc/skel.

I'm fine with configuring it on my machine, but as I administer a lot of
machines (both Workstation and Server) I think the default for admins
should stay vi.

So it is a -1 from me for the current variant of the proposal.

All the best,
David


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Mauricio Tavares]

I am reading this thread and seeing a lot of "this will make it easy
on end users" and "this will piss developers off." How many?  Who?
Without data to back those statements they are just examples of
hyperbole built upon personal beliefs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[David Kirwan]

Is this a vote? If so -1.

Don't pave the jungle, put on some boots!

On Fri, 26 Jun 2020 at 12:33, David Kaufmann  wrote:

> On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:
> > The most user friendly solution is to have nano by default with a very
> easy
> > way to revert to vim for anyone that knows what they are doing.
>
> No, it is not. It is user friendly to the users only using the command
> line a few times or the users who prefer nano.
>
> For users having to edit files on a lot of different systems this is
> actually harmful and leads to bad behavior.
>
> On a lot of systems I manage new users don't get a default shell - which
> is reasonable for service users - which led to the behavior that I only
> edit files as root - I think the reason is that switching to a service
> user ends up in /bin/sh and tab completion often does not work anymore.
>
> Maybe it is an option to limit this change to Fedora Workstation and
> non-root accounts only? Or even better to put it as default only for
> users created via GUI?
> This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc
> from /etc/skel.
>
> I'm fine with configuring it on my machine, but as I administer a lot of
> machines (both Workstation and Server) I think the default for admins
> should stay vi.
>
> So it is a -1 from me for the current variant of the proposal.
>
> All the best,
> David
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
David Kirwan
Software Engineer

Community Platform Engineering @ Red Hat

T: +(353) 86-8624108 IM: @dkirwan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Sergio Belkin]

El vie., 26 jun. 2020 a las 8:10, Ankur Sinha ()
escribió:

> On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
> > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> > > I'm not sure why you think end-users can't use a free OS.
> >
> > First steps of end-users is to install Chrome, Spotify and VirtualBox.
> > So there is left no advantage of a Free OS.
>
> That's anecdotal generalisation at best. I know enough people to
> disprove this statement using my set of anecdotal evidence---and it
> won't get us any where.
>
> We are a FOSS community and we will keep promoting FOSS as much as
> we can. It is our First Foundation:
> https://docs.fedoraproject.org/en-US/project/
>
> So, let's keep the discussion on topic: about the default editor.
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

Again, I'm not against the proposal, but I would prefer a better and sane
discussion.
Honestly most end users dislike the CLI.
However I understand that discussion is not about "what is my preferred
editor?".
I understand that discussion is "if by chance an end user has to use CLI,
he/she will not know what/how to do with vim".
In such a case nano is easier (regardless that the argument about how hard
is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
A better for a newcomer that faces cli would be something like mcedit, but
sadly it is not a standalone editor.
But please, again, most end users prefer to use a gui editor. Is not about
that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about
that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical
environments.


-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Charalampos Stratakis]

+1

I'm all for making the user experience better, and I think this change 
contributes to that.

- Original Message -
> From: "Ben Cotton" 
> To: devel-annou...@lists.fedoraproject.org, "Development discussions related 
> to Fedora"
> 
> Sent: Thursday, June 25, 2020 7:18:59 PM
> Subject: Fedora 33 System-Wide Change proposal: Make nano the default editor
> 
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> 
> == Summary ==
> 
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.
> 
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email:  chrismur...@fedoraproject.org
> 
> 
> == Detailed Description ==
> 
> Users are exposed to the default editor when they use commands that
> call it. The main example here is something like git
> commit.
> 
> Fedora does not currently have a default terminal text editor, because
> the $EDITOR environment variable is unset by default. But a common
> scenario where users wind up in a terminal text editor is when using
> 'git commit'. By default, git picks vi. You need to spend time
> learning how to use it, for even basic editing tasks. This increases
> the barrier to entry for those who are switching to Fedora and don't
> know how to use vi. It also makes things hard for those who don't
> particularly want to learn how to use vi. (These arguments would apply
> just as well if git picked Vim. vi is like hard mode for Vim, with
> fewer features, missing syntax highlighting, and no indication of what
> mode you are in. Even Vim users may feel lost and bewildered when
> using vi.)
> 
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to, and therefore doesn't require specialist
> knowledge to use. It is already installed across most Fedora Editions
> and Spins. This proposal will make Nano the default editor, while
> continuing to install vim-minimal (which provides vi, but
> not Vim). People will still be able to call vi if they
> want to edit a file. It will also obviously be possible to change the
> default editor to vi or Vim, for those who want it.
> 
> Why make Nano default and vi optional, rather than the other way
> round? Because Nano is the option that everyone can use.
> 
> == Feedback ==
> 
> Pending ...
> 
> == Benefit to Fedora ==
> 
> * Makes the default editor across all of Fedora more approachable.
> * Nano is also mostly self-documenting, by displaying common keyboard
> shortcuts on-screen.
> * More in line with the default editor of other distributions.
> 
> == Scope ==
> * Proposal owners:
> ** Modify comps to include nano Fedora wide.
> ** Create a new subpackage of nano, called
> nano-editor.
> ** nano-editor to include
> /usr/lib/environment.d/10-nano.conf, which sets
> $EDITOR to nano.
> 
> With this approach, if nano is uninstalled, the
> configuration will be removed with it. At the same time, installing
> nano on its own won't install the conf.
> 
> * Other developers: N/A
> 
> * Release engineering: [https://pagure.io/releng/issue/9522 #9522]
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> 
> == Upgrade/compatibility impact ==
> 
> Will not apply to upgrades.
> 
> == How To Test ==
> 
> Run export EDITOR="/usr/bin/nano".
> 
> == User Experience ==
> 
> Users running git commit will be able to just type their
> commit message, rather than having to learn about insert mode, and
> they'll be able to cut and paste without having to learn special
> shortcuts.
> 
> == Dependencies ==
> 
> No additional dependencies are required.
> 
> == Contingency Plan ==
> The contingency plan is to revert the change by removing the
> nano-editor package.
> 
> * Contingency deadline: probably the beta? It's an easy change to revert.
> * Blocks release? If the change breaks the redirection to an editor,
> it should block the release. However, this is unlikely.
> * Blocks product? Potentially all.
> 
> == Documentation ==
> As part of this change, it would be good to add instructions for
> changing the default editor to the
> [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
> 
> 
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of 

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vascom]

I think it is good step to user friendly Fedora experience.

+1

пт, 26 июн. 2020 г., 14:45 Charalampos Stratakis :

> +1
>
> I'm all for making the user experience better, and I think this change
> contributes to that.
>
> - Original Message -
> > From: "Ben Cotton" 
> > To: devel-annou...@lists.fedoraproject.org, "Development discussions
> related to Fedora"
> > 
> > Sent: Thursday, June 25, 2020 7:18:59 PM
> > Subject: Fedora 33 System-Wide Change proposal: Make nano the default
> editor
> >
> > https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> >
> > == Summary ==
> >
> > Let's make Fedora more approachable, by having a default editor that
> > doesn't require specialist knowledge to use.
> >
> > == Owner ==
> > * Name: [[User:chrismurphy| Chris Murphy]]
> > * Email:  chrismur...@fedoraproject.org
> >
> >
> > == Detailed Description ==
> >
> > Users are exposed to the default editor when they use commands that
> > call it. The main example here is something like git
> > commit.
> >
> > Fedora does not currently have a default terminal text editor, because
> > the $EDITOR environment variable is unset by default. But a common
> > scenario where users wind up in a terminal text editor is when using
> > 'git commit'. By default, git picks vi. You need to spend time
> > learning how to use it, for even basic editing tasks. This increases
> > the barrier to entry for those who are switching to Fedora and don't
> > know how to use vi. It also makes things hard for those who don't
> > particularly want to learn how to use vi. (These arguments would apply
> > just as well if git picked Vim. vi is like hard mode for Vim, with
> > fewer features, missing syntax highlighting, and no indication of what
> > mode you are in. Even Vim users may feel lost and bewildered when
> > using vi.)
> >
> > In contrast, Nano offers the kind of graphical text editing experience
> > that people are used to, and therefore doesn't require specialist
> > knowledge to use. It is already installed across most Fedora Editions
> > and Spins. This proposal will make Nano the default editor, while
> > continuing to install vim-minimal (which provides vi, but
> > not Vim). People will still be able to call vi if they
> > want to edit a file. It will also obviously be possible to change the
> > default editor to vi or Vim, for those who want it.
> >
> > Why make Nano default and vi optional, rather than the other way
> > round? Because Nano is the option that everyone can use.
> >
> > == Feedback ==
> >
> > Pending ...
> >
> > == Benefit to Fedora ==
> >
> > * Makes the default editor across all of Fedora more approachable.
> > * Nano is also mostly self-documenting, by displaying common keyboard
> > shortcuts on-screen.
> > * More in line with the default editor of other distributions.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Modify comps to include nano Fedora wide.
> > ** Create a new subpackage of nano, called
> > nano-editor.
> > ** nano-editor to include
> > /usr/lib/environment.d/10-nano.conf, which sets
> > $EDITOR to nano.
> >
> > With this approach, if nano is uninstalled, the
> > configuration will be removed with it. At the same time, installing
> > nano on its own won't install the conf.
> >
> > * Other developers: N/A
> >
> > * Release engineering: [https://pagure.io/releng/issue/9522 #9522]
> >
> > * Policies and guidelines: N/A
> >
> > * Trademark approval: N/A
> >
> > == Upgrade/compatibility impact ==
> >
> > Will not apply to upgrades.
> >
> > == How To Test ==
> >
> > Run export EDITOR="/usr/bin/nano".
> >
> > == User Experience ==
> >
> > Users running git commit will be able to just type their
> > commit message, rather than having to learn about insert mode, and
> > they'll be able to cut and paste without having to learn special
> > shortcuts.
> >
> > == Dependencies ==
> >
> > No additional dependencies are required.
> >
> > == Contingency Plan ==
> > The contingency plan is to revert the change by removing the
> > nano-editor package.
> >
> > * Contingency deadline: probably the beta? It's an easy change to revert.
> > * Blocks release? If the change breaks the redirection to an editor,
> > it should block the release. However, this is unlikely.
> > * Blocks product? Potentially all.
> >
> > == Documentation ==
> > As part of this change, it would be good to add instructions for
> > changing the default editor to the
> > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
> >
> >
> > --
> > Ben Cotton
> > He / Him / His
> > Senior Program Manager, Fedora & CentOS Stream
> > Red Hat
> > TZ=America/Indiana/Indianapolis
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> 

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 13:32 +0200, David Kaufmann wrote:

On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:

The most user friendly solution is to have nano by default with a very easy
way to revert to vim for anyone that knows what they are doing.


No, it is not. It is user friendly to the users only using the command
line a few times or the users who prefer nano.

For users having to edit files on a lot of different systems this is
actually harmful and leads to bad behavior.

On a lot of systems I manage new users don't get a default shell - which
is reasonable for service users - which led to the behavior that I only
edit files as root - I think the reason is that switching to a service
user ends up in /bin/sh and tab completion often does not work anymore.

Maybe it is an option to limit this change to Fedora Workstation and
non-root accounts only? Or even better to put it as default only for
users created via GUI?
This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc
from /etc/skel.

I'm fine with configuring it on my machine, but as I administer a lot of
machines (both Workstation and Server) I think the default for admins
should stay vi.


Only doing it for non-root users seems OK to me. Alternatively, just
add EDITOR=vi to root's profile.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Theodore Papadopoulo]

On 6/26/20 1:30 PM, Qiyu Yan wrote:
> 
> 
> Adam Williamson  > 于 2020年6月26日周五 上午9:32写道：
> 
> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> > What about to provide a prompt to the user telling them the difference
> > between editors?
> > For example, when a new user to fedora first invokes git commit
> > without $EDITOR set, a program named fedora-default-editor comes up
> > and asks: Which editor do you like?
> > User can do his or hers choice and the choice will be remembered by
> > setting $EDITOR in his or hers ~/.bashrc
> >
> > The fedora-default-editor can be a small script that shows user all
> > the difference and set $EDITOR for the user.
> 
> It's a nice idea, but the problem with things like this is they
> *always* introduce bugs, and often wind up being unmaintained, because
> keeping them working is kind of a thankless task.
> 
> IMHO it's better to keep things simple and just pick a default. And the
> default should definitely be nano. :D
> 
> Then I will +1 for this proposal. Yes, this certainly will make Fedora
> easier use for beginners. And for those who would like to use vi as
> default, we should make this as easy as possible.

This seems the best approach in my opinion.
I totally agree that having something simple is important for new users.
My only fear (and it applies to any default editor choice) is that the
default will be changed only by a minority of new-users, or after many
months.

Thus having an educational approach which tells the user how to
configure his environment properly (and eventually doing it for him from
a list of choices) seems the most friendly approach.

I must add that nano feels like an old VT100 editor. Not very appealing
to new users (but indeed very clear on how to operate). My guess is that
an average user will hope to see an editor application with icons and
everything to popup (call it notepad and you will fill all his/her
expectations ;-) )... Of course, this will not work in a linux terminal,
but most new users don't even know the concept of a terminal...


0x12BF16AD4F273D5D.asc
Description: application/pgp-keys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1851243] perl-Test-Fake-HTTPD: FTBFS with crypto-policies-20200625-1.gitb298a9e.fc33

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1851243

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|de...@fateyev.com   |ppi...@redhat.com




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 25/06/20 18:48 -0700, Adam Williamson wrote:

On Thu, 2020-06-25 at 22:30 -0300, Sergio Belkin wrote:


Well, I strongy disagree whit this move.
In fact on of the things that I hate of Debian/Ubuntu is the choice of nano
and the poor version that they offer by default of vi.
More friendly for end-users? Really?
Please thinking so, the end-user use GUI's. Nano has no any significative
advantage over vi and even lesser over vim. What's the wrong with vim?
Really I don't understand.
If one end-user wants to use a text editor, he will find kate, gedit and
the like better options. If you don't like a modal editor, propose a better
option not a mediocre one. For example, micro is a non-modal editor but
more powerful that nano.
If has no real benefit, please could you reconsider it and let the
community give his voice?
Thanks in advance.
SB


This isn't about an editor someone *chooses* to use.

It's about that moment quite soon after you start using Linux, when
you're puzzling your way through something at a console, and something
you do triggers the default editor.

If you are unfortunate enough that the default editor is vi, what
happens next is you spend half an hour trying to figure out what the
*hell* is going on, followed by - depending how much you've learned
about Linux so far, and whether you're at a VT or a desktop terminal -
killing or closing the terminal from somewhere else, or just hard
rebooting the system. (I had literally exactly this experience myself,
back in the year 2000 or so.)


Back in 2000 maybe, but these days I'm surprised it can take half an
hour for somebody with **any** unix/linux experience to try Ctrl-C,
and in normal mode that makes vim say:

Type  :qa  and press  to exit Vim
  
  
   0,0-1 All

And if you've somehow got into insert mode and type Ctrl-C Ctrl-C it
says:

Type  :qa!  and press  to abandon all changes and exit Vim   
  
  
   1,0-1 All

That's been there for years, so I think the "stuck in vim" meme is
outdated.


Nothing in vi's default view (if launched with a file, which is what
happens in this case) tells you you need to press 'insert' in order to
actually edit anything. Nothing in vi's default view tells you you have
to type the entirely cryptic sequence ":wq" to save and exit (or gives
you any clue how to exit at all).


Nothing says that if you just sit there staring at it for half an
hour, but Ctrl-C does tell you what to do.


Nothing in vi's default view even
*tells you that what you're looking at is a text editor called vi*.


Yes, the fact you don't even know which editor you're in, so don't
know how to search the web for clues, is the main reason I'm in favour
of the change.

Some actual numbers (from 2017), which are missing from this thread:
https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/

"In the last year, How to exit the Vim editor has made up about .005%
of question traffic: that is, one out of every 20,000 visits to Stack
Overflow questions. That means during peak traffic hours on weekdays,
there are about 80 people per hour that need help getting out of Vim."

And that's Stack Overflow, a website **for developers**, and those
numbers are for people who actually know they're in Vim and know what
to search for!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 14:03 +0200, Theodore Papadopoulo wrote:

On 6/26/20 1:30 PM, Qiyu Yan wrote:



Adam Williamson mailto:adamw...@fedoraproject.org>> 于 2020年6月26日周五 上午9:32写道：

On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> What about to provide a prompt to the user telling them the difference
> between editors?
> For example, when a new user to fedora first invokes git commit
> without $EDITOR set, a program named fedora-default-editor comes up
> and asks: Which editor do you like?
> User can do his or hers choice and the choice will be remembered by
> setting $EDITOR in his or hers ~/.bashrc
>
> The fedora-default-editor can be a small script that shows user all
> the difference and set $EDITOR for the user.

It's a nice idea, but the problem with things like this is they
*always* introduce bugs, and often wind up being unmaintained, because
keeping them working is kind of a thankless task.

IMHO it's better to keep things simple and just pick a default. And the
default should definitely be nano. :D

Then I will +1 for this proposal. Yes, this certainly will make Fedora
easier use for beginners. And for those who would like to use vi as
default, we should make this as easy as possible.


This seems the best approach in my opinion.
I totally agree that having something simple is important for new users.
My only fear (and it applies to any default editor choice) is that the
default will be changed only by a minority of new-users, or after many
months.

Thus having an educational approach which tells the user how to
configure his environment properly (and eventually doing it for him from
a list of choices) seems the most friendly approach.

I must add that nano feels like an old VT100 editor. Not very appealing
to new users (but indeed very clear on how to operate). My guess is that
an average user will hope to see an editor application with icons and
everything to popup (call it notepad and you will fill all his/her
expectations ;-) )... Of course, this will not work in a linux terminal,
but most new users don't even know the concept of a terminal...


Why would $EDITOR even matter if they're not using the terminal?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Sergio Belkin]

> That's been there for years, so I think the "stuck in vim" meme is
> outdated.
>
>
I agree is a funny meme, but even unreal. Sift+zz is not hard that Ctrl-o.
Perhaps vim  needs a footer such as nano :)
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Sergio Belkin]

>
> Why would $EDITOR even matter if they're not using the terminal?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


I agree with you. And it's funny because people that support the use of
nano over vi/vim say "don't talk about personal beliefs" and come to talk
about meme's and how vim is hard to our grandmothers :)

Really do we believe that setting nano as a default editor will attract new
users to Linux? How many end users in last years use Debian because of the
default editor change? A newbie generally does know nothing about vi/vim,
cron, git, etc...
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 09:22 -0300, Sergio Belkin wrote:

Really do we believe that setting nano as a default editor will attract new
users to Linux? How many end users in last years use Debian because of the
default editor change? A newbie generally does know nothing about vi/vim,
cron, git, etc...


The proposal doesn't say it will *attract* new users. I think the
point is to not frustrate users who have already decided to try Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Solomon Peachy]

On Fri, Jun 26, 2020 at 08:39:46AM -0300, Sergio Belkin wrote:
> In such a case nano is easier (regardless that the argument about how hard
> is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).

I disagree, for the simple reason that ^O is discoverable (indeed, it 
and other hotkeys are displayed on-screen) whereas the user has no way 
to know that 'esc-ZZ' is the magic incantation that will get them back 
out.

(Or what to do should they have mashed some keys and got into an edit 
 mode, and don't want to save their changes)

vi is quite powerful, but friendly to n00bs it is very much not.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Zdenek Dohnal  said:
> I'm not sure if which other applications use the default editor, I know
> only git from those. So let's say I will talk about the editor which
> git-commit spawns during committing a change.

There are a variety of CLI tools that use $EDITOR (do any still use
$VISUAL? I still set that out of habit), and usually default to /bin/vi
in the absence of a setting.  On one desktop system, I see about 20
packages that appear like they might be referencing $EDITOR (just
grepping in /usr/bin and /usr/sbin).

I've been using vi/vim for almost 30 years, and have set $EDITOR and
$VISUAL for the whole time.  I honestly didn't realize $EDITOR wasn't
being defaulted to /bin/vi, and we just have programs with their own
arbitrary default.  So I'm definitely +1 to explicitly setting it.

I would go with /etc/profile.d snippets, because that's the most obvious
and historical place (for Red Hat-derived systems at least).
Alternately, the default PAM config loads pam_env, which will look in
/etc/security/pam_env.conf, /etc/environment, and ~/.pam_environment by
default.  There's possibly other things that could be moved here; if
this isn't a good use for it, I don't know what is (why are we loading
pam_env if we aren't going to use it?).

As for the default value of $EDITOR... I don't really care that much,
because I both already set it and already know vi.  But it is quite
obvious that vi is not very user-friendly for the casual/occasional CLI
user (someone following some online directions that include "edit this
config file" for example).  I'd say nano is a little better, as long as
you figure out that ^ is Ctrl.

At under 3MB installed, nano is relatively light-weight (although about
twice as big as vim-minimal :) ).  I would say we should keep
vim-minimal as part of the minimal install, as obviously there are
programs that use it as a default, and it is smaller.

As a system administrator and developer, I can change defaults myself.
These days, I have an Ansible playbook that I run to set up a system to
my preferred liking (used to just be a collection of shell scripts).  I
would assume that developers already set their own defaults for lots of
things, as no two developers can ever seem to agree 100% on how
everything should be done. :)

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Sergio Belkin  said:
> I agree is a funny meme, but even unreal. Sift+zz is not hard that Ctrl-o.
> Perhaps vim  needs a footer such as nano :)

vim does respond to the common ^C invocation with:

Type  :quit  to exit Vim

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 01:27:54PM +0100, Jonathan Wakely wrote:
> On 26/06/20 09:22 -0300, Sergio Belkin wrote:
> > Really do we believe that setting nano as a default editor will attract new
> > users to Linux? How many end users in last years use Debian because of the
> > default editor change? A newbie generally does know nothing about vi/vim,
> > cron, git, etc...
> 
> The proposal doesn't say it will *attract* new users. I think the
> point is to not frustrate users who have already decided to try Fedora.

Do we have real stasitics on this (somthing in the form of bz reports or
comments on a list) indicating that users actually are frustrated with being
confronted with vi unexpectedly?  Given the initially presented use case (having
git-commit or git-rebase pop up vi as the default editor), I'm struggling with
the notion that an individual user is sufficiently skilled to use git on the
command line, yet struggles to find information on the editor git uses by
default.  It seems somewhat inconsistent to me.  Thats not to say its not a real
problem, but it feels a bit like we're taking action on an issue that may not be
a problem, at the expense of existing users that like the environment the way it
is.

Neil (who, in full disclosure, likes vi as the default editor)


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Markus Larsson]

On 26 June 2020 13:39:46 CEST, Sergio Belkin  wrote:
>El vie., 26 jun. 2020 a las 8:10, Ankur Sinha ()
>escribió:
>
>> On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
>> > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
>> > > I'm not sure why you think end-users can't use a free OS.
>> >
>> > First steps of end-users is to install Chrome, Spotify and VirtualBox.
>> > So there is left no advantage of a Free OS.
>>
>> That's anecdotal generalisation at best. I know enough people to
>> disprove this statement using my set of anecdotal evidence---and it
>> won't get us any where.
>>
>> We are a FOSS community and we will keep promoting FOSS as much as
>> we can. It is our First Foundation:
>> https://docs.fedoraproject.org/en-US/project/
>>
>> So, let's keep the discussion on topic: about the default editor.
>>
>> --
>> Thanks,
>> Regards,
>> Ankur Sinha "FranciscoD" (He / Him / His) |
>> https://fedoraproject.org/wiki/User:Ankursinha
>> Time zone: Europe/London
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>Again, I'm not against the proposal, but I would prefer a better and sane
>discussion.
>Honestly most end users dislike the CLI.
>However I understand that discussion is not about "what is my preferred
>editor?".
>I understand that discussion is "if by chance an end user has to use CLI,
>he/she will not know what/how to do with vim".
>In such a case nano is easier (regardless that the argument about how hard
>is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
>A better for a newcomer that faces cli would be something like mcedit, but
>sadly it is not a standalone editor.
>But please, again, most end users prefer to use a gui editor. Is not about
>that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about
>that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical
>environments.
>
>

I think this is more a discussion about target groups. As far as I understand 
Fedora is aimed at everyone end users, devs, sysadmins and others alike.
While I recognize that helping new users onboard is a good thing it seems that 
more often than not it is at the inconvenience of the not new.
This particular issue is very small but part of a trend, it seems. The 
workstation installer, gnome and other seems to be arguing in the same way. The 
needs of new hypothetical users why does not want to learn and/or despises 
having to use a CLI is more important than the needs of the existing userbase.
I think we can find a much better way of being welcoming to new users. One that 
fits those who just wants to edit some text and those who care about what they 
use.
I like to think that I am part of everyone and I would love if we could deliver 
smart solutions that doesn't needlessly change default behaviour under the 
guise "advanced users will know how to configure this".

BR
Markus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Sergio Belkin]

El vie., 26 jun. 2020 a las 9:29, Jonathan Wakely (<
jwak...@fedoraproject.org>) escribió:

> On 26/06/20 09:22 -0300, Sergio Belkin wrote:
> >Really do we believe that setting nano as a default editor will attract
> new
> >users to Linux? How many end users in last years use Debian because of the
> >default editor change? A newbie generally does know nothing about vi/vim,
> >cron, git, etc...
>
> The proposal doesn't say it will *attract* new users.
>

Yes, you'right . The problem is not the proposal itself but the "arguments"
of their supporters :)

-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Tomasz Torcz]

On Fri, Jun 26, 2020 at 12:27:39PM +0100, Jonathan Wakely wrote:
> On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
> > On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
> > > The dnf one works fine.
> > 
> > It does not as I have shown. Moreover it takes so much time to do dnf 
> > command
> > completion and one always has to ctrl-c it anyway. That is because dnf 
> > should
> > use cached results updated by cron and do not contact network during
> > interactive cache queries. If one really wants most fresh data there is
> > --refresh for that.
> 
> That sounds like a good idea, and could be filed as a bug against
> dnf. I'd prefer if it's optional though, because for me 'sudo dnf
> install foo' only takes seven seconds, not minutes, and
> that seems reasonable to me.


  Seven seconds sounds like a horrible user experience. I would lose
patience and start hitting ^C after around 3s.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Solomon Peachy]

On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
> Do we have real stasitics on this (somthing in the form of bz reports or
> comments on a list) indicating that users actually are frustrated with being
> confronted with vi unexpectedly? 

Why would one file a bugzilla ticket over this?  vi, and the system 
default, is working as intended.  "That's just the way Linux is," say 
the folks having to answer "how to quit vi" for the umpteenth time.

> I'm struggling with the notion that an individual user is sufficiently 
> skilled to use git on the command line,

They actually aren't skilled on the cmdline.  At most they'll just 
cut-n-paste something they found on stack overflow.  Instead, GUI git 
frontends are the norm, generally embedded within IDEs.

(FFS most of the folks I work with use the github web frontend to commit 
 things.  Because git is just short for github!)

 - Solomon [who greatly prefers emacs]
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Orcan Ogetbil]

On Fri, 26 Jun 2020 at 04:16, Samuel Sieb wrote:
> If you're going to say that you have to use vim for it to be unix,
> you're going to start another war with the emacs users. :-)

I came here with peace. Let's face it. It's always between the two. I
respect vim and I learned quite some things in vim. But I'm an emacs
user and I find the original decision between vim and emacs for 'git
commit' unfair. The decision made the experience inconsistent with
bash, to begin with (e.g. default bash shortcuts are pretty much
default emacs shortcuts)...

This proposal changes the default to a neutral light-weight editor.
Although the proposal doesn't fix the inconsistency, it's fair for
both sides. +1
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 08:43 -0400, Neil Horman wrote:

On Fri, Jun 26, 2020 at 01:27:54PM +0100, Jonathan Wakely wrote:

On 26/06/20 09:22 -0300, Sergio Belkin wrote:
> Really do we believe that setting nano as a default editor will attract new
> users to Linux? How many end users in last years use Debian because of the
> default editor change? A newbie generally does know nothing about vi/vim,
> cron, git, etc...

The proposal doesn't say it will *attract* new users. I think the
point is to not frustrate users who have already decided to try Fedora.


Do we have real stasitics on this (somthing in the form of bz reports or
comments on a list) indicating that users actually are frustrated with being


Finding/using Bugzilla or a mailing list are apparently almost as
arcane as using vi to many people, even developers.

I can't find any questions about it at ask.fedoraproject.org, but that
probably isn't most people's first place to go for help anyway.


confronted with vi unexpectedly?  Given the initially presented use case (having
git-commit or git-rebase pop up vi as the default editor), I'm struggling with
the notion that an individual user is sufficiently skilled to use git on the
command line, yet struggles to find information on the editor git uses by


There are thousands of "how to use git" pages describing using the
command line TUI. I bet only the better pages think to mention using vi.

Users familiar with version control from another OS might want to try
doing it on the command line in Fedora, and stumble when they get to
the editor step.


default.  It seems somewhat inconsistent to me.  Thats not to say its not a real
problem, but it feels a bit like we're taking action on an issue that may not be
a problem, at the expense of existing users that like the environment the way it
is.


See
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4XS6ZYUO4K3OY46MSJQOLBPEKCXZFAE4/
for actual numbers, to be taken with a large pinch of salt (we have no
way to know how relevant those searches are to Fedora users).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Robert-André Mauchin]

On Monday, 24 February 2020 23:04:26 CEST Ben Cotton wrote:
> In the weekly Fedora program update that I publish on
> communityblog.fedoraproject.org, I have started to include a count of the
> open package review requests. As of this moment, there are ~1300 open
> review requests. Some of these were opened in 2006.
> 
> The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
> excludes review request bugs. Having a large number of open, ancient review
> requests isn't exactly harmful, but it's not very helpful either.
> 
> Before I make a proposal to FPC, I thought I'd open a conversation here.
> What does a reasonable cleanup of review requests look like?
> 
> My initial thought is to close all review requests that were opened >2
> years ago, to be performed at the EOL closure for each release.


Any news on that? Dropping requests on the last comment date, not last 
activity, as some CC/Un-assigning may happen well after the real bug activity.
There is around 500 "old" bugs which are still "New" or Unassigned from my 
Bugzilla searches.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 14:59 +0200, Tomasz Torcz wrote:

On Fri, Jun 26, 2020 at 12:27:39PM +0100, Jonathan Wakely wrote:

On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
> On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
> > The dnf one works fine.
>
> It does not as I have shown. Moreover it takes so much time to do dnf command
> completion and one always has to ctrl-c it anyway. That is because dnf should
> use cached results updated by cron and do not contact network during
> interactive cache queries. If one really wants most fresh data there is
> --refresh for that.

That sounds like a good idea, and could be filed as a bug against
dnf. I'd prefer if it's optional though, because for me 'sudo dnf
install foo' only takes seven seconds, not minutes, and
that seems reasonable to me.



 Seven seconds sounds like a horrible user experience. I would lose
patience and start hitting ^C after around 3s.


It depends what you're trying to do. If you want install something in
the local directory, sure, it's awful. If you really do want dnf to
query the repo and tell you all the packages that match 'foo*' then
it's useful to be able to do that.

It only takes about 3s the second time, so maybe a lot of the time is
getting the results into the disk cache, not the network operation.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Solomon Peachy]

On Fri, Jun 26, 2020 at 12:13:41PM +0200, Alejandro Saez Morollon wrote:
> I like not having a default editor and a more user-friendly approach
> would be to ask the user what they want on the installation or on the
> first run.

Okay, how is this new user supposed to know which editor to pick when 
prompted for the first time?  Will they just pick one at random?

Are you going to limit it to just installed editors, or anything that 
could be snagged via dnf?

I also should point out that this entire discussion seems to be limited 
to console editors.  Why?  Having $EDITOR pointed at, oh, gedit when 
running under X/Wayland could actually be quite useful and consistent 
with the experience they're already used to.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
> On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy  wrote:
> >
> > On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro  
> > wrote:
> > >
> > > On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro
> > >  wrote:
> > > > Yes. I already fixed the wiki page to clarify that we don't need to
> > > > install nano, but I forgot to clarify that we will install
> > > > nano-editor by default.
> > >
> > > BTW maybe nano-editor is not the best name for the subpackage,
> > > considering it will not include the nano text editor, but rather a conf
> > > snippet to set $EDITOR. Any alternative naming proposals?
> >
> > nano-default ?
> 
> We're using zram-generator-defaults for this.
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
> 
> Which is better? default or defaults? I don't have a preference.

I went with "-defaults" in this case because the package provides "the
default configuration", i.e. "defaults".

This doesn't translate exactly to the nano case, which is about making
the program the default "plugin" in another program (git).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neal Gompa]

On Fri, Jun 26, 2020 at 8:35 AM Chris Adams  wrote:
>
> Once upon a time, Zdenek Dohnal  said:
> > I'm not sure if which other applications use the default editor, I know
> > only git from those. So let's say I will talk about the editor which
> > git-commit spawns during committing a change.
>
> There are a variety of CLI tools that use $EDITOR (do any still use
> $VISUAL? I still set that out of habit), and usually default to /bin/vi
> in the absence of a setting.  On one desktop system, I see about 20
> packages that appear like they might be referencing $EDITOR (just
> grepping in /usr/bin and /usr/sbin).
>
> I've been using vi/vim for almost 30 years, and have set $EDITOR and
> $VISUAL for the whole time.  I honestly didn't realize $EDITOR wasn't
> being defaulted to /bin/vi, and we just have programs with their own
> arbitrary default.  So I'm definitely +1 to explicitly setting it.
>
> I would go with /etc/profile.d snippets, because that's the most obvious
> and historical place (for Red Hat-derived systems at least).
> Alternately, the default PAM config loads pam_env, which will look in
> /etc/security/pam_env.conf, /etc/environment, and ~/.pam_environment by
> default.  There's possibly other things that could be moved here; if
> this isn't a good use for it, I don't know what is (why are we loading
> pam_env if we aren't going to use it?).
>

Actually, if we turn on PAM's support for split distro/admin
configuration, we *could* ship this as a pam.d snippet in /usr and
allow the admin to override it in /etc if they wish. This might work
better than profile.d snippets too, since it'd be one file for all the
shells, rather than a bunch of files for every shell.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ben Cotton]

On Fri, Jun 26, 2020 at 9:14 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
> > Which is better? default or defaults? I don't have a preference.
>
> I went with "-defaults" in this case because the package provides "the
> default configuration", i.e. "defaults".
>
> This doesn't translate exactly to the nano case, which is about making
> the program the default "plugin" in another program (git).
>
What about something like "default-editor"? That way it's more obvious
from the name what it actually does. If we later decide to change the
default editor, we update that package (and spins/labs, power users,
etc can exclude that package in kickstarts if they don't want it)



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Mairo P. Rufus]

On Fri Jun 26, 2020 at 9:44 AM WAT, Qiyu Yan wrote:
> What about to provide a prompt to the user telling them the difference
> between editors?
> For example, when a new user to fedora first invokes git commit
> without $EDITOR set, a program named fedora-default-editor comes up
> and asks: Which editor do you like?
> User can do his or hers choice and the choice will be remembered by
> setting $EDITOR in his or hers ~/.bashrc
>
> The fedora-default-editor can be a small script that shows user all
> the difference and set $EDITOR for the user.

+1, but I think it's better to set the variable in ~/.profile to make 
it shell agnostic.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jaroslav Skarvada]

- Original Message -
> 
> 
> Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
> 
> 
> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> > What about to provide a prompt to the user telling them the difference
> > between editors?
> > For example, when a new user to fedora first invokes git commit
> > without $EDITOR set, a program named fedora-default-editor comes up
> > and asks: Which editor do you like?
> > User can do his or hers choice and the choice will be remembered by
> > setting $EDITOR in his or hers ~/.bashrc
> > 
> > The fedora-default-editor can be a small script that shows user all
> > the difference and set $EDITOR for the user.
> 
> It's a nice idea, but the problem with things like this is they
> *always* introduce bugs, and often wind up being unmaintained, because
> keeping them working is kind of a thankless task.
> 
> IMHO it's better to keep things simple and just pick a default. And the
> default should definitely be nano. :D
> Then I will +1 for this proposal. Yes, this certainly will make Fedora easier
> use for beginners. And for those who would like to use vi as default, we
> should make this as easy as possible.
> 
> I has been asked "how to exit this hell?" multiple times by my new-to-Linux
> friends, that time I would always suggest them to set nano as default. Vim
> is great though, it is not for beginners.
> 
Why not just patch vim-minimal to show the hint on the CTRL+C?
Problem solved :)

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 10:44:22AM -, Leigh Scott wrote:
> > One thing that's required of all spin maintainers, and everyone else,
> > is to be nice, there's no need to describe people as grubby.
> Maybe you should learn the meaning before launching an attack!
> https://www.ldoceonline.com/dictionary/grubby-hands-paws-mitts#:~:text=From%20Longman%20Dictionary%20of%20Contemporary,your%20grubby%20paws%20to%20yourself!

Tone doesn't translate well to email. I assume you meant this with a joking,
friendly tone -- but "grubby" is still negative (merriam-webster says
"worthy of contempt"). It's easy for these things to be misread or taken out
of context and better to, yeah, stick to being nice. The negative language
doesn't really add anything even as a joke.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Qiyu Yan]

Jaroslav Skarvada  于2020年6月26日周五 下午9:41写道：
>
>
>
> - Original Message -
> >
> >
> > Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
> >
> >
> > On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> > > What about to provide a prompt to the user telling them the difference
> > > between editors?
> > > For example, when a new user to fedora first invokes git commit
> > > without $EDITOR set, a program named fedora-default-editor comes up
> > > and asks: Which editor do you like?
> > > User can do his or hers choice and the choice will be remembered by
> > > setting $EDITOR in his or hers ~/.bashrc
> > >
> > > The fedora-default-editor can be a small script that shows user all
> > > the difference and set $EDITOR for the user.
> >
> > It's a nice idea, but the problem with things like this is they
> > *always* introduce bugs, and often wind up being unmaintained, because
> > keeping them working is kind of a thankless task.
> >
> > IMHO it's better to keep things simple and just pick a default. And the
> > default should definitely be nano. :D
> > Then I will +1 for this proposal. Yes, this certainly will make Fedora 
> > easier
> > use for beginners. And for those who would like to use vi as default, we
> > should make this as easy as possible.
> >
> > I has been asked "how to exit this hell?" multiple times by my new-to-Linux
> > friends, that time I would always suggest them to set nano as default. Vim
> > is great though, it is not for beginners.
> >
> Why not just patch vim-minimal to show the hint on the CTRL+C?
> Problem solved :)
Ctrl + C in vi will give you a
Type :qa and press  to exit Vim
>
> Jaroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Robinson]

> -1 for the change. If the so called 'end-user' (whatever does it mean)
> can learn git, she or he can also learn 'vi' or at least how to enable
> the preferred editor. Personally, I can see nothing special on the
> nano, for me it qualifies as very poor editor

I feel you're completely missing the point, it's about a straight
foward to understand editor by default so they aren't scared away
before they even learn what an environment variable is, it's not about
being the best most special editor. They may well have learned how to
use git on windows or Mac before moving to Linux. I would flip this
around and say anyone who knows vim enough should know how to change
their default editor.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jaroslav Skarvada]

- Original Message -
> Jaroslav Skarvada  于2020年6月26日周五 下午9:41写道：
> >
> >
> >
> > - Original Message -
> > >
> > >
> > > Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
> > >
> > >
> > > On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> > > > What about to provide a prompt to the user telling them the difference
> > > > between editors?
> > > > For example, when a new user to fedora first invokes git commit
> > > > without $EDITOR set, a program named fedora-default-editor comes up
> > > > and asks: Which editor do you like?
> > > > User can do his or hers choice and the choice will be remembered by
> > > > setting $EDITOR in his or hers ~/.bashrc
> > > >
> > > > The fedora-default-editor can be a small script that shows user all
> > > > the difference and set $EDITOR for the user.
> > >
> > > It's a nice idea, but the problem with things like this is they
> > > *always* introduce bugs, and often wind up being unmaintained, because
> > > keeping them working is kind of a thankless task.
> > >
> > > IMHO it's better to keep things simple and just pick a default. And the
> > > default should definitely be nano. :D
> > > Then I will +1 for this proposal. Yes, this certainly will make Fedora
> > > easier
> > > use for beginners. And for those who would like to use vi as default, we
> > > should make this as easy as possible.
> > >
> > > I has been asked "how to exit this hell?" multiple times by my
> > > new-to-Linux
> > > friends, that time I would always suggest them to set nano as default.
> > > Vim
> > > is great though, it is not for beginners.
> > >
> > Why not just patch vim-minimal to show the hint on the CTRL+C?
> > Problem solved :)
> Ctrl + C in vi will give you a
> Type :qa and press  to exit Vim
> >
Thanks for info, I didn't know :) So I can't see any problem there and
it's just about the personal preference

thanks & regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jaroslav Skarvada]

- Original Message -
> > -1 for the change. If the so called 'end-user' (whatever does it mean)
> > can learn git, she or he can also learn 'vi' or at least how to enable
> > the preferred editor. Personally, I can see nothing special on the
> > nano, for me it qualifies as very poor editor
> 
> I feel you're completely missing the point, it's about a straight
> foward to understand editor by default so they aren't scared away
> before they even learn what an environment variable is, it's not about
> being the best most special editor. They may well have learned how to
> use git on windows or Mac before moving to Linux. I would flip this
> around and say anyone who knows vim enough should know how to change
> their default editor.
>
Yes, of course, but it will cost me time to find out where to revert
the change (the right way).

I just wanted to point out how absurd the arguments in the proposal
are. Somebody using the complex git CLI (which was never meant to be to
highlevel CLI) is usually skilled enough not to be stopped by the
different default editor (especially if the editor gives hints on
wrong usage). Unskilled people will usually use GUI so they do not care

Jaroslav

> Peter
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 02:55:01PM +0100, Peter Robinson wrote:
> I feel you're completely missing the point, it's about a straight
> foward to understand editor by default so they aren't scared away
> before they even learn what an environment variable is, it's not about
> being the best most special editor. They may well have learned how to
> use git on windows or Mac before moving to Linux. I would flip this
> around and say anyone who knows vim enough should know how to change
> their default editor.

And it really isn't just git, although that may the most common tool people
run into it with. "crontab -e" is another example off the top of my head.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Kamil Dudka]

On Friday, June 26, 2020 3:55:01 PM CEST Peter Robinson wrote:
> > -1 for the change. If the so called 'end-user' (whatever does it mean)
> > can learn git, she or he can also learn 'vi' or at least how to enable
> > the preferred editor. Personally, I can see nothing special on the
> > nano, for me it qualifies as very poor editor
> 
> 
> I feel you're completely missing the point, it's about a straight
> foward to understand editor by default so they aren't scared away
> before they even learn what an environment variable is, it's not about
> being the best most special editor. They may well have learned how to
> use git on windows or Mac before moving to Linux.

The distribution of git I use on Windows defaults to vi, too.

Kamil

> I would flip this
> around and say anyone who knows vim enough should know how to change
> their default editor.
> 
> Peter

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Leigh Scott]

> On Fri, Jun 26, 2020 at 10:44:22AM -, Leigh Scott wrote:
> 
> Tone doesn't translate well to email. I assume you meant this with a joking,
> friendly tone -- but "grubby" is still negative (merriam-webster says
> "worthy of contempt"). It's easy for these things to be misread or taken
> out
> of context and better to, yeah, stick to being nice. The negative language
> doesn't really add anything even as a joke.

It depends if you choose to ignore the smiley at the end of my comment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Vít Ondruch]

Dne 26. 06. 20 v 15:17 Ben Cotton napsal(a):
> On Fri, Jun 26, 2020 at 9:14 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
>>> Which is better? default or defaults? I don't have a preference.
>> I went with "-defaults" in this case because the package provides "the
>> default configuration", i.e. "defaults".
>>
>> This doesn't translate exactly to the nano case, which is about making
>> the program the default "plugin" in another program (git).
>>
> What about something like "default-editor"?


Shouldn't it be independent package then? Or shouldn't all editors have
subpackage like this?


Vít


>  That way it's more obvious
> from the name what it actually does. If we later decide to change the
> default editor, we update that package (and spins/labs, power users,
> etc can exclude that package in kickstarts if they don't want it)
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Matthew Miller  said:
> And it really isn't just git, although that may the most common tool people
> run into it with. "crontab -e" is another example off the top of my head.

And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit,
less v, mutt, edquota, and a number of bug-report type things like perlbug.

That's just things off the top of my head, I'm sure there's more.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Ben Cotton]

On Fri, Jun 26, 2020 at 9:03 AM Robert-André Mauchin  wrote:
>
> Any news on that?

Nope! The lukewarm reaction and subsequent *guestures at the state
of the world* moved this to the bottom of the stack. It's still on my
todo list for some point in the future.

> Dropping requests on the last comment date, not last
> activity, as some CC/Un-assigning may happen well after the real bug activity.
>
That's a good point.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
> On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
> > Do we have real stasitics on this (somthing in the form of bz reports or
> > comments on a list) indicating that users actually are frustrated with being
> > confronted with vi unexpectedly? 
> 
> Why would one file a bugzilla ticket over this?  vi, and the system 
> default, is working as intended.  "That's just the way Linux is," say 
> the folks having to answer "how to quit vi" for the umpteenth time.
> 
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people
actually asking how to quit vi (or some simmilar questions) somewhere?  If I
google how to quit vi, I see a full 10 pages of the answer to the question
documented in detail (which suggests lots of people had the question at some
point in time), but what I don't see are stackoverflow (or other message board
posts) asking the question currently.  Clearly there was a time when this was a
problem (and access to all the online resources we have today wasn't available),
but now?  I'm just asking us not to make this decision by proxy.  Are there
users out there today that are complaining somewhere that vi is hard to use, and
can't either figure it out, or figure out how to use a different editor

> > I'm struggling with the notion that an individual user is sufficiently 
> > skilled to use git on the command line,
> 
> They actually aren't skilled on the cmdline.  At most they'll just 
> cut-n-paste something they found on stack overflow.  Instead, GUI git 
> frontends are the norm, generally embedded within IDEs.
> 
This just confuses me further.  For integrated IDEs, the selection of a default
editor for terminal usage is largely irrelevant, as the IDE typically provides
an editor built in (basing this assertion on eclipse behvior, but I'd be
suprised if an ide forks a terminal just to run the git default editor)

So the user you are describing

1) Isn't skilled in command line usage
2) Chose to use the command line anyway, despite having a littany of IDE's
available
3) Was sufficiently well versed in development process to chose to use an SCM,
and to search for commands to work with it (setting asside their lack of
understanding of what they were doing)
4) But wasn't sufficiently well versed enough to go back and find out how to use
the editor that their scm choice chose to default to

I just don't see that that person really exists.

Note I'm not saying we shouldn't make this change, I'm just saying that I don't
like the idea of making it based on our assumption of what our end users are
struggling with.  If we have references to end users that legitimately have this
problem, I'd love it to see them, and that would satisfy me.

Neil

> (FFS most of the folks I work with use the github web frontend to commit 
>  things.  Because git is just short for github!)
> 
>  - Solomon [who greatly prefers emacs]
> -- 
> Solomon Peachy  pizza at shaftnet dot org 
> (email&xmpp)
>   @pizza:shaftnet dot org   (matrix)
> High Springs, FL  speachy (freenode)



> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 13:11 +, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:

On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy  wrote:
>
> On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro  
wrote:
> >
> > On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro
> >  wrote:
> > > Yes. I already fixed the wiki page to clarify that we don't need to
> > > install nano, but I forgot to clarify that we will install
> > > nano-editor by default.
> >
> > BTW maybe nano-editor is not the best name for the subpackage,
> > considering it will not include the nano text editor, but rather a conf
> > snippet to set $EDITOR. Any alternative naming proposals?
>
> nano-default ?

We're using zram-generator-defaults for this.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737

Which is better? default or defaults? I don't have a preference.


I went with "-defaults" in this case because the package provides "the
default configuration", i.e. "defaults".

This doesn't translate exactly to the nano case, which is about making
the program the default "plugin" in another program (git).


This is not really about Git, and it's certainly not a "plugin".

Obeying EDITOR is required by POSIX e.g. see
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_08

Note that POSIX says "The default editor shall be vi." But that means
when EDITOR isn't set. If the system or a user sets EDITOR to
something else, it's still POSIX-conforming.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Robinson]

> > > Why not just patch vim-minimal to show the hint on the CTRL+C?
> > > Problem solved :)
> > Ctrl + C in vi will give you a
> > Type :qa and press  to exit Vim

You can also do ZZ (two capital Zs) to exit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

[PGNet Dev]

hi,

On 6/25/20 11:58 PM, Nicolas Mailhot wrote:
> forgemeta works in release mode, with release archives published over
> http(s). It does not talk at all to source projects using the git
> protocol (and that is intentional, since a lot ot things tooling-side
> do not talk the git protocol and will never talk the git protocol,
> starting with rpm itself, spectool, etc).

noted.  not clear initially from reading the docs; this helps. thx!

> git is not the only scm system out there.
(snip)

sure.  i'm trying to get forge playing nice with not-included-yet hg sources 
atm :-)

>  From a pure auditing side
...

> Note that your spec as it stands is inherently unsafe since
...
> The correct auditable way
...

(snip)

yup.  and for the moment -- while I'm getting my 'end product' sorted out -- 
that's intentional, and I'm not concerned with audit trail.

yet.

point taken otherwise.

> So you should have a long list of
> %forgeurlX


that's already changed in my latest ...

> %tagX or %commitX

fair enuf, now that the above is nice-n-clear ...

> and a single %forgemeta -a at the end

was having weird artifacts doing that earlier, so split into 
one-per-source-target.

once a forge bug (other thread) gets ironed out, that'll get revisited, too.

> That will change soonish BTW, I’m currently doing final testing on code
> that will use a slightly different syntax:
> 
> %forge_urlX
(snip)

that'll get announced ... here?

do you have a _rough_ timeframe for when that'll be consistently 
supported/usable in rpmbuild, mock & COPR?
bunch of moving parts to get in sync ...

> Because not making -a the default and emphasising -z in the
> documentation was comfusing users. -z should be a last resort debuging
> help

it was helpful for debug, here.  and at my early stage, necessary ...

> not the first thing you look at when packaging multiple sources.

yup

> That will leave you with each individual source unpacked and patched in
> %{_builddir}, and needing a some symlinks between %{_builddir}
> subdirectories to construct a unified source trees, but that’s how
> multisource works deep down in rpm, nothing I invented myself.

that's what i'd naively assumed was to cleanly happen when i'd started with 
this multisource spec.
if this cleans that up, then +1 !

> ... have people butcher it to achiever their aims ...

but, that's _our_ job! ;-)

cheers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 Self-Contained Change proposal: GHC 8.8 and Haskell Stackage LTS 16

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GHC_8.8_and_LTS16

== Summary ==
The GHC Haskell compiler will be updated from major version 8.6 to 8.8,
and Haskell packages will be updated from Stackage LTS 14 to LTS 16 versions.

== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email: 

== Detailed Description ==
For Fedora 33, the GHC Haskell compiler will be updated from version
8.6.5 to 8.8.3 (based on the ghc:8.8 module stream).
Along with this Haskell packages in [https://www.stackage.org
Stackage] will be updated from the versions in LTS 14 to LTS 16.
Haskell packages not in Stackage will be updated to the latest current
version in [https://hackage.haskell.org Hackage].

== Benefit to Fedora ==
Fedora users will benefit from access to the latest stable Haskell
compiler release, package tools, and current stable Haskell packages
from Stackage LTS.

GHC 8.8 features a new code layout algorithm for x86, the final
implementation of the MonadFail proposal, and also many bugfixes (see
the Documentation links for more details).

== Scope ==
* Proposal owners:
** rebase ghc to 8.8.3
** update ghc-rpm-macros to the final version for F33 GA
** refresh packagings with the latest cabal-rpm release
** update packages to latest Stackage LTS 16 versions using cabal-rpm
** build all the packages in a Koji sidetag repo in dependency order
** When finished push all builds through Bodhi to Rawhide before the
mass rebuild
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Any dropped packages will have obsoletes added.
Otherwise there should not be any direct upgrade impact.

Users' Haskell projects will get rebuilt with ghc-8.8 when they next
build them and might need minor adjustments.

== How To Test ==
* install ghc and cabal-install
* install pandoc, ShellCheck, git-annex
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep ; cabal install 
* test upgrades of F32 packages to F33

== User Experience ==
Users will have the most recent stable major version of `ghc` and
Haskell libraries and tools available to them.
This makes it easier to build the latest versions of Haskell projects.

Also these updates include a major new version 3 of the Haskell
`Cabal` library and `cabal-install` packaging tool
with important new features and enhancements, and `stack` is being
updated from 2.1 to 2.3.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?)
** Change owner will drop the new builds and revert back to the versions in F32.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
* 
https://downloads.haskell.org/~ghc/8.8.3/docs/html/users_guide/8.8.1-notes.html
* https://hackage.haskell.org/package/cabal-install-3.0.0.0/changelog
* https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/8.8

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/BtrfsByDefault

== Summary ==

For laptop and workstation installs of Fedora, we want to provide file
system features to users in a transparent fashion. We want to add new
features, while reducing the amount of expertise needed to deal with
situations like [https://pagure.io/fedora-workstation/issue/152
running out of disk space.] Btrfs is well adapted to this role by
design philosophy, let's make it the default.

== Owners ==

* Names: [[User:Chrismurphy|Chris Murphy]], [[User:Ngompa|Neal
Gompa]], [[User:Josef|Josef Bacik]], [[User:Salimma|Michel Alexandre
Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:eeickmeyer|Erich
Eickmeyer]], [[User:ignatenkobrain|Igor Raits]],
[[User:Raveit65|Wolfgang Ulbrich]], [[User:Zsun|Zamir SUN]],
[[User:rdieter|Rex Dieter]], [[User:grinnz|Dan Book]],
[[User:nonamedotc|Mukundan Ragavan]]
* Emails: chrismur...@fedoraproject.org, ngomp...@gmail.com,
jo...@toxicpanda.com, mic...@michel-slm.name, dcava...@fb.com,
er...@ericheickmeyer.com, ignatenkobr...@fedoraproject.org,
fed...@raveit.de, z...@fedoraproject.org, rdie...@gmail.com,
gri...@gmail.com, nonamed...@gmail.com

* Products: All desktop editions, spins, and labs
* Responsible WGs: Workstation Working Group, KDE Special Interest Group


== Detailed Description ==

Fedora desktop edition/spin variants will switch to using Btrfs as the
filesystem by default for new installs. Labs derived from these
variants inherit this change, and other editions may opt into this
change.

The change is based on the installer's custom partitioning Btrfs
preset. It's been well tested for 7 years.

'Current partitioning'
vg/root LV mounted at / and a vg/home LV mounted at /home. These are separate file system volumes, with
separate free/used space.

'Proposed partitioning'
root subvolume mounted at / and home subvolume mounted at /home. Subvolumes don't have size, they act mostly like
directories, space is shared.

'Unchanged'
/boot will be a small ext4 volume.
A separate boot is needed to boot dm-crypt sysroot installations; it's
less complicated to keep the layout the same, regardless of whether
sysroot is encrypted. There will be no automatic snapshots/rollbacks.

If you select to encrypt your data, LUKS (dm-crypt) will be still used
as it is today (with the small difference that Btrfs is used instead
of LVM+Ext4). There is upstream work on getting native encryption for
Btrfs that will be considered once ready and is subject of a different
change proposal in a future Fedora release.

=== Optimizations (Optional) ===

The detailed description above is the proposal. It's intended to be a
minimalist and transparent switch. It's also the same as was
[[Features/F16BtrfsDefaultFs|proposed]] (and
[https://lwn.net/Articles/446925/ accepted]) for Fedora 16. The
following optimizations improve on the proposal, but are not critical.
They are also transparent to most users. The general idea is agree to
the base proposal first, and then consider these as enhancements.

 Boot on Btrfs 

* Instead of a 1G ext4 boot, create a 1G Btrfs boot.
* Advantage: Makes it possible to include in a snapshot and rollback
regime. GRUB has stable support for Btrfs for 10+ years.
* Scope: Contingent on bootloader and installer team review and
approval. blivet should use mkfs.btrfs --mixed.

 Compression 

* Enable transparent compression using zstd on select directories:
/usr/var/lib/flatpak~/.local/share/flatpak
* Advantage: Saves space and significantly increase the lifespan of
flash-based media by reducing write amplification. It may improve
performance in some instances.
* Scope: Contingent on installer team review and approval to enhance
anaconda to perform the installation using mount -o
compress=zstd, then set the proper XATTR for each directory.
The XATTR can't be set until after the directories are created via:
rsync, rpm, or unsquashfs based installation.

 Additional subvolumes 

* /var/log//var/lib/libvirt/images  and  ~/.local/share/gnome-boxes/images/ will use separate
subvolumes.
* Advantage: Makes it easier to excluded them from snapshots,
rollbacks, and send/receive. (Btrfs snapshotting is not recursive, it
stops at a nested subvolume.)
* Scope: Anaconda knows how to do this already, just change the
kickstart to add additional subvolumes (minus the subvolume in ~/. GNOME Boxes will need enhancement to
detect that the user home is on Btrfs and create ~/.local/share/gnome-boxes/images/ as a subvolume.

== Feedback ==

 Red Hat doesn't support Btrfs? Can Fedora do this? 

Red Hat supports Fedora well, in many ways. But Fedora already works
closely with, and depends on, upstreams. And this will be one of them.
That's an important consideration for this proposal. The community has
a stake in ensuring it is supported. Red Hat will never support Btrfs
if Fedora rejects it. Fedora necessarily needs to be first, and make
the persuasive case that it solves 

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 10:33 -0400, Neil Horman wrote:

On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:

On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
> Do we have real stasitics on this (somthing in the form of bz reports or
> comments on a list) indicating that users actually are frustrated with being
> confronted with vi unexpectedly?

Why would one file a bugzilla ticket over this?  vi, and the system
default, is working as intended.  "That's just the way Linux is," say
the folks having to answer "how to quit vi" for the umpteenth time.


Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people
actually asking how to quit vi (or some simmilar questions) somewhere?  If I
google how to quit vi, I see a full 10 pages of the answer to the question
documented in detail (which suggests lots of people had the question at some
point in time), but what I don't see are stackoverflow (or other message board
posts) asking the question currently.


For the third time:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4XS6ZYUO4K3OY46MSJQOLBPEKCXZFAE4/

Three years ago they said:

"In the last year, How to exit the Vim editor has made up about .005%
of question traffic: that is, one out of every 20,000 visits to Stack
Overflow questions. That means during peak traffic hours on weekdays,
there are about 80 people per hour that need help getting out of Vim."


Note I'm not saying we shouldn't make this change, I'm just saying that I don't
like the idea of making it based on our assumption of what our end users are
struggling with.  If we have references to end users that legitimately have this
problem, I'd love it to see them, and that would satisfy me.


See above. I find it surprising, but the numbers are there, and while
I think things have changed a lot in 20 years, I don't think they've
changed much since 2017.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 26, 2020 at 08:39:46AM -0300, Sergio Belkin wrote:
> Again, I'm not against the proposal, but I would prefer a better and sane
> discussion.
> Honestly most end users dislike the CLI.
> However I understand that discussion is not about "what is my preferred
> editor?".
> I understand that discussion is "if by chance an end user has to use CLI,
> he/she will not know what/how to do with vim".
> In such a case nano is easier (regardless that the argument about how hard
> is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
...
> But please, again, most end users prefer to use a gui editor. Is not about
> that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about
> that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical
> environments.

Hi,

While users do prefer graphical editors, they fact that the editor
window is completely separate from the terminal (non-modal) creates a
big usability issue for the usecase of git. The problem is not so bad
if a new editor window is spawned, because then it is clear to the
user that the new window is in response to the terminal action. But
when the user already has the editor open, most editors will simply
pop up a new tab. The way I have seen this work in practice is that
newbies see their git prompt "hang" and are oblivious to fact they
they should switch to the editor. But even if they do switch, they
will often just try to save the document, and not exit the editor.
When you have someone at hand to explain it to you, it's not so
bad, but without assistance, people get confused.

(More generally: for the edit command to work properly, git requires
that command not exit until after the file has been edited and saved.
This is trivial with any in-terminal editor, but guis most often
operate in the fashion where the command either goes into the
background to unblock the terminal, or sends a message to the
already-running instance to open another file and exits. All this can
usually be worked-around with specific options to the editor command,
but is certainly confusing to newbies.)

Because of this additional complexity with gui editors, I'm very
much convinced that a text editor is a better default. (And nano
is good choice among text editors...).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 09:24 -0500, Chris Adams wrote:

Once upon a time, Matthew Miller  said:

And it really isn't just git, although that may the most common tool people
run into it with. "crontab -e" is another example off the top of my head.


And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit,
less v, mutt, edquota, and a number of bug-report type things like perlbug.

That's just things off the top of my head, I'm sure there's more.


POSIX specifies the EDITOR env var and requires 'crontab', 'mailx',
and 'more' to use it. The decision for other non-POSIX utilities like
git to use it is an obvious choice, for consistency with standard
utilities.

Amusingly, the fc utility requires "If FCEDIT is null or unset, ed
shall be used as the editor." Yikes ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

> I came here with peace. Let's face it. It's always between the two. I
> respect vim and I learned quite some things in vim. But I'm an emacs
> user and I find the original decision between vim and emacs for 'git
> commit' unfair.

Git doesn't use vim by default, it uses vi, and it's got nothing to do with 
fairness. vi is specified by the POSIX standard, emacs is not. Using vi as the 
default when EDITOR is not set is consistent with POSIX utilities like crontab, 
using emacs is not.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html

But this isn't about your preference (emacs) or my preference (vim), or what 
POSIX can portably assume is present. Fedora can assume nano is present, 
because Fedora controls that and already makes it present.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Vitaly Zaitsev via devel]

On 26.06.2020 16:42, Ben Cotton wrote:
> For laptop and workstation installs of Fedora, we want to provide file
> system features to users in a transparent fashion. We want to add new
> features, while reducing the amount of expertise needed to deal with
> situations like [https://pagure.io/fedora-workstation/issue/152
> running out of disk space.] Btrfs is well adapted to this role by
> design philosophy, let's make it the default.

I'm strongly against this proposal. BTRFS is the most unstable file
system I ever seen. It can break up even under an ideal conditions and
lead to a complete data loss. There are lots of complaints and bug
reports in Linux kernel bugzilla and Reddit.

Such changes could affect Fedora reputation among other distributions.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Matthew Miller]

> https://fedoraproject.org/wiki/Changes/BtrfsByDefault

Wow! Is it 2010 already? Time flies! :)

In seriousness: thanks for all of the effort put into this change proposal,
and the impressive list of change owners. I'm following the discussion here
with much interest!



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Watters]

Makes sense to me.  Many people do not know how to use vi/vim and don't
want to spend time learning arcane commands just to edit a bit of text. 
This would also put Fedora in line with other distros such as Ubuntu.

Those of us who actually *want* to use a different editor can also
easily change this setting via the $EDITOR environment variable.

On 6/25/2020 1:18 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
>
> == Summary ==
>
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.
>
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email:  chrismur...@fedoraproject.org
>
>
> == Detailed Description ==
>
> Users are exposed to the default editor when they use commands that
> call it. The main example here is something like git
> commit.
>
> Fedora does not currently have a default terminal text editor, because
> the $EDITOR environment variable is unset by default. But a common
> scenario where users wind up in a terminal text editor is when using
> 'git commit'. By default, git picks vi. You need to spend time
> learning how to use it, for even basic editing tasks. This increases
> the barrier to entry for those who are switching to Fedora and don't
> know how to use vi. It also makes things hard for those who don't
> particularly want to learn how to use vi. (These arguments would apply
> just as well if git picked Vim. vi is like hard mode for Vim, with
> fewer features, missing syntax highlighting, and no indication of what
> mode you are in. Even Vim users may feel lost and bewildered when
> using vi.)
>
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to, and therefore doesn't require specialist
> knowledge to use. It is already installed across most Fedora Editions
> and Spins. This proposal will make Nano the default editor, while
> continuing to install vim-minimal (which provides vi, but
> not Vim). People will still be able to call vi if they
> want to edit a file. It will also obviously be possible to change the
> default editor to vi or Vim, for those who want it.
>
> Why make Nano default and vi optional, rather than the other way
> round? Because Nano is the option that everyone can use.
>
> == Feedback ==
>
> Pending ...
>
> == Benefit to Fedora ==
>
> * Makes the default editor across all of Fedora more approachable.
> * Nano is also mostly self-documenting, by displaying common keyboard
> shortcuts on-screen.
> * More in line with the default editor of other distributions.
>
> == Scope ==
> * Proposal owners:
> ** Modify comps to include nano Fedora wide.
> ** Create a new subpackage of nano, called
> nano-editor.
> ** nano-editor to include
> /usr/lib/environment.d/10-nano.conf, which sets
> $EDITOR to nano.
>
> With this approach, if nano is uninstalled, the
> configuration will be removed with it. At the same time, installing
> nano on its own won't install the conf.
>
> * Other developers: N/A
>
> * Release engineering: [https://pagure.io/releng/issue/9522 #9522]
>
> * Policies and guidelines: N/A
>
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
>
> Will not apply to upgrades.
>
> == How To Test ==
>
> Run export EDITOR="/usr/bin/nano".
>
> == User Experience ==
>
> Users running git commit will be able to just type their
> commit message, rather than having to learn about insert mode, and
> they'll be able to cut and paste without having to learn special
> shortcuts.
>
> == Dependencies ==
>
> No additional dependencies are required.
>
> == Contingency Plan ==
> The contingency plan is to revert the change by removing the
> nano-editor package.
>
> * Contingency deadline: probably the beta? It's an easy change to revert.
> * Blocks release? If the change breaks the redirection to an editor,
> it should block the release. However, this is unlikely.
> * Blocks product? Potentially all.
>
> == Documentation ==
> As part of this change, it would be good to add instructions for
> changing the default editor to the
> [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Solomon Peachy]

On Fri, Jun 26, 2020 at 10:42:25AM -0400, Ben Cotton wrote:
> For laptop and workstation installs of Fedora, we want to provide file
> system features to users in a transparent fashion. We want to add new
> features, while reducing the amount of expertise needed to deal with
> situations like [https://pagure.io/fedora-workstation/issue/152
> running out of disk space.] Btrfs is well adapted to this role by
> design philosophy, let's make it the default.

So... can btrfs now be trusted to not crap itself?

> The change is based on the installer's custom partitioning Btrfs
> preset. It's been well tested for 7 years.

What does "Well tested" mean, in this context?  Do we have data that 
shows roughly how many installs were done in Fedora-land, and how long 
they lasted?

(two of the installs in that 7 year period were mine, and ended in 
 complete filesystem loss across clean shutdown/restart cycles. Hardware 
 is still in use, and other than a failed fan, hasn't so much as 
 hiccupped since scrapping btrfs)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org