Changing the subject for visibility.
We're looking for someone to watch PATCH threads and ping them if they peter
out unresolved (e.g., are awaiting review or are awaiting re-submission with
revisions). You needn't be a zsh developer yourself; you just need to be able
to follow a patch thread, and have time once a week or so to review a few such
threads and reply with short reminders where needed.
Any volunteers?
Cheers,
Daniel
----- Forwarded message from Daniel Shahaf <d.s@daniel.shahaf.name> -----
> Date: Mon, 8 Feb 2021 05:53:38 +0000
> From: Daniel Shahaf <d.s@daniel.shahaf.name>
> To: zsh-workers@zsh.org
> Subject: Re: [PATCH] Fix [:IDENT:] vs posixidentifiers
> Message-ID: <20210208055338.GB22819@tarpaulin.shahaf.local2>
> X-Seq: 47945
>
> Bart Schaefer wrote on Sun, Feb 07, 2021 at 12:24:26 -0800:
> > On Sun, Feb 7, 2021 at 7:50 AM Stephane Chazelas <stephane@chazelas.org> wrote:
> > >
> > > Ping. Anybody objecting to this?
> >
> > Not I. We're behind on merging several patches, I think.
>
> Do we need a patch manager?
>
> (See, for instance,
> https://subversion.apache.org/docs/community-guide/roles#patch-manager;
> tl;dr: someone who watches PATCH threads and pings them if they peter out
> unresolved — neither accepted nor rejected.)
>
----- End forwarded message -----
[-- Attachment #1: Type: text/plain, Size: 689 bytes --] On Mon, Feb 15, 2021 at 3:21 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > You needn't be a zsh developer yourself; you just need to be able to follow a patch thread, and have > time once a week or so to review a few such threads and reply with short reminders where needed. By "follow a patch thread" do you mean: 1. Read emails related to a topic and see that the conversation has stopped or slowed, but no resolution (closed or merged) has occurred. or 2. Be able to understand what a patch does and why it is important? I think I could do the former. I could not do the latter. ~ Tj (not officially volunteering just yet, but wanting to understand what the 'job' entails) [-- Attachment #2: Type: text/html, Size: 1462 bytes --]
TJ Luoma wrote on Mon, Feb 15, 2021 at 16:06:42 -0500: > On Mon, Feb 15, 2021 at 3:21 PM Daniel Shahaf <d.s@daniel.shahaf.name> > wrote: > > > You needn't be a zsh developer yourself; you just need to be able to follow > > a patch thread, and have time once a week or so to review a few such > > threads and reply with short reminders where needed. > > By "follow a patch thread" do you mean: > > 1. Read emails related to a topic and see that the conversation has stopped > or slowed, but no resolution (closed or merged) has occurred. > > or > > 2. Be able to understand what a patch does and why it is important? > > > I think I could do the former. I could not do the latter. > > ~ Tj > (not officially volunteering just yet, but wanting to understand what the > 'job' entails) Thanks for asking. I mean #1. The patch manager doesn't actually have to understand what a patch does at either the implementation level or the user-facing level; a patch manager just needs to be able to determine "This patch has been committed", "This patch has been rejected", "This patch has not yet been reviewed", etc.. There's also a write-up in https://producingoss.com/en/share-management.html#patch-manager, which I neglected to link to earlier. Cheers, Daniel (By the way, sourceforge sends email notifications of each push to the repository. I assume it'll be possible for the patch manager to subscribe to these notifications, if they wish. That'll help them track which patches have been committed.)
On 2021-02-15 2:20 p.m., Daniel Shahaf wrote:
>
>> ~ Tj
>> (not officially volunteering just yet, but wanting to understand what the
>> 'job' entails)
Same here. I'd like to do something useful just so long as I am able to
do it.
Ray Andrews wrote on Mon, Feb 15, 2021 at 15:29:42 -0800:
> On 2021-02-15 2:20 p.m., Daniel Shahaf wrote:
> > TJ Luoma wrote on Mon, Feb 15, 2021 at 16:06:42 -0500:
> > > (not officially volunteering just yet, but wanting to understand what the
> > > 'job' entails)
TJ, Ray, thanks for your interest, however, as neither of you has
"officially volunteered", I took that to mean I shouldn't enter your
ballots into the hat I made the selection with.
The Patch Manager hat goes to Lawrence Velázquez, who volunteered
offlist, and not unofficially. Thanks, Lawrence!
Is there any patch submission or community governance documentation we
should be updating?
Lawrence, if there's any automation we can stick on zsh.org to make your
job easier, let us know.
Cheers,
Daniel
On 2021-02-17 2:36 p.m., Daniel Shahaf wrote:
>
> The Patch Manager hat goes to Lawrence Velázquez, who volunteered
> offlist, and not unofficially. Thanks, Lawrence!
Just as well to have someone of known competence. I at least would have to
learn the job on the job. Still, it would be nice to be able to make
some sort
of contribution given all the help I've received.
[-- Attachment #1: Type: text/plain, Size: 544 bytes --] On Wed, Feb 17, 2021 at 6:30 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > Just as well to have someone of known competence. I at least would have to learn the job on the > job. Still, it would be nice to be able to make some sort of contribution given all the help I've > received. Exactly my thoughts. I wouldn't have known how to do the job, but I would have been glad to do something to try to give back for all the help I've received over the many years. Still, glad to have someone who knows what they're doing take the helm! ~ Tj [-- Attachment #2: Type: text/html, Size: 866 bytes --]
TJ Luoma wrote on Thu, 18 Feb 2021 01:42 +00:00: > > On Wed, Feb 17, 2021 at 6:30 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > Just as well to have someone of known competence. I at least would have to learn the job on the > > job. Still, it would be nice to be able to make some sort of contribution given all the help I've > > received. > > Exactly my thoughts. I wouldn't have known how to do the job, but I > would have been glad to do something to try to give back for all the > help I've received over the many years. Hmm. I appreciate the desire to give back, but I don't know how to clarify the several descriptions I've already given. Again, in a nutshell, the patch manager (PM) should, at regular intervals, go through [PATCH] threads and for each patch do: case $state in (accepted-and-committed) :;; (rejected) :;; (not-yet-reviewed) ping;; (has-been-reviewed-and-is-awaiting-revised-submission) ping;; (*) DTRT;; esac As to other ways to help, well, how about writing documentation patches? They're very helpful, and not hard to write. See Doc/Zsh/*.yo. (Custom syntax highlighting for Vim is in the tree.) > Still, glad to have someone who knows what they're doing take the helm! Cheers, Daniel
> On Feb 17, 2021, at 5:36 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > The Patch Manager hat goes to Lawrence Velázquez, who volunteered > offlist, and not unofficially. Thanks, Lawrence! Happy to help. Like everyone else, I love managing email, and also hats > Is there any patch submission or community governance documentation we > should be updating? To be honest, I don't know where any of that documentation is, other than the "Contributing" section of <http://zsh.sourceforge.net/Arc/git.html>. > Lawrence, if there's any automation we can stick on zsh.org to make your > job easier, let us know. Will do, once I figure out what I'm doing! vq
> On Feb 17, 2021, at 8:42 PM, TJ Luoma <luomat@gmail.com> wrote: > >> On Wed, Feb 17, 2021 at 6:30 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> >> Just as well to have someone of known competence. > > Still, glad to have someone who knows what they're doing take the helm! Surely you are both talking about someone else? >> I at least would have to learn the job on the job. Well now you get to watch me do exactly that! vq
> > Is there any patch submission or community governance documentation we > > should be updating? > > To be honest, I don't know where any of that documentation is, other than > the "Contributing" section of <http://zsh.sourceforge.net/Arc/git.html>. There's at least the "Patches" section in Etc/zsh-development-guide and the paragraph in README that points to that file. > > Lawrence, if there's any automation we can stick on zsh.org to make your > > job easier, let us know. > > Will do, once I figure out what I'm doing! :) Cheers, Daniel
This is unrelated to the previous bug I mentioned, and apologies if this has been brought forward before. There is a more problematic issue with the menu when in the `interactive` setting. zmodload zsh/complist setopt MENU_COMPLETE zstyle ':completion:*:default' menu yes select interactive autoload -Uz compinit compinit # for demo purposes: touch ~/a{b,c} The following and similar inputs show issues [1]: echo $a<Tab>liases[<arrow-right> echo ~/a<Tab>b <Tab><arrow-right> The user finishes the token/word themselves instead of accepting one of the menu's completions. The completer doesn't update the location to insert the new completion. Instead, the new completion is inserted at the original location rather than where it should be. [1]: Demo: https://asciinema.org/a/dZXOf1HGc5zj8AWJ4Ea3lBiGr
On Mon, Feb 22, 2021 at 8:58 AM Paul <GammaFunction@vivaldi.net> wrote: > > This is unrelated to the previous bug I mentioned, and apologies if this > has been brought forward before. There is a more problematic issue with > the menu when in the `interactive` setting. > echo ~/a<Tab>b <Tab><arrow-right> I think the issue here is that typing SPACE does not end the interactive completion, so even though the buffer has advanced, you're still interactively completing the same word as previously. This one is fixed by doing bindkey -M menuselect " " accept-line > echo $a<Tab>liases[<arrow-right> This one is more problematic. You can at least prevent the word so far from being clobbered by doing bindkey -M menuselect "[" .self-insert but there's probably a context-dependent set of characters that could be typed at the end of a word, some of which should self-insert and then end the completion, but others of which should have the effect of ending the current word, self-inserting, and then resuming completion.