Could somebody explain the purpose, maintainership, etc of the following trees? http://xenbits.xensource.com/linux-2.6-xen.hg http://xenbits.xensource.com/ext/linux-2.6.rc-xen.hg http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg I''ve been pursuing inclusion of xen-ia64 in fedora rawhide, and in the process learned that Juan uses these trees to generate the patch for fedora''s kernel rpm. This seems like a great approach (easier than using xen-unstable''s sparse tree) but before following Juan down this path, I''d like to understand the intended purpose of these trees, who maintains them, and ideally the mechanics of that maintenance. For example, linux-2.6-xen.hg seems to pull patches from xen-unstable, but it can''t be a direct pull because one is a xen tree, the other is a kernel tree, so how is it done? Thanks, Aron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Aron Griffis (aron@hp.com) wrote:> Could somebody explain the purpose, maintainership, etc of the > following trees? > > http://xenbits.xensource.com/linux-2.6-xen.hgPurpose: Normal Linux source tree view of linux-2.6-sparse. Maintainer: XenSource (primarily Christian is handling this)> http://xenbits.xensource.com/ext/linux-2.6.rc-xen.hgPurpose: Same as linux-2.6-xen.hg, but tracking ahead to -rc''s Maintainer: same as above, although it''s lagged a bit, probably due to redundancy of below.> http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hgPurpose: Same as linux-2.6.rc-xen.hg, but tracking ahead to -tip of linux. Maintainer: me, although I''ve lagged back to only tracking -rc''s. Basically, linux-2.6-xen is just effectively application of linux-sparse tree, and the others are the same plus are tracking closer to Linus'' tree.> I''ve been pursuing inclusion of xen-ia64 in fedora rawhide, and in the > process learned that Juan uses these trees to generate the patch for > fedora''s kernel rpm.Juan''s tree is quite close to linux-2.6.tip-xen.hg (of course with addition of fedora merges).> This seems like a great approach (easier than using xen-unstable''s > sparse tree) but before following Juan down this path, I''d like to > understand the intended purpose of these trees, who maintains them, > and ideally the mechanics of that maintenance. For example, > linux-2.6-xen.hg seems to pull patches from xen-unstable, but it can''t > be a direct pull because one is a xen tree, the other is a kernel > tree, so how is it done?Going from xen-unstable to linux-2.6-xen is largely scripted (although it needs human attention). The rest of the merging is automated to the degree that SCM''s can help, final bit of conflict resolution being manual, of course. thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2006-06-05 at 09:08 -0700, Chris Wright wrote: [ Nice chris explanation of the trees ]> Juan''s tree is quite close to linux-2.6.tip-xen.hg (of course with > addition of fedora merges).Basically, my tree is similar than linux-2.6.tip-xen. They are supposed to be the same, but _I_ really merge linux-2.6 & linux-2.6-xen daily, because rawhide kernels are released with the git of the day :p Tree is not published waiting for a machine with decent conection and xen installed (should happenn soon).> > This seems like a great approach (easier than using xen-unstable''s > > sparse tree) but before following Juan down this path, I''d like to > > understand the intended purpose of these trees, who maintains them, > > and ideally the mechanics of that maintenance. For example, > > linux-2.6-xen.hg seems to pull patches from xen-unstable, but it can''t > > be a direct pull because one is a xen tree, the other is a kernel > > tree, so how is it done? > > Going from xen-unstable to linux-2.6-xen is largely scripted (although > it needs human attention). The rest of the merging is automated to the > degree that SCM''s can help, final bit of conflict resolution being > manual, of course.That is my understanding also :) Since I use linux-2.6-xen instead of xen-unstable, my life has been way, way better :) Until now, I had the previous unstable patch and the new one, and have to apply it, and look for differences. Now hg inccoming -p Show me differences in changesets, and once that I merge anything, the scm "remembers it, and I don''t have to re-merge it again. Later, Juan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Chris, that''s a huge help. Aron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/5/06, Chris Wright <chrisw@sous-sol.org> wrote:> Going from xen-unstable to linux-2.6-xen is largely scripted (although > it needs human attention). The rest of the merging is automated to the > degree that SCM''s can help, final bit of conflict resolution being > manual, of course.Yes, it''s pretty much automated now, all I do is sanity check the result before it goes out. There''s a few corner cases which can cause trouble: - add/delete of files to the sparse tree: * add can be dropped iff the file is added first and only changed in a seperate changeset * delete needs to restore the file to the unchanged version - merges and long lived branches: Since the process linearizes the changesets, merges can usually be dropped (unless they sneak in changes...) This becomes a bit tricker with long lived branches, especially when there are merges back from xen-unstable -- we have those regularly in the xen-unstable-ia64 tree and try to avoid them otherwise. - 2.6.16 vs 2.6.16.13 differences: xen-unstable is based on 2.6.16.13 while linux-2.6-xen is based on 2.6.16 christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel