Re: Linux 2.6.12-rc3

[Andrew Morton]

Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/