Hey Keir, I committed the last of the big outstanding tools blockers for 4.2 yesterday. Currently they are still in staging because they added some new xenstore paths which tickled the leak detector in the test system What do you think of doing an rc0 release next week? There''s still some smaller issues remaining but I think they can wait until rc1. Ian.
On 27/07/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:> Hey Keir, > > I committed the last of the big outstanding tools blockers for 4.2 > yesterday. Currently they are still in staging because they added some > new xenstore paths which tickled the leak detector in the test system > > What do you think of doing an rc0 release next week? > > There''s still some smaller issues remaining but I think they can wait > until rc1.We''ve never done an rc0 before. :) Yes, if the toolstack stuff is sorted sufficiently, we should definitely get on with the next step in the process! -- Keir> Ian. >
On Fri, 2012-07-27 at 11:34 +0100, Keir Fraser wrote:> On 27/07/2012 11:09, "Ian Campbell" <Ian.Campbell@citrix.com> wrote: > > > Hey Keir, > > > > I committed the last of the big outstanding tools blockers for 4.2 > > yesterday. Currently they are still in staging because they added some > > new xenstore paths which tickled the leak detector in the test system > > > > What do you think of doing an rc0 release next week? > > > > There''s still some smaller issues remaining but I think they can wait > > until rc1. > > We''ve never done an rc0 before. :)rc1 then ;-)> Yes, if the toolstack stuff is sorted sufficiently, we should definitely get > on with the next step in the process!We should give the test system a chance to push (Ian J just added the leak exception) and do it early next week sometime.> > -- Keir > > > Ian. > > > >
On Fri, 2012-07-27 at 11:54 +0100, Ian Campbell wrote:> > Yes, if the toolstack stuff is sorted sufficiently, we should definitely get > > on with the next step in the process! > > We should give the test system a chance to push (Ian J just added the > leak exception) and do it early next week sometime.We''ve now had a successful push. There are some fixes pending, but nothing mega-critical so I think we should go ahead with rc1. The release plan suggests weekly release candidates, does that work for you? If the overhead is burdensome we could go fortnightly. Ian.
On 30/07/2012 09:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:> On Fri, 2012-07-27 at 11:54 +0100, Ian Campbell wrote: >>> Yes, if the toolstack stuff is sorted sufficiently, we should definitely get >>> on with the next step in the process! >> >> We should give the test system a chance to push (Ian J just added the >> leak exception) and do it early next week sometime. > > We''ve now had a successful push. > > There are some fixes pending, but nothing mega-critical so I think we > should go ahead with rc1. > > The release plan suggests weekly release candidates, does that work for > you? If the overhead is burdensome we could go fortnightly.The actual steps to create an RC are pretty trivial. Do you want me to tag and sign an rc1 now? Is the qemu repo tagged with xen-4.2.0-rc1 yet? -- Keir> Ian. >
On Mon, 2012-07-30 at 13:28 +0100, Keir Fraser wrote:> On 30/07/2012 09:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote: > > > On Fri, 2012-07-27 at 11:54 +0100, Ian Campbell wrote: > >>> Yes, if the toolstack stuff is sorted sufficiently, we should definitely get > >>> on with the next step in the process! > >> > >> We should give the test system a chance to push (Ian J just added the > >> leak exception) and do it early next week sometime. > > > > We''ve now had a successful push. > > > > There are some fixes pending, but nothing mega-critical so I think we > > should go ahead with rc1. > > > > The release plan suggests weekly release candidates, does that work for > > you? If the overhead is burdensome we could go fortnightly. > > The actual steps to create an RC are pretty trivial. Do you want me to tag > and sign an rc1 now?Yes please. Modulo being blocked on:> Is the qemu repo tagged with xen-4.2.0-rc1 yet?Not so far as I know. Ian? Ian.
On 30/07/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:>> Is the qemu repo tagged with xen-4.2.0-rc1 yet? > > Not so far as I know. Ian?I think Ian also has a checklist of things to do before a major release. Might be worth running through those ahead of the first RC, too. -- Keir
Keir Fraser writes ("Re: [Xen-devel] Time for 4.2.0
rc0?"):> On 30/07/2012 13:37, "Ian Campbell"
<Ian.Campbell@citrix.com> wrote:
> > Not so far as I know. Ian?
>
> I think Ian also has a checklist of things to do before a major release.
> Might be worth running through those ahead of the first RC, too.
Looking at that:
- we aren''t branching now I take it, so the entries in it relating to
branching aren''t relevant
- the following entries may be relevant:
* consider bumping sonames of shlibs
I think we have been trying to do this as we went along.
Libraries which _aren''t_ updated are
libblktap.so.3.0 -> libblktap.so.3.0.0*
libblktapctl.so.1.0 -> libblktapctl.so.1.0.0*
libfsimage.so.1.0 -> libfsimage.so.1.0.0*
libvhd.so.1.0 -> libvhd.so.1.0.0*
libxenstat.so.0 -> libxenstat.so.0.0*
libxenstore.so.3.0 -> libxenstore.so.3.0.1*
libxenvchan.so.1.0 -> libxenvchan.so.1.0.0*
libxlutil.so.1.0 -> libxlutil.so.1.0.0*
and perhaps various usr/lib/fs/*, and ocaml and python modules.
I don''t think we''ve changed libxenstore incompatibly. The
others
are sufficiently internal or unchanged that we are content ?
* change xen-unstable README
Seems to have 4.2 in it already.
* change xen-unstable Config
I can''t see what this might refer to. Config.mk doesn''t
seem
to have a version number in it.
* change xen-unstable xen/Makefile XEN_EXTRAVERSION
I guess this will happen when we do the rc ?
And it''s RC1 we''re doing I guess, not RC0 ? If so I will tag
that in
the qemu trees.
Ian.
Ian Jackson writes ("Re: [Xen-devel] Time for 4.2.0
rc0?"):> And it''s RC1 we''re doing I guess, not RC0 ? If so I will
tag that in
> the qemu trees.
I have now tagged qemu-xen-traditional xen-4.2.0-rc1 and pushed it to
the usual places.
Ian.
On Mon, 2012-07-30 at 15:28 +0100, Ian Jackson wrote:> Keir Fraser writes ("Re: [Xen-devel] Time for 4.2.0 rc0?"): > > On 30/07/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote: > > > Not so far as I know. Ian? > > > > I think Ian also has a checklist of things to do before a major release. > > Might be worth running through those ahead of the first RC, too. > > Looking at that: > > - we aren''t branching now I take it, so the entries in it relating to > branching aren''t relevantRight.> - the following entries may be relevant: > > * consider bumping sonames of shlibs > > I think we have been trying to do this as we went along. > Libraries which _aren''t_ updated are > libblktap.so.3.0 -> libblktap.so.3.0.0*Part of tools/blktap. Nothing exciting looking under there.> libblktapctl.so.1.0 -> libblktapctl.so.1.0.0* > libvhd.so.1.0 -> libvhd.so.1.0.0*Parts of tools/blktap2. 24800:acf4ad70c87b "blktap2/libvhd: Build shared objects using -fPIC" might be interesting? 23055:a73a35527763 "tools: link each shared library or binary only against the libraries it uses" might be an ABI visible change? The rest look like uninteresting build system tweaks and the odd fix.> libfsimage.so.1.0 -> libfsimage.so.1.0.0*tools/libfsimage/, nothing jumps out.> libxenstat.so.0 -> libxenstat.so.0.0*Newly installed in 4.2, 23075:b4351d57464b> libxenstore.so.3.0 -> libxenstore.so.3.0.1*tools/xenstore contains 24376:32a3d86ae4a4 "libxenstore: Provide xs_check_watch" and 24507:19a0a2e26137 "xenstore: New function xs_path_is_subpath"> libxenvchan.so.1.0 -> libxenvchan.so.1.0.0*tools/libvchan is new in this release> libxlutil.so.1.0 -> libxlutil.so.1.0.0*23619:77a235e95b47 "libxl: disks: new xlu_disk_parse function"> and perhaps various usr/lib/fs/*, and ocaml and python modules. > > I don''t think we''ve changed libxenstore incompatibly. The others > are sufficiently internal or unchanged that we are content ?I did the above comparisons with hg log -r 4.1.0-branched:tip <paths> Looks like we wanht to bump libxenstore and libxlu. Possibly the blktap2 ones too, but they are pretty internal I guess.> * change xen-unstable Config > > I can''t see what this might refer to. Config.mk doesn''t seem > to have a version number in it.Don''t we switch QEMU_TAG to point to the tagged name instead of a SHA sum?> And it''s RC1 we''re doing I guess, not RC0 ? If so I will tag that in > the qemu trees.Yes, all my talk of rc0 was just me not checking what we''ve done before. It''s rc1 all the way.> > Ian.
Ian Campbell writes ("Re: [Xen-devel] Time for 4.2.0
rc0?"):> [changelogs]
Oh thanks for digging into that.
> Parts of tools/blktap2.
>
> 24800:acf4ad70c87b "blktap2/libvhd: Build shared objects using
-fPIC"
> might be interesting?
That''s not an ABI change either. It might warrant a minor bump.
> 23055:a73a35527763 "tools: link each shared library or binary only
> against the libraries it uses" might be an ABI visible change?
No, I don''t think it is.
> > libxenstore.so.3.0 -> libxenstore.so.3.0.1*
>
> tools/xenstore contains 24376:32a3d86ae4a4
> "libxenstore: Provide xs_check_watch" and 24507:19a0a2e26137
"xenstore:
> New function xs_path_is_subpath"
That warrants a minor bump, surely ? But not a soname change. Ie it
should be 3.0.2.
> > libxlutil.so.1.0 -> libxlutil.so.1.0.0*
>
> 23619:77a235e95b47 "libxl: disks: new xlu_disk_parse function"
Again I think that should be 1.0.1 then.
> Looks like we wanht to bump libxenstore and libxlu.
I agree.
> Possibly the blktap2 ones too, but they are pretty internal I guess.
Right.
> > * change xen-unstable Config
> >
> > I can''t see what this might refer to. Config.mk
doesn''t seem
> > to have a version number in it.
>
> Don''t we switch QEMU_TAG to point to the tagged name instead of a
SHA
> sum?
Yes. Perhaps that''s what that means...
Ian.
On Mon, 2012-07-30 at 15:56 +0100, Ian Jackson wrote:> > tools/xenstore contains 24376:32a3d86ae4a4 > > "libxenstore: Provide xs_check_watch" and 24507:19a0a2e26137 "xenstore: > > New function xs_path_is_subpath" > > That warrants a minor bump, surely ? But not a soname change. Ie it > should be 3.0.2.Yes, sorry, I was conflating the SONAME change with bumping the version generally. Minor is right.
On 30/07/2012 15:52, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:>> and perhaps various usr/lib/fs/*, and ocaml and python modules. >> >> I don''t think we''ve changed libxenstore incompatibly. The others >> are sufficiently internal or unchanged that we are content ? > > I did the above comparisons with > hg log -r 4.1.0-branched:tip <paths> > > Looks like we wanht to bump libxenstore and libxlu. > > Possibly the blktap2 ones too, but they are pretty internal I guess.Do you want to do these now? I deal with QEMU_TAG in Config.mk as part of making the -rc1 tag. -- Keir
Keir Fraser writes ("Re: [Xen-devel] Time for 4.2.0
rc0?"):> On 30/07/2012 15:52, "Ian Campbell"
<Ian.Campbell@citrix.com> wrote:
> > Possibly the blktap2 ones too, but they are pretty internal I guess.
>
> Do you want to do these now?
This should be done by a patch posted to the list really. We can
either post and apply it, or we can do the RC without it and bump the
patch numbers later.
Ian.
On Mon, 2012-07-30 at 16:09 +0100, Ian Jackson wrote:> Keir Fraser writes ("Re: [Xen-devel] Time for 4.2.0 rc0?"): > > On 30/07/2012 15:52, "Ian Campbell" <Ian.Campbell@citrix.com> wrote: > > > Possibly the blktap2 ones too, but they are pretty internal I guess. > > > > Do you want to do these now? > > This should be done by a patch posted to the list really. We can > either post and apply it, or we can do the RC without it and bump the > patch numbers later.Lets go ahead with RC1. I''ll add this to the TODO list as something to be done before release (ideally earlier rather than later in the RC cycle) Ian.
On 30/07/2012 16:12, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:> On Mon, 2012-07-30 at 16:09 +0100, Ian Jackson wrote: >> Keir Fraser writes ("Re: [Xen-devel] Time for 4.2.0 rc0?"): >>> On 30/07/2012 15:52, "Ian Campbell" <Ian.Campbell@citrix.com> wrote: >>>> Possibly the blktap2 ones too, but they are pretty internal I guess. >>> >>> Do you want to do these now? >> >> This should be done by a patch posted to the list really. We can >> either post and apply it, or we can do the RC without it and bump the >> patch numbers later. > > Lets go ahead with RC1. I''ll add this to the TODO list as something to > be done before release (ideally earlier rather than later in the RC > cycle)Okay, done. And I also pushed version update to 4.2.0-rc2-pre to tip, proactively. ;) -- Keir> Ian. >
>>> On 30.07.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Mon, 2012-07-30 at 15:28 +0100, Ian Jackson wrote: >> libxenstat.so.0 -> libxenstat.so.0.0* > > Newly installed in 4.2, 23075:b4351d57464bIs this an experimental, unsupported library? If not, I''d suggest making it .so.1 (and .so.1.0*)... Jan
On Mon, 2012-07-30 at 16:20 +0100, Jan Beulich wrote:> >>> On 30.07.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Mon, 2012-07-30 at 15:28 +0100, Ian Jackson wrote: > >> libxenstat.so.0 -> libxenstat.so.0.0* > > > > Newly installed in 4.2, 23075:b4351d57464b > > Is this an experimental, unsupported library? If not, I''d suggest > making it .so.1 (and .so.1.0*)...It''s the backend for xentop and I think a few other utils. It has existed for quite a while but for some reason wasn''t installed (xentop used to link statically). Ian.
Maybe Matching Threads
- xen-unstable unable to boot on Wheezy
- make install not creating lib entries in /usr/lib under Ubunu 11.10
- [PATCH 0 of 2 RESEND] tools: add two new compile flags and perform checks on user defined folders.
- [PATCH] blktap2: fix makefile of vhd for parallel make
- Regarding xenstat [test.c:3:24: fatal error: xenstat.h: No such file or directory]