xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH raisin 3/4] Update config-4.6 and config-4.5 to point to stable branches
Date: Wed, 15 Jun 2016 17:11:13 +0100	[thread overview]
Message-ID: <57617E21.4060701@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1606151501490.18449@sstabellini-ThinkPad-X260>

On 15/06/16 15:02, Stefano Stabellini wrote:
> On Wed, 15 Jun 2016, George Dunlap wrote:
>> On 15/06/16 11:53, Stefano Stabellini wrote:
>>> On Wed, 15 Jun 2016, George Dunlap wrote:
>>>> On 15/06/16 11:24, Stefano Stabellini wrote:
>>>>> On Tue, 14 Jun 2016, George Dunlap wrote:
>>>>>> On 14/06/16 11:01, Stefano Stabellini wrote:
>>>>>>> On Tue, 14 Jun 2016, George Dunlap wrote:
>>>>>>>> On 14/06/16 10:40, Stefano Stabellini wrote:
>>>>>>>>> On Mon, 13 Jun 2016, George Dunlap wrote:
>>>>>>>>>> Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branches.
>>>>>>>>>>
>>>>>>>>>> And point the default libvirt to point to the libvirt 1.3.3
>>>>>>>>>> maintenance branch, rather than xen-tested-master.
>>>>>>>>>>
>>>>>>>>>> Also update OVMF revision for 4.6 to a version that builds with modern
>>>>>>>>>> gccs.
>>>>>>>>>>
>>>>>>>>>> Singed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>>>>>>>>
>>>>>>>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>>  configs/config-4.5     | 6 +++---
>>>>>>>>>>  configs/config-4.6     | 8 ++++----
>>>>>>>>>>  configs/config-master  | 3 +++
>>>>>>>>>>  configs/config-url-git | 2 +-
>>>>>>>>>>  4 files changed, 11 insertions(+), 8 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/configs/config-4.5 b/configs/config-4.5
>>>>>>>>>> index 4163b68..8db9a9d 100644
>>>>>>>>>> --- a/configs/config-4.5
>>>>>>>>>> +++ b/configs/config-4.5
>>>>>>>>>> @@ -1,8 +1,8 @@
>>>>>>>>>>  XEN_REVISION="origin/stable-4.5"
>>>>>>>>>> -QEMU_REVISION="master"
>>>>>>>>>> -QEMU_TRADITIONAL_REVISION="master"
>>>>>>>>>> +QEMU_REVISION="origin/stable-4.5"
>>>>>>>>>> +QEMU_TRADITIONAL_REVISION="origin/stable-4.5"
>>>>>>>>>>  SEABIOS_REVISION="rel-1.7.5"
>>>>>>>>>>  GRUB_REVISION="master"
>>>>>>>>>> -LIBVIRT_REVISION="origin/xen-tested-master"
>>>>>>>>>> +LIBVIRT_REVISION="origin/v1.3.3-maint"
>>>>>>>>>>  OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>>>>>>>>>>  LINUX_REVISION="master"
>>>>>>>>>> diff --git a/configs/config-4.6 b/configs/config-4.6
>>>>>>>>>> index e8b2a09..b003a30 100644
>>>>>>>>>> --- a/configs/config-4.6
>>>>>>>>>> +++ b/configs/config-4.6
>>>>>>>>>> @@ -1,8 +1,8 @@
>>>>>>>>>>  XEN_REVISION="origin/stable-4.6"
>>>>>>>>>> -QEMU_REVISION="master"
>>>>>>>>>> -QEMU_TRADITIONAL_REVISION="master"
>>>>>>>>>> +QEMU_REVISION="origin/stable-4.6"
>>>>>>>>>> +QEMU_TRADITIONAL_REVISION="origin/stable-4.6"
>>>>>>>>>>  SEABIOS_REVISION="rel-1.8.2"
>>>>>>>>>>  GRUB_REVISION="master"
>>>>>>>>>> -LIBVIRT_REVISION="origin/xen-tested-master"
>>>>>>>>>> -OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>>>>>>>>>> +LIBVIRT_REVISION="origin/v1.3.3-maint"
>>>>>>>>>> +OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
>>>>>>>>>>  LINUX_REVISION="master"
>>>>>>>>>> diff --git a/configs/config-master b/configs/config-master
>>>>>>>>>> index bd26ce3..fce7436 100644
>>>>>>>>>> --- a/configs/config-master
>>>>>>>>>> +++ b/configs/config-master
>>>>>>>>>> @@ -6,3 +6,6 @@ GRUB_REVISION="master"
>>>>>>>>>>  LIBVIRT_REVISION="origin/xen-tested-master"
>>>>>>>>>>  OVMF_REVISION="origin/xen-tested-master"
>>>>>>>>>>  LINUX_REVISION="master"
>>>>>>>>>> +
>>>>>>>>>> +# oss-tested branch
>>>>>>>>>> +LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
>>>>>>>>>
>>>>>>>>> Why keep this around? I would remove it.
>>>>>>>>
>>>>>>>> Because...
>>>>>>>>
>>>>>>>>>> diff --git a/configs/config-url-git b/configs/config-url-git
>>>>>>>>>> index 79813c4..614f522 100644
>>>>>>>>>> --- a/configs/config-url-git
>>>>>>>>>> +++ b/configs/config-url-git
>>>>>>>>>> @@ -3,6 +3,6 @@ QEMU_URL="git://xenbits.xen.org/qemu-xen.git"
>>>>>>>>>>  QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-traditional.git"
>>>>>>>>>>  SEABIOS_URL="git://xenbits.xen.org/seabios.git"
>>>>>>>>>>  GRUB_URL="git://git.savannah.gnu.org/grub.git"
>>>>>>>>>> -LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
>>>>>>>>>> +LIBVIRT_URL="git://libvirt.org/libvirt.git"
>>>>>>>>
>>>>>>>> ...here, the LIBVIRT_URL in config-url-git is set to the libvirt.org URL
>>>>>>>> so that the stable releases can be pointed to v1.3.3-maint instead. The
>>>>>>>> xen.org repo doesn't contain the v1.3.3-maint branch, and the
>>>>>>>> libvirt.org repo doesn't contain the 'xen-tested-master' branch.
>>>>>>>>
>>>>>>>> I admit this is a bit ugly, *almost* separating things entirely but then
>>>>>>>> not. But I don't see another easy way of having both the 1.3.3
>>>>>>>> maintenance branch and the oss-tested branch. (Unless we started having
>>>>>>>> osstest test the maintenance branch as well.)
>>>>>>>  
>>>>>>> I would drop git://xenbits.xen.org/libvirt.git and xen-tested-master
>>>>>>> entirely and just stick to v1.3.3-maint everywhere. Or the other way
>>>>>>> around.
>>>>>>
>>>>>> Well I assume that people building one of the releases want something
>>>>>> relatively stable and supported, so xen-tested-master is obviously
>>>>>> unsuitable (and might not actually be capable of building against Xen
>>>>>> versions older than a certain point due to the fact that libxl cannot be
>>>>>> both forward- and backward-compatible).  And I also assume that people
>>>>>> building with XEN_RELEASE="master" want the bleeding edge of everything
>>>>>> so that they can test new features (or indeed, so that they can write
>>>>>> new features).  So I think we actually do want both -- a maintenance
>>>>>> branch for releases, and xen-tested-master for developers and
>>>>>> bleeding-edge users.
>>>>>
>>>>> Sure, we need to support both, but do they really need to be both
>>>>> enabled in one of the example config files? We could just have the
>>>>> libvirt xenbits tree as a comment.
>>>>
>>>> Well for that matter, why have a config-master at all?  Just say how to
>>>> make one in the comments. :-)
>>>>
>>>> I thought part of the point of raisin was to be able to get up and
>>>> running with a reasonable template without having to read or change a
>>>> lot of the comments.  I don't really understand why anyone would want
>>>> the development versions of Xen and qemu, but the stable maintenance
>>>> release of libvirt.  Doesn't it make more sense to have "config-master"
>>>> get you the development versions of everything?
>>>
>>> The idea is to provide good templates and be very transparent on what
>>> get cloned and built. It's the transparency here that it is weakening:
>>> as a user I would prefer the libvirt tree not to change depending on the
>>> version I write in the main config file. As a user, I would be surprised
>>> if I saw this happening. That's why I was suggesting to keep to one
>>> libvirt tree. Or if you would like to have two, then make the choice
>>> obvious, not a consequence of a seemingly unrelated version setting.
>>
>> By "libvirt tree", you mean the location of the libvirt repository?
>>
>> I guess we have fairly different ideas about what users care about and
>> what they'd find unexpected. :-)  I as a user wouldn't care a bit about
>> URL I was downloading from, as long as I got the appropriate version.
>> And I would be quite surprised to specify the "master" config, and get
>> the bleeding edge of everything except libvirt.
>>
>> We could just have it point to libvirt-master I suppose.  That risks
>> having things in a broken state in the time between the inevitable
>> regressions are introduced in libvirt-master and the time they get
>> noticed and fixed.  But that doesn't seem to be terribly often these
>> days.  What do you think?
> 
> libvirt master is good. After all master is for developers, so it makes
> sense.

