All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: lars.kurth@xen.org
Cc: "George.Dunlap@citrix.com" <George.Dunlap@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Hackathon Minutes] Xen 4.4 Planning
Date: Thu, 13 Jun 2013 15:43:12 +0100	[thread overview]
Message-ID: <51B9DA80.7090107@eu.citrix.com> (raw)
In-Reply-To: <51B9D08E.4000905@xen.org>

On 13/06/13 15:00, Lars Kurth wrote:
> This took me a while to post, but given that we are not starting 4.4 
> just yet, this may be appropriate now. I may have misrepresented some 
> stuff as it has been 4 weeks since I wrote these.
> Cheers
> Lars
>
> = Purpose of Roadmap =
> * Set a vision for interesting features
> * Track items
> * Help consumers of Xen with their planning
>
> = Release Models that work well =
> There was a brief discussion on two different release models
> * Train leaves the station (Linux)
> * Release when ready (Debian)
>
> == Stefano's Proposal ==
> We should aim to reduce the release cycle to 4 months (or maybe 6 
> months as an intermediate step) from the current 9 months. A 4 months 
> relase cycle should help accelerate development and lead to fewer 
> patches being queued up. The implications are that we would have to 
> operate a 2-3 weeks merge window.
>
> To do this, we would need to resolve a number of issues
> * It is likely that code reviews for such a short merge window would 
> become a bottleneck. We are not sure whether this would be a major 
> issue : the review bandwith would depend on the patches submitted (and 
> their complexity)
> * [I can't remember who raised this] The concern was raised that we 
> would not have enough x86 Xen reviewers got a 2-3 weeks merge window
> * [Konrad] Stated that in PVOPS for Linux contributions we don't have 
> a review bottleneck, but we should make sure that the Xen and 
> PVOPS/Linux merge window don't overlap (as this would require the same 
> set of people to review patches in two projects)
> * The rest of the time (approx 3 months) would be used for stabilizing 
> the release

Why would we need 3 months to do testing for 2 weeks of merging (or 4 
months of development, depending on how you look at it), when 6 weeks 
has been just about right for 9 months of "merging"?

I think it takes that long for Linux because it's such a gigantic 
project.  I would think 3 months development / 1 month stabilization 
would be OK for Xen.

I would rather avoid the "merge window" workflow until it becomes really 
necessary, as it adds all kinds of other issues (e.g., needing something 
like linux-next to detect and sort out merge conflicts ahead of the 
merge window).

  -George

  parent reply	other threads:[~2013-06-13 14:43 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-13 14:00 [Hackathon Minutes] Xen 4.4 Planning Lars Kurth
2013-06-13 14:22 ` Jan Beulich
2013-06-13 15:11   ` George Dunlap
2013-06-13 15:30     ` Jan Beulich
2013-06-13 15:39       ` Ian Campbell
2013-06-17  8:27         ` Fabio Fantoni
2013-06-17  9:52           ` Ian Campbell
2013-06-13 14:31 ` Ian Campbell
2013-06-13 14:52   ` George Dunlap
2013-06-13 15:06     ` Ian Campbell
2013-06-14 17:41   ` Konrad Rzeszutek Wilk
2013-06-13 14:43 ` George Dunlap [this message]
2013-06-13 17:09 ` Ben Guthro
2013-06-13 18:07   ` Pasi Kärkkäinen
2013-06-13 21:03 ` Alex Bligh
2013-06-13 23:56   ` Ian Murray
2013-06-14  7:01     ` Alex Bligh
2013-06-14  9:46       ` Ian Murray
2013-06-14 11:53         ` Alex Bligh
2013-06-14 12:32           ` Ian Murray
2013-06-14 12:49             ` Alex Bligh
2013-06-14 13:34               ` Ian Murray
2013-06-14 13:55                 ` Ian Campbell
2013-06-14 14:44                   ` Ian Murray
2013-06-14 14:55                     ` Gordan Bobic
2013-06-14 15:00                       ` George Dunlap
2013-06-14 15:09                     ` Ian Campbell
2013-06-14 15:43                   ` Alex Bligh
2013-06-14 21:05                     ` Ian Murray
2013-06-19 21:22                     ` Alex Bligh
2013-06-14 15:44                 ` Alex Bligh
2013-06-14 17:25         ` Konrad Rzeszutek Wilk
2013-06-14  8:15   ` Jan Beulich
2013-06-14  9:47     ` George Dunlap
2013-06-14  9:59     ` Lars Kurth
2013-06-14 10:45       ` Jan Beulich
2013-06-14 11:19         ` George Dunlap
2013-06-14 11:30         ` Gordan Bobic
2013-06-14 12:10       ` Sander Eikelenboom
2013-06-14 10:44   ` George Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2013-06-14 11:46 Alex Bligh
2013-06-14 12:26 ` Jan Beulich
2013-06-14 12:45   ` Alex Bligh
2013-06-14 18:55 Alex Bligh

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=51B9DA80.7090107@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=lars.kurth@xen.org \
    --cc=xen-devel@lists.xen.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.