[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] [linux-2.6.39.x for xen] tmem: self-ballooning and frontswap-selfshrinking
On Tue, 2011-06-07 at 17:59 +0100, Dan Magenheimer wrote: > > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx] > > > > > > Although you're right, as I am fresh off a 2-1/2 year odyssey of > > > upstreaming cleancache, AND since this is almost certainly Xen > > > specific AND since there will likely be some changes over time > > > which could conceivably make this unnecessary, I would be content > > > with carrying this in a Xen-only tree for the foreseeable future. > > > > As someone who is fresh of a 5+ year odyssey of upstreaming a Xen-only > > tree into mainline I must strongly object to this approach. > > > > We have had a long uphill battle to get ourselves to the state we are in > > today and the approach you are suggesting is absolutely counter to the > > philosophy we have built up whilst doing that and accepting this undoes > > all of the good work up until now. > > > > Getting stuff into a Xen tree is not an aim in and of itself but merely > > a conduit towards upstream. Nothing should be going into the Xen stable > > trees with the explicit aim of staying there for the foreseeable future. > > > > If you want to run a tmem-only tree with stuff you don't intend to send > > upstream yet in it then that is your prerogative, please don't ask the > > rest of us to carry that burden. > > Well that's a bit harsh. Perhaps I should clarify: By "for the > foreseeable future", I meant I don't expect it to be a candidate > for 3.1 or probably even 3.2. I didn't mean to imply that > I wasn't going to try, just that I wasn't going to try for 3.1. I think that's fine, but your initial statement sounded a lot less positive and had me quite worried. The old attitude of getting something into the Xen tree as an end goal and leaving the rest to someone else (or no one at all) is something which needs to be stomped on hard (I'm talking more generally now, you've explained this specific case) > I see Konrad's tree as kind of a linux-next specific to Xen where > Xen-ish functionality/fixes can be exposed "officially" to Xen users > before the upstreaming battle is fought. linux-next is very specifically about stuff which is ready for the next merge window, i.e. stuff which a maintainer intends to send along to Linus when the merge window opens. It is also explicitly not for works in progress. You have a tree in linux-next so I assume you have seen and read Stephen's boilerplate intro. I think that exposing Xen users to features which have not been proposed upstream (whether due to fears of "battles" or otherwise) does neither our users nor us any favours in the long run. Once things are exposed to users in an official way they begin to build expectations and requirements and when such features are subsequently taken upstream it is trying to retain these while addressing upstream concerns and requests for change which is one of the most frequent sources of so called battles and other tensions. The specific hunk which spawned this sub-thread (exporting something from mm/mmap.c) is exactly the sort of change which can lead to tension if it is not discussed with the mm maintainers early on. IMHO it is much better to simply work with upstream, with upstreaming in mind from day one and to release early and often to LKML and to encourage Xen contributors (who are really Linux contributors in this context) to behave in that way also. > I've had many requests > for tmem over the last couple of years but haven't had a good > foundation for delivery. Every developer always has the option of setting up a git tree and publishing specific branches or of posting regular patch kits on LKML etc etc. That is how everyone treats their development work without asking for it to be included in a subsystem tree before it is actually ready or has been through review etc. > Are you saying nothing should go in > Konrad's tree unless it is immediately upstreamable? It is up to Konrad what he includes in his tree. I think the main thing here is to stop thinking in terms of Xen and "upstream" trees as separate things. The Linux trees which Xen maintainers publish are part of the upstream workflow as much as the tip.git or block/net subsystem maintainer's trees and should be treated as such. There really should be no _concept_ of an official Xen tree other than as part of the flow from contributors to upstream. IOW there would ideally only be the various Xen maintainer's linux-next branches and nothing more official than that. However if we really feel there is a need for there to be branches (whichever tree they live in) which we (test and) bless as official Xen.org trees then I think we should aim to be as close to upstream as we are able (and these days we are in a very good position to achieve this aim) and that means those branches are effectively equivalent to either a linux-next style branch where patches in that tree are believed to be stable and ready for upstream or a stable/longterm style branch containing backports of already upstreamed patches (in the case of base versions maintained for longer than normal term). So in the case of official branches, yes, I think its contents should, by definition, be ready for upstream. I originally wrote about this need to switch how we as a community thinks about "Linux upstream" last year, see: http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00078.html I don't think anything much has changed except that we are in an even better position WRT upstream so the arguments for working with upstream first and foremost are even stronger. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |