![]() | |||||||||||||
Messages in this thread |
Greg KH <greg@kroah.com> wrote: > > On Sun, Apr 24, 2005 at 12:29:46AM +0200, Pavel Machek wrote: > > Hi! > > > > > > > A word of warning: in many ways it's easier to work with patches. In > > > > > particular, if you want to have me merge from your tree, I require a > > > > > certain amount of cleanliness in the trees I'm pulling from. All of the > > > > > people who used to use BK to sync are already used to that, but for people > > > > > who didn't historically use BK this is going to be a learning experience. > > > > > > > > > > > > > Is there a summary available of the major issues here so that we who are > > > > new to this can get up to speed fairly quickly? > > > > > > The main issue is if you want to use git for development and accepting > > > patches from others, you need to be used to not using that git tree to > > > send patches to Linus. To send patches to him, do something like the > > > following: > > > - export the patches from your git tree > > > - pick and choose what you want to send off, cleaning up the > > > changelog comments and merging patches that need to be. > > > - clone the latest copy of Linus's tree. > > > - apply the patches to that tree. > > > - make the tree public > > > - generate an email with the diffs and send that off to lkml and > > > Linus. > > > > > > Because of all of this, I've found that it is easier to use quilt for > > > day-to-day development and acceptance of patches. Then use git to build > > > up trees for Linus to pull from. > > > > > > But you might find your workflow is different :) > > > > How does Andrew fit into this picture, btw? I thought all patches ought > > to go through him... Is Andrew willing to pull from git trees? Or is > > it "create one version for akpm, and when he ACKs it, create another > > for Linus"? > > Yeah, getting Andrew into the picture is a bit different. Andrew has some work to do before he can regain momentum: - Which subsystem maintainers will have public git trees? - Which maintainers will continue to use bk? - Can Andrew legally use the bk client? - Can Andrew legally use a bk client which won't go phut at cset 65535? - How do I do a bk `gcapatch' is there is no Linus bk tree to base it off? - If none of the above, which maintainers will put up-to-date raw patches in places where Andrew can get at them? I don't know how all this will pan out. I guess the next -mm won't have many subsystem trees and I'll gradually add them as things get sorted out. > Previously, > with bk, I could just have him pull from my trees, and generate a patch > from that. And actually, with git that would work just as well, so if > you make your git working trees public, he can pull from them and you're > fine. yup. > But with quilt it's different. That's why I make up a big patch which > is the sum of my individual patches and put them on a public site. > Right now you can see this at: > kernel.org/pub/linux/kernel/people/gregkh-2.6/ > The patches in that directory are the "rolled up" ones. The script > there is what I use to build these patches, if you want to do something > like it. I could aggregate a subsystem maintainer's quilt series into -mm of course. That would be nicer than a huge rollup for both code reviewing and for the old bsearch-to-find-the-regression process. Of course, quilt-based patches can be checked into an SCM and publically exported. Lots of people do that. > In the patches/ subdir below that one, is a mirror of my quilt patches > directory, series file and all. That way people can still see the > individual patches if they want to. > > Does this help some? It's all still under flux as to how this all > works, try something and go from there :) Yes, it would be nice to have gregkh's patches in -mm as individual patches. Of course, whatever gets done, I'd selfishly prefer that most (or even all) subsystem maintainers work the same way and adopt the same work practices. I guess it's too early to think about that, but if one maintainer (hint) were to develop and document a good methodology and toolset, others might quickly follow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-04-24 12:30 [W:0.979 / U:1.500 seconds] ©2003-2008 Jasper Spaans | |||||||||||||