qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/6] docs/devel: add git-publish for patch submitting


From: Daniel P . Berrangé
Subject: Re: [PATCH v2 2/6] docs/devel: add git-publish for patch submitting
Date: Fri, 6 Dec 2024 11:45:58 +0000
User-agent: Mutt/2.2.13 (2024-03-09)

On Fri, Dec 06, 2024 at 11:43:11AM +0000, Peter Maydell wrote:
> On Fri, 6 Dec 2024 at 11:32, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Dec 05, 2024 at 02:22:37PM -0800, Pierrick Bouvier wrote:
> > > Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> > > ---
> > >  docs/devel/submitting-a-patch.rst | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/docs/devel/submitting-a-patch.rst 
> > > b/docs/devel/submitting-a-patch.rst
> > > index 03b2ac298aa..f8b7fc59544 100644
> > > --- a/docs/devel/submitting-a-patch.rst
> > > +++ b/docs/devel/submitting-a-patch.rst
> > > @@ -235,6 +235,25 @@ to another list.) ``git send-email`` (`step-by-step 
> > > setup guide
> > >  works best for delivering the patch without mangling it, but
> > >  attachments can be used as a last resort on a first-time submission.
> > >
> > > +.. _use_git_publish:
> > > +
> > > +Use git-publish
> > > +~~~~~~~~~~~~~~~
> > > +
> > > +If you already configured git send-email, you can simply use `git-publish
> > > +<https://github.com/stefanha/git-publish>`__ to send series.
> > > +
> > > +::
> > > +
> > > +    $ git checkout master -b my-feature
> > > +    $ # work on new commits, add your 'Signed-off-by' lines to each
> > > +    $ git publish
> > > +    $ ... more work, rebase on master, ...
> > > +    $ git publish # will send a v2
> > > +
> > > +Each time you post a series, git-publish will create a local tag with 
> > > the format
> > > +``<branchname>-v<version>`` to record the patch series.
> >
> > Lets also mention
> >
> >   "When sending patch emails, 'git publish' will consult the output
> >    of 'scripts/get_maintainers.pl' and automatically CC anyone listed
> >    as maintainers of the affected code. Generally you should accept the
> >    suggested CC list, but there may sometimes be scenarios where it is
> >    appropriate to cut it down (eg on certain large tree-wide cleanups),
> >    or augment it with other interested people"
> >
> > Second, lets say something about pull requests
> >
> >   "When a subsystem maintainer is ready to send a pull request, the
> >    'git publish --pull' command will triggering GPG tag signing,
> >    publish the branch to the git remote name specified by the
> >    'remote.pushDefault' config option, and send the email series'
> 
> We don't do pull requests for the normal "end developer submits
> a patch" process, and given the prevalence of the github/gitlab
> "all contributions go in as pull requests" model, I think that
> talking about pull requests here (except to say "we don't do them")
> would be confusing. If we want to document how you can use git publish
> for pull request submission we can do that in
> docs/devel/submitting-a-pull-request.rst.

Ah yes, I agree with that.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]