pull requests for completion functions

pull requests for completion functions

[Oliver Kiddle]

I have tentatively added a short line to the bottom of the contributing
section of the web pages to indicate that completions are acceptable in
the form of pull/merge requests. The link is here:

  http://zsh.sourceforge.net/Arc/git.html

Can I take silence to mean that people were happy with my suggestion on
this new policy? If not then please speak now, reverting the web page is
easily done.

My intended procedure for managing pull requests is as follows.

First you need to add separate remote repositories:
  git remote add gitlab https://gitlab.com/zsh-org/zsh.git
  git remote add github https://github.com/zsh-users/zsh.git

There's a variety of ways to fetch pull requests directly but I add a line
in .git/config under each section:

  under: [remote "gitlab"]
  add:       fetch = +refs/merge-requests/*/head:refs/remotes/gitlab/merge-requests/*
  under: [remote "github"]
  add:       fetch = +refs/pull/*:refs/remotes/github/pr/*

Many projects use merges but, to keep things as consistent as possible
with current practices, for now I would cherry-pick individual pull
requests and amend the commit to add a ChangeLog entry and reference
to the commit message. For ChangeLog entries and commit messages, the
references might be something like "MR: #1". Or do we need to be more
explicit, e.g. "github PR: #1"?

Any comments or suggestions would be welcome.

Oliver

Re: pull requests for completion functions

[Peter Stephenson]

(Aplogies for fornatting, on my mobile.)

I've certainly got no objection to more flexible arrangements for completion functions if that works.

pws

On 9 November 2017 16:20:59 GMT+00:00, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>I have tentatively added a short line to the bottom of the contributing
>section of the web pages to indicate that completions are acceptable in
>the form of pull/merge requests. The link is here:
>
>  http://zsh.sourceforge.net/Arc/git.html
>
>Can I take silence to mean that people were happy with my suggestion on
>this new policy? If not then please speak now, reverting the web page
>is
>easily done.
>
>My intended procedure for managing pull requests is as follows.
>
>First you need to add separate remote repositories:
>  git remote add gitlab https://gitlab.com/zsh-org/zsh.git
>  git remote add github https://github.com/zsh-users/zsh.git
>
>There's a variety of ways to fetch pull requests directly but I add a
>line
>in .git/config under each section:
>
>  under: [remote "gitlab"]
>add:       fetch =
>+refs/merge-requests/*/head:refs/remotes/gitlab/merge-requests/*
>  under: [remote "github"]
>  add:       fetch = +refs/pull/*:refs/remotes/github/pr/*
>
>Many projects use merges but, to keep things as consistent as possible
>with current practices, for now I would cherry-pick individual pull
>requests and amend the commit to add a ChangeLog entry and reference
>to the commit message. For ChangeLog entries and commit messages, the
>references might be something like "MR: #1". Or do we need to be more
>explicit, e.g. "github PR: #1"?
>
>Any comments or suggestions would be welcome.
>
>Oliver

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: pull requests for completion functions

[Alex George]

[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]

No objections here. I think it would be especially useful for large
patches. However, if someone were to use git{hub,lab} to submit a PR,
should they send a message about it to the list? If so, should discussion
about the patch take place on the list, or on git{hub,lab}? What should the
mailing list subject be? Should the body simply contain a link to the PR?

These are just my immediate thoughts and questions about the approach.
Also, I'm terribly sorry if my formatting is poor, I'm a mailing list noon
and not using a "real" mail client.

---------- Forwarded message ---------
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
Date: Thu, Nov 9, 2017, 09:33
Subject: Re: pull requests for completion functions
To: <zsh-workers@zsh.org>


(Aplogies for fornatting, on my mobile.)

I've certainly got no objection to more flexible arrangements for
completion functions if that works.

pws

On 9 November 2017 16:20:59 GMT+00:00, Oliver Kiddle <okiddle@yahoo.co.uk>
wrote:
>I have tentatively added a short line to the bottom of the contributing
>section of the web pages to indicate that completions are acceptable in
>the form of pull/merge requests. The link is here:
>
>  http://zsh.sourceforge.net/Arc/git.html
>
>Can I take silence to mean that people were happy with my suggestion on
>this new policy? If not then please speak now, reverting the web page
>is
>easily done.
>
>My intended procedure for managing pull requests is as follows.
>
>First you need to add separate remote repositories:
>  git remote add gitlab https://gitlab.com/zsh-org/zsh.git
>  git remote add github https://github.com/zsh-users/zsh.git
>
>There's a variety of ways to fetch pull requests directly but I add a
>line
>in .git/config under each section:
>
>  under: [remote "gitlab"]
>add:       fetch =
>+refs/merge-requests/*/head:refs/remotes/gitlab/merge-requests/*
>  under: [remote "github"]
>  add:       fetch = +refs/pull/*:refs/remotes/github/pr/*
>
>Many projects use merges but, to keep things as consistent as possible
>with current practices, for now I would cherry-pick individual pull
>requests and amend the commit to add a ChangeLog entry and reference
>to the commit message. For ChangeLog entries and commit messages, the
>references might be something like "MR: #1". Or do we need to be more
>explicit, e.g. "github PR: #1"?
>
>Any comments or suggestions would be welcome.
>
>Oliver

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 

- Alex

Re: pull requests for completion functions

[Oliver Kiddle]

Alex George wrote:
> No objections here. I think it would be especially useful for large
> patches. However, if someone were to use git{hub,lab} to submit a PR,
> should they send a message about it to the list? If so, should discussion
> about the patch take place on the list, or on git{hub,lab}? What should the
> mailing list subject be? Should the body simply contain a link to the PR?

The motivation is to make it easier for casual contributors to submit
completion function related patches. I was planning to keep interaction
related to pull/merge requests on git{hub,lab} and only move to the
list if questions related to the core parts of completion come up. When
discussing a proposed patch, it's often useful to quote parts of both
patch and commentary so I'm not sure how constructive it would be if the
patch is on gitlab and the explanatory remarks go to the list.

Sending completion function patches to the mailing list will also
continue to be perfectly acceptable. I'll probably continue to do things
that way myself. Perhaps we should lower the threshold of what gets
pushed unposted with completion functions to reduce noise on the list(?)

I'm not sure I see a problem with large patches on the mailing list but
until now, my experience with git{lab,hub} is relatively limited. So I'm
open to suggestions.

Oliver

Re: pull requests for completion functions

[Bart Schaefer]

On Nov 9,  5:20pm, Oliver Kiddle wrote:
}
} Any comments or suggestions would be welcome.

This is not yet intended to address the question of releasing completions
separately from the main shell releases, is that correct?