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

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Daniel Shahaf wrote:
> > 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.

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

A further advantage relates to the following point that Julien raised:

| | • If I send a compdef to zsh, what happens then ? We have to wait a least for
| |   the next release of zsh to delete it from zsh-completions. But then, not
| |   all distros update to the latest release of zsh, or the compdef could have
| |   evolved in zsh-completions in the meanwhile, so I can see this could be
| |   become quite a headache to manage (for users as well).

Perhaps zsh-completions could add a separate directory containing
functions that graduated to zsh. Copies of other functions that are
newish in zsh might also go there, perhaps in backported form. Packagers
would need to arrange for this to come at the end of $fpath which
might be a little tricky.

> 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@.

Yes, that's how I would envisage it.

> 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@).

If that removes the need to manually post patches for basic completion
updates I'd be in favour of that. An option might be to have that only
take commits that don't have an X-Seq reference in the commit message.

> 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.

I'd be happy enough to commit twice. We did that in the past with
3.0, 4.0 and 4.2 branches. But that approach also requires us to make
releases of the branch. I alluded to something along these lines in
41908 ¶4.

Backporting to the most recent release branch is rarely a big deal.
Certainly compared to what a separate project might find users.
expecting (RHEL 6 is in wide use still and has 4.3.11).

Oliver