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

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Joey Pabalinas wrote:
> Git subtrees lend themselves better when developing both main project
> and sub-project within the same directory (a "system approach"). This, however,
> would be more akin to a "vendor branch": a branch which allows you to access

Thanks, having not used submodules and subtrees before I was
experimenting to see how they might be used and this has helped clarify
things.

I also concluded that we can't easily pull in a subdirectory of the
existing zsh-completions project: it is all or nothing. Maybe it is
somehow possible with a subtree merge (a different thing from git
subtree) but my attempts at that failed. However:

> I feel like a good compromise would be for there to be a seperate, isolated
> `zsh-completions` repository that both projects can submodule;

That might work. Not sure I like there then being three projects (plus
upstreams). The whole idea is to make it less confusing for someone
wanting to contribute. Maybe the "incubator" completions could be pulled
in to the zsh repository with the others but excluded from a zsh release
tarball. Or we could use a separate orphan git branch.

If we're to separate completions out of zsh, there's also the question
of how much to separate out. Different levels would be:
  * Separate away all of it, even including Base and compinit
  * Leave back only the core
  * Also leave completion of Zsh builtins
  * Also leave any functions that are called from these, i.e. a good chunk
    of Unix/Type, especially _files; separating just external commands
  * Start with an empty new repository leaving all the existing stuff

Unless we use the empty new repository, actually making the separation
is quite a bit of work given Makefile stuff aswell. And as mentioned
before, separating also creates the problem of needing to worry about
backward compatibility in functions.

What I would prefer is for us to leave zsh completions where they are but
optimise the workflow:

  * Encourage completion contributions in the form of github pull
    requests to the zsh-users/zsh mirror. This isn't hard to handle:
    add github as an additional remote, fetch refs/remotes/xxxx/pr/*,
    cherry-pick and push to the sourceforge master.
  * Require no mailing list message for basic completion updates.
  * Rethink the need to update ChangeLog on every commit.

We preserved the ChangeLog in its existing form when migrating from CVS
largely so that we were changing as little as possible. But we have git
log. All new ChangeLog entries can be autogenerated as a whole as part
of rolling a release for inclusion in the tarball. Even for the tarball
I'd argue that most users would prefer a well produced NEWS file update
to the detailed ChangeLog.

I realise that this doesn't solve the problems with how to hatch
completions from zsh-completions.

Oliver