Messages in this thread | | | Date | Sun, 24 Apr 2005 03:26:22 -0700 | From | Andrew Morton <> | Subject | Re: Linux 2.6.12-rc3 |
| |
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/
| |