xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Steven Haigh <netwiz@crc.id.au>
Subject: Re: RFC: LTS and stable release scheme
Date: Thu, 8 Oct 2015 13:49:03 +0200	[thread overview]
Message-ID: <5616582F.5000303@suse.com> (raw)
In-Reply-To: <561670CD02000078000A94AA@suse.com>

On 10/08/2015 01:34 PM, Jan Beulich wrote:
>>>> On 08.10.15 at 12:59, <Ian.Jackson@eu.citrix.com> wrote:
>> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
>>> Perhaps there's room for further automation here, yet as with
>>> any automation the question is how quickly getting this in place
>>> will amortize itself.
>>
>> Even with the current situation I think much more automation would be
>> good.  (But then I'm someone who really (a) likes automating things
>> (b) likes sitting back and watching the automation do its thing and
>> even (c) likes debugging the automation when it goes wrong.)
>>
>> I think that maybe as a starting point, Jan and I could agree that
>> instead of build-testing our backports locally, we will throw them at
>> osstest and see what sticks.
>
> Well, yes, we could. Otoh the overhead of fixing something that
> didn't build but got committed already means more mechanical
> work (revert, or create a fixup patch) compared to fixing it before
> pushing to the respective staging tree.
>
> What I would see as possibly useful would be a queue like thing
> where backports could be added, and automation would take
> care of committing and pushing as much of it as it can validate
> to build (more severe problems are pretty rare in stable trees,
> and hence relying on the normal osstest there like we do now
> would seem reasonable). Yet again this would mean one may
> have to turn attention to the respective tree more often (since
> right now this is needed just once for each batch of backports,
> unless something really odd happens).

Couldn't that purely mechanical work be spread to others? I can't
believe this would require exceptional skills and I think your
time is to precious for stuff like that.

In the beginning the workflow could be the same as yours today,
there would be just the queue you mentioned and someone either
doing the builds and committing or just look after the results
of any automatism. It just wouldn't be you.


Just my 0.02€, Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2015-10-08 11:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06 11:07 RFC: LTS and stable release scheme Wei Liu
2015-10-06 12:57 ` George Dunlap
2015-10-06 13:10 ` Ian Campbell
2015-10-06 16:25   ` Wei Liu
2015-10-06 16:30     ` Ian Campbell
2015-10-06 13:15 ` Wei Liu
2015-10-06 13:38 ` Jan Beulich
2015-10-06 14:09   ` Wei Liu
2015-10-06 14:52     ` Jan Beulich
2015-10-06 15:01       ` Wei Liu
2015-10-07 17:45       ` George Dunlap
2015-10-08  8:05         ` Jan Beulich
2015-10-08 10:39           ` George Dunlap
2015-10-08 11:48             ` Jan Beulich
2015-10-08 10:59           ` Ian Jackson
2015-10-08 11:34             ` Jan Beulich
     [not found]             ` <561670CD02000078000A94AA@suse.com>
2015-10-08 11:49               ` Juergen Gross [this message]
2015-10-08 12:22                 ` Jan Beulich
     [not found]                 ` <56167C0802000078000A953E@suse.com>
2015-10-08 12:39                   ` Juergen Gross
2015-10-08 13:52                     ` Wei Liu
2015-10-08 11:10           ` Wei Liu
2015-10-08 12:13             ` Jan Beulich
2015-10-08 14:23               ` Wei Liu
2015-10-08 15:01                 ` Jan Beulich
2015-10-08 11:10           ` George Dunlap
2015-10-06 14:12   ` George Dunlap
2015-10-06 14:49     ` Jan Beulich
2015-10-07 17:56   ` George Dunlap
2015-10-08  8:15     ` Jan Beulich
2015-10-06 15:27 ` Dario Faggioli

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=5616582F.5000303@suse.com \
    --to=jgross@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=ian.campbell@citrix.com \
    --cc=lars.kurth@citrix.com \
    --cc=netwiz@crc.id.au \
    --cc=wei.liu2@citrix.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).