OK, cool.  While testing libvirt-master  I discovered that config-master
was broken anyway, because it was pointing to xen-tested-master for ovmf
and seabios as well, which don't actually exist (!).  New spin of the
series on its way.

 -George

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

  reply	other threads:[~2016-06-15 16:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 14:44 [PATCH raisin 0/4] Fixes for 4.6, update to 4.7 George Dunlap
2016-06-13 14:44 ` [PATCH raisin 1/4] components/xen: Actually disable rombios George Dunlap
2016-06-14  9:32   ` Stefano Stabellini
2016-06-13 14:44 ` [PATCH raisin 2/4] config: Separate config urls into a separate file George Dunlap
2016-06-14  9:34   ` Stefano Stabellini
2016-06-13 14:44 ` [PATCH raisin 3/4] Update config-4.6 and config-4.5 to point to stable branches George Dunlap
2016-06-14  9:40   ` Stefano Stabellini
2016-06-14  9:57     ` George Dunlap
2016-06-14 10:01       ` Stefano Stabellini
2016-06-14 10:10         ` George Dunlap
2016-06-15 10:24           ` Stefano Stabellini
2016-06-15 10:38             ` George Dunlap
2016-06-15 10:53               ` Stefano Stabellini
2016-06-15 11:13                 ` George Dunlap
2016-06-15 14:02                   ` Stefano Stabellini
2016-06-15 16:11                     ` George Dunlap [this message]
2016-06-13 14:44 ` [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes George Dunlap
2016-06-14  9:46   ` Stefano Stabellini
2016-06-14 10:03     ` George Dunlap
2016-06-14 10:08       ` Stefano Stabellini
2016-06-14 10:17         ` George Dunlap
2016-06-14 10:31           ` Stefano Stabellini
2016-06-14 10:34             ` George Dunlap
2016-06-14 13:53               ` Anthony PERARD
2016-06-14 14:00                 ` George Dunlap
2016-06-14 14:23                   ` Anthony PERARD
2016-06-14 14:38                     ` George Dunlap
2016-06-15 10:39                 ` Stefano Stabellini
2016-06-15 10:42                   ` George Dunlap

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=57617E21.4060701@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=sstabellini@kernel.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 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).