Re: GH:zsh-users/zsh-completions.

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote on Tue, 31 Oct 2017 00:38 +0100:
> On 19 Oct, Daniel Shahaf wrote:
> > [having trouble following everything in this thread; replying to just
> > one section]
> 
> Sorry. I suspect you weren't alone. We didn't really come to any useful
> conclusion so I'll try to distill it down to the key alternatives. Note
> that this is no longer about the external zsh-completions project.
> 

Thanks for summarising.

> 1) A suggestion was made to separate the completion functions out into a
> separate project but continuing to include the functions in zsh releases
> and the zsh git repository via git submodule.
> 
>    This strikes me as being a bit extreme. As a separate project it
>    would need to take care of backward compatibility. It could lead to
>    them not being available on some systems due to separate packaging.
>    And setting it all up would be a chunk of work. But there are
>    advantages: less noise on zsh-workers, more frequent releases for
>    completions, easier and less intimidating for casual contributors.
> 

Let's enumerate the advantages and see if there are other ways to
achieve them.  (As you have done.)

> 2) Keep things together but encourage completion contributions in the
> form of pull requests on github and gitlab mirrors. Along with this, I'd
> also suggest that we drop the requirement for a mailing list message for
> basic completion updates.
> 
>    This gets some of the advantages.
> 

I don't see a problem with encouraging patch submission via git??b or
any other channel, provided that (a) we are responsive over the channels
we advertise as 'official', (b) we don't split brain the discussions; i.e.,
we continue to have just one forum for discussing patches that need
discussion (because they're controversial or invasive or ...).  I assume that
forum would continue to be zsh-workers@.

I'd be happy to consider a different workflow for commits.  The
requirement to first post your own patch and then copy the X-Seq header
before pushing it just adds work to maintainers for little benefit.  (We
can continue to add X-Seq references when they're informative to the
commit or changelog message, of course.)

Note, I'd still love for there to be a mailing list that all commits'
diffs are emailed to --- diffs, not just notifications --- but that list
needn't be -workers@; it could be a separate list (say, zsh-commits@).

The remaining point is more frequent releases for completion.  This
again brings compatibility questions, e.g., when we introduced the
typeset reserved word syntax, the completion in master wouldn't have
been usable by released  zsh's; so we need some way to distinguish
Completions/ changes that are for master only from those that are
suitable for released versions too.  I guess that boils down to maintaining
a git branch of the latest release that contains relevant Completions/
commits?  This would require maintainers to commit every patch twice,
though.

> 3) Do nothing.
> 
> It'd be good to know which of these options has broad support before
> getting bogged down on the details.
> 
> Oliver