Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-workers 41970
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: GH:zsh-users/zsh-completions.
- Date: Wed, 01 Nov 2017 16:35:10 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3vshbh Aa4H+0ENuL3zkj6ah8OUopOBCFK+dq+RUqWVo=; b=TDXI2voL3JL0cwPb5qdJUW 0MJDsJJ4aqOPW4hs0dDWPieYhyg+2vWv2SBA68i1x7GZBgWcsmxnxLKeajl4fciP 2NvS1IqIMIuQNsiqkySEMxRs6jBfiyOlKXzx+dmzqMj1YQG8aAvItqNMEZ//7CB/ DCvD7dmmE50YDKtw+KbOVspHDiHocUq985dpRZJx3/SV/70pPesdPmJhNlyA/bXu lnZDT/JZnZBhaJEkn0opVbkgyRq9Ihlrvmlt1n0DPjMfxQ0aJf2azrWqKQKOrKJQ 1AjSkjV1yWp3vYixENBLaxLMl2WzMwi1qn5kn3zjyy93ceaaySOgQ6emfp6S8/Kw ==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3vshbh Aa4H+0ENuL3zkj6ah8OUopOBCFK+dq+RUqWVo=; b=rXCOMcM/4nkWMhz/yv0NNH nKjxuoRNXwfNdJ/4iQptWcjX+5OTpW6PKfqnpqQS2F/rQAPJqJvoINQpN4e2WDOv 1AT3T9PCQf0V+FBd66zxeswABBNj8N2t2yBFzocJcpfJf13BXxFg6bHScsCc4LFz J9qB7pPvn61t2aeT6SywoM+yk+7Rq423ikVkqBXzp8tZK3o/Q8+7UbqE4Kky0DsR 561pvRfEYSZZ1jGVN9rxd1f7hK5u+1TlY75yQw79B0KixyFf6FEk3p034+BD2vsy obWSNAQlIvyrCysZl5+Urp6nBDJpoZOOfsLEYxd68uYvUxR3lz5w05Ag12q3P8PA ==
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- List-unsubscribe: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <email@example.com> <CA+mcLN6ZuZ_AoKvfbceupZVg9+1btDg7NG=bGRUMDxwzLs5bcg@mail.gmail.com> <CGME20171016144130epcas1p2c1fa53d06d36c27f8ac8af3237b97721@epcas1p2.samsung.com> <firstname.lastname@example.org> <email@example.com> <CAH+w=7a2Y+hM_m22MCJYY=ZE67v-_PyOqqMkdC9c1JqCvbUAsg@mail.gmail.com> <firstname.lastname@example.org> <20171016174914.GO31613@andrew.cmu.edu> <MtKUvyERJ4IZOwutyo30irHfL7z63FqUejhZnpXv6zrWYAt_C1-WxOCO_pafA4d3rZ5acQvFoQqrLDmwGsIvy5Y0YQbBirOxZs4xjVCAfRgemail@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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,
> 3) Do nothing.
> It'd be good to know which of these options has broad support before
> getting bogged down on the details.
Messages sorted by: