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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

  • To: Wei Liu <wei.liu2@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Thu, 5 Jul 2018 10:31:10 +0200
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb
  • Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, "advisory-board@xxxxxxxxxxxxxxxxxxxx" <advisory-board@xxxxxxxxxxxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Rich Persaud <persaur@xxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 05 Jul 2018 08:31:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 05/07/18 09:53, Wei Liu wrote:
> On Wed, Jul 04, 2018 at 03:26:16PM +0000, George Dunlap wrote:
>>> On Jul 3, 2018, at 11:07 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>> On Mon, Jul 02, 2018 at 06:03:39PM +0000, Lars Kurth wrote:
>>>> We then had a discussion around why the positive benefits didn't 
>>>> materialize:
>>>> * Andrew and a few other believe that the model isn't broken, but that the 
>>>> issue is with how we 
>>>>   develop. In other words, moving to a 9 months model will *not* fix the 
>>>> underlying issues, but 
>>>>   merely provide an incentive not to fix them.
>>>> * Issues highlighted were:
>>>>   * 2-3 months stabilizing period is too long
>>> I think one of the goals with the 6 month release cycle was to shrink
>>> the stabilizing period, but it didn't turn that way, and the
>>> stabilizing period is quite similar with a 6 or a 9 month release
>>> cycle.
>> Right, and I think this was something that wasn’t quite captured in Lars’ 
>> summary.
>> Everyone agreed:
>> 1. The expectation was that a shorter release cycle would lead to shorter 
>> stabilization periods
>> 2. This has not turned out to be the case, which means
>> 3 At the moment, our “time doing development” to “time fixing bugs for a 
>> release” ratio is far too low.
>> One option to fix #3 is to go back to a 9-month cycle (or even a
>> 12-month cycle), which would increase the “development” part of the
>> equation.
> You get more changes in, you also get more bugs.  Assuming bugs are
> introduced at a constant rate in relation to changes, moving back to 9
> months won't help.

Uuh, why not? It isn't as if no bugs are found and corrected in the
development period. As long as the development period is longer than
the average time between OSSTEST pushs the stabilization period should
be roghly constant. So a longer development period will result in a
better ratio development / stabilization.

> At least in my experience, a majority of time during the freeze is spent
> on *waiting*. Waiting for osstest to turn around, waiting for security
> issues to become public. Moving to 9 months won't change those factors.

But waiting isn't a factor, it is a constant, assuming the number of
unresolved bugs at the end of the development period is roughly the
same. And that will be the case if we don't:

a) pay no attention to OSSTEST results during development (i.e. trying
   to get pushs as often as possible)

b) rush most series in at the end of the development period

> A typical bug would need five working days (one week) to fix.
> 1. Someone report or osstest reports a bug. (Day 1)
> 2. Someone analyses it and writes a patch. (Day 2)
> 3. Someone reviews it. (Day 2 or 3).
> 4. Someone commits it. (Day 3 or 4).
> 5. Osstest produces test results (Day 3 to 5).
> For a simple bug, we might finish 1-4 in one day. But we still need to
> allow for at least two days to get a push.

In case of OSSTEST often enough multiple bugs are reported in parallel
and can (and should) be processed concurrently.

> In reality, a number of factors actually prolong getting things fixed
> (in the sense that patches are pushed to master): 1. bug fixes are
> incomplete; 2. hardware issues in test system; 3. other random hiccups.
> Should any of these happens, another 2 to 3 days is required to get
> patches pushed.

4. rarely triggering bugs which have been ignored before re-surface
and cause delays


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.