All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Iurii Artemenko <Iurii_Artemenko@epam.com>,
	Wei Liu <wei.liu2@citrix.com>, Doug Goldstein <cardoe@cardoe.com>,
	Minios-devel <minios-devel@lists.xenproject.org>,
	committers@xenproject.org,
	xen-devel <xen-devel@lists.xenproject.org>,
	Matt Spencer <Matt.Spencer@arm.com>
Subject: Re: automation: Creating a patchwork instance to improve pre-commit build testing
Date: Tue, 24 Jul 2018 10:43:52 +0100	[thread overview]
Message-ID: <20180724094352.bobqiacujy4tgcp4@citrix.com> (raw)
In-Reply-To: <5B56F2BB02000078001D7130@prv1-mh.provo.novell.com>

On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 11:24, <wei.liu2@citrix.com> wrote:
> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> >>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
> >> > # How does this impact me?
> >> > The contribution workflow is *not* impacted by this change, but once up and 
> > 
> >> > running the following will happen once you post a patch or patch series to 
> >> > xen-devel:
> >> > * Patchwork will take patch series from the mailing list and applies it
> >> > * CI/DC testing is triggered
> >> > * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
> >> > 
> >> > This does mean though that series which do not build or show other issues, 
> >> > will likely not be reviewed until the tests pass. This would lessen the 
> >> > burden on reviewers, as they will know whether the code submitted builds on a 
> >> > wide array of environments. 
> >> 
> >> So how are dependencies between series intended to be dealt with? It
> >> is not uncommon for someone to say "applies only on top of xyz". The
> >> implication of "will likely not be reviewed until the tests pass" seems
> >> unsuitable to me in such a case.
> >> 
> > 
> > We have been asking everyone to rebase to staging before posting a new
> > version for a long time.  It is natural for the bot to assume that
> > everything should apply on top of staging. That would provide most value
> > to the community.
> > 
> > For special cases like you just mention, we should aim to provide
> > mechanisms to manually appoint a branch to be tested.
> 
> I'm afraid I disagree again: Tools used should not be dictated. I'm
> using quilt, not git for my work, and hence I don't maintain any
> branches anywhere.

Alright.

First, I don't think I said that only git would be supported.
Git is the most prevalent VCS nowadays, and most developers use it, so
it would make sense to support it first.  If you want quilt, we can
certainly look into that. But I'm afraid if you don't say what you
specifically need, nothing can be done in that regard.

Second, it is up to individual whether they want to use a certain tool
or not. If you don't want to use this infrastructure for whatever
reason, that's OK. You're only missing out all the work in the community
has done, but you should be able to use your own workflow just fine.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-07-24  9:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23 16:40 automation: Creating a patchwork instance to improve pre-commit build testing Lars Kurth
2018-07-24  9:06 ` Jan Beulich
2018-07-24  9:14   ` Andrew Cooper
2018-07-24  9:31     ` Jan Beulich
2018-07-24  9:24   ` Wei Liu
2018-07-24  9:34     ` Jan Beulich
2018-07-24  9:43       ` Wei Liu [this message]
2018-07-24 10:04         ` Jan Beulich
2018-07-24 10:18           ` Wei Liu
2018-07-24 10:33             ` Lars Kurth
2018-07-24 10:50               ` Julien Grall
2018-07-24 11:23                 ` Lars Kurth
2018-07-24 14:26                   ` Anthony PERARD
2018-07-24 15:26                   ` George Dunlap
2018-07-24 15:32                     ` George Dunlap
2018-07-24 17:22                     ` Dario Faggioli
2018-07-24 15:16           ` Doug Goldstein
2018-07-24 10:09       ` Lars Kurth
2018-07-24 14:32       ` George Dunlap
2018-07-24 15:08         ` Doug Goldstein
2018-07-24  9:38     ` [Minios-devel] " Lars Kurth
2018-07-24  9:46       ` Wei Liu
2018-07-24  9:57         ` Lars Kurth
2018-07-24 13:10           ` Andrew Cooper
2018-07-24  9:26   ` Lars Kurth
2018-07-24 11:48     ` [Minios-devel] " Yuri Volchkov
2018-07-24 12:00       ` Jan Beulich
2018-07-24 12:45         ` Lars Kurth
2018-07-24 14:01           ` George Dunlap
2018-07-24 15:44             ` Jan Beulich
2018-07-24 15:51               ` George Dunlap
2018-07-24 14:05           ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180724094352.bobqiacujy4tgcp4@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Iurii_Artemenko@epam.com \
    --cc=JBeulich@suse.com \
    --cc=Matt.Spencer@arm.com \
    --cc=cardoe@cardoe.com \
    --cc=committers@xenproject.org \
    --cc=lars.kurth@citrix.com \
    --cc=minios-devel@lists.xenproject.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.