Greg KH <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
