Hi Ian, with these I''m getting the impression we''re making it, just like for qemu, a requirement to use the xenbits mirror rather than the original as well, even more so given that the two post-1.6.3.1 commits the mirror now has don''t even exist in the upstream tree (yet), making this not even a mirror anymore. I really had hoped that we would bring down (rather than up) the number of private clones of upstream trees, and provide true mirrors on xenbits really just for developers'' convenience. Any word on the overall picture? Jan
On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:> Hi Ian, > > with these I''m getting the impression we''re making it, just like for qemu, > a requirement to use the xenbits mirror rather than the original as well, > even more so given that the two post-1.6.3.1 commits the mirror now > has don''t even exist in the upstream tree (yet), making this not even a > mirror anymore.I cherry picked both of those commits directly from the mainline SeaBIOS tree, so they are upstream.> I really had hoped that we would bring down (rather than up) the > number of private clones of upstream trees, and provide true mirrors > on xenbits really just for developers'' convenience. Any word on the > overall picture?The reality is that we will sometimes need to backport fixes to stable trees which are specific to Xen and which upstream declines to take into their own stable branch (e.g. because they need to balance the risk of taking a Xen thing against other non-Xen users of their stable branch). It is also possible that we will want to backport new features from upstream mainline in order to better expose them to Xen users and developers prior to a new upstream release occurring. For example I expect that the upstream qemu support for save/restore will fall into this category. In this case I should have asked upstream about a backport to their stable branch before taking them myself which I neglected to do, sorry. I have approached upstream about these two now and will fixup with the appropriate merging in 1.6.3-stable-xen if the decide to take them. The rules which I will be applying (and which e.g. Stefano will be applying for the qemu tree) will be similar to the upstream kernel stable rules -- primarily that a commit must be included in the relevant mainline branch before being proposed for backport. This ensures that the fork will be bounded due to being reset each time we rebase to a new upstream stable release. Ian.
>>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote: >> Hi Ian, >> >> with these I''m getting the impression we''re making it, just like for qemu, >> a requirement to use the xenbits mirror rather than the original as well, >> even more so given that the two post-1.6.3.1 commits the mirror now >> has don''t even exist in the upstream tree (yet), making this not even a >> mirror anymore. > > I cherry picked both of those commits directly from the mainline SeaBIOS > tree, so they are upstream.Then I may be tracking (and looking at) another mirror rather than upstream. What is "upstream" here?>> I really had hoped that we would bring down (rather than up) the >> number of private clones of upstream trees, and provide true mirrors >> on xenbits really just for developers'' convenience. Any word on the >> overall picture? > > The reality is that we will sometimes need to backport fixes to stable > trees which are specific to Xen and which upstream declines to take into > their own stable branch (e.g. because they need to balance the risk of > taking a Xen thing against other non-Xen users of their stable branch). > > It is also possible that we will want to backport new features from > upstream mainline in order to better expose them to Xen users and > developers prior to a new upstream release occurring. For example I > expect that the upstream qemu support for save/restore will fall into > this category. > > In this case I should have asked upstream about a backport to their > stable branch before taking them myself which I neglected to do, sorry. > I have approached upstream about these two now and will fixup with the > appropriate merging in 1.6.3-stable-xen if the decide to take them. > > The rules which I will be applying (and which e.g. Stefano will be > applying for the qemu tree) will be similar to the upstream kernel > stable rules -- primarily that a commit must be included in the relevant > mainline branch before being proposed for backport. This ensures that > the fork will be bounded due to being reset each time we rebase to a new > upstream stable release.Okay, thanks for the explanation. Jan
On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote:> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote: > >> Hi Ian, > >> > >> with these I''m getting the impression we''re making it, just like for qemu, > >> a requirement to use the xenbits mirror rather than the original as well, > >> even more so given that the two post-1.6.3.1 commits the mirror now > >> has don''t even exist in the upstream tree (yet), making this not even a > >> mirror anymore. > > > > I cherry picked both of those commits directly from the mainline SeaBIOS > > tree, so they are upstream. > > Then I may be tracking (and looking at) another mirror rather than > upstream. What is "upstream" here?git://git.seabios.org/seabios.git Are you looking at qemu''s mirror perhaps? Ian.
>>> On 28.02.12 at 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote: >> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote: >> >> Hi Ian, >> >> >> >> with these I''m getting the impression we''re making it, just like for qemu, >> >> a requirement to use the xenbits mirror rather than the original as well, >> >> even more so given that the two post-1.6.3.1 commits the mirror now >> >> has don''t even exist in the upstream tree (yet), making this not even a >> >> mirror anymore. >> > >> > I cherry picked both of those commits directly from the mainline SeaBIOS >> > tree, so they are upstream. >> >> Then I may be tracking (and looking at) another mirror rather than >> upstream. What is "upstream" here? > > git://git.seabios.org/seabios.gitThanks.> Are you looking at qemu''s mirror perhaps?Indeed. Jan