From: Andrew Morton <akpm@osdl.org>
To: Greg KH <greg@kroah.com>
Cc: pavel@ucw.cz, drzeus-list@drzeus.cx, torvalds@osdl.org,
pasky@ucw.cz, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6.12-rc3
Date: Sun, 24 Apr 2005 03:26:22 -0700 [thread overview]
Message-ID: <20050424032622.3aef8c9f.akpm@osdl.org> (raw)
In-Reply-To: <20050423233809.GA21754@kroah.com>
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.
next prev parent reply other threads:[~2005-04-24 10:27 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-21 0:59 Linux 2.6.12-rc3 Linus Torvalds
2005-04-21 1:09 ` Alejandro Bonilla
2005-04-21 1:26 ` James Purser
2005-04-21 1:38 ` Patrick McFarland
2005-04-21 2:01 ` Alejandro Bonilla
2005-04-21 4:03 ` Barry K. Nathan
2005-04-21 8:17 ` Martin Schlemmer
2005-04-21 8:49 ` Jan Dittmer
2005-04-21 8:59 ` Jan Dittmer
2005-04-21 9:10 ` Geert Uytterhoeven
2005-04-21 16:11 ` Al Viro
2005-04-21 17:39 ` Al Viro
2005-04-22 22:18 ` Roman Zippel
2005-05-30 23:48 ` more thread_info patches Roman Zippel
2005-05-30 23:50 ` Roman Zippel
2005-05-30 23:51 ` Roman Zippel
2005-05-31 12:16 ` Vincent Hanquez
2005-05-30 23:52 ` Roman Zippel
2005-05-31 1:25 ` randy_dunlap
2005-05-31 9:35 ` Roman Zippel
2005-05-31 15:37 ` randy_dunlap
2005-04-21 17:45 ` Linux 2.6.12-rc3 Al Viro
2005-04-21 17:57 ` Al Viro
2005-04-21 18:08 ` Al Viro
2005-04-25 19:14 ` Geert Uytterhoeven
2005-04-26 3:24 ` Al Viro
2005-04-26 8:21 ` Geert Uytterhoeven
2005-04-21 18:04 ` Al Viro
2005-04-25 19:12 ` Geert Uytterhoeven
2005-04-21 11:20 ` Pavel Machek
2005-04-21 12:03 ` Pavel Machek
2005-04-21 16:22 ` Petr Baudis
2005-04-21 19:00 ` Pavel Machek
2005-04-21 19:09 ` Petr Baudis
2005-04-21 21:38 ` Pavel Machek
2005-04-21 21:41 ` Petr Baudis
2005-04-23 21:31 ` Pavel Machek
2005-04-21 23:22 ` Pavel Machek
2005-04-21 23:33 ` Linus Torvalds
2005-04-22 0:21 ` Petr Baudis
2005-04-22 23:18 ` Pavel Machek
2005-04-23 0:21 ` Linus Torvalds
2005-04-23 11:19 ` Pavel Machek
2005-04-23 14:15 ` Linus Torvalds
2005-04-23 16:27 ` Pierre Ossman
2005-04-23 22:02 ` Greg KH
2005-04-23 22:29 ` Pavel Machek
2005-04-23 23:38 ` Greg KH
2005-04-24 10:26 ` Andrew Morton [this message]
2005-04-24 17:44 ` Linus Torvalds
2005-04-24 19:06 ` Sam Ravnborg
2005-04-24 19:55 ` Greg KH
2005-04-24 20:17 ` Pavel Machek
2005-04-24 20:29 ` Pavel Machek
2005-04-24 22:48 ` David S. Miller
2005-04-24 23:17 ` Marcel Holtmann
2005-04-25 7:40 ` Anton Altaparmakov
2005-04-26 5:25 ` Len Brown
2005-04-26 5:50 ` Andrew Morton
2005-04-23 23:00 ` Pavel Machek
2005-04-23 23:06 ` Petr Baudis
2005-04-24 7:21 ` Pavel Machek
2005-04-24 7:35 ` Dmitry Torokhov
2005-04-24 5:45 ` Greg KH
2005-04-23 12:21 ` Ed Tomlinson
2005-04-23 23:23 ` Petr Baudis
2005-04-24 7:25 ` Pavel Machek
2005-04-21 12:18 ` Martin Schlemmer
2005-04-22 7:55 ` H. Peter Anvin
2005-04-21 12:19 ` Ralf Hildebrandt
2005-04-21 15:45 ` Randy.Dunlap
2005-04-21 13:33 ` Andreas Steinmetz
2005-04-22 0:31 ` Greg KH
2005-04-21 14:24 ` Linux 2.6.12-rc3: Oops on IDE flash disk eject Andreas Steinmetz
2005-04-21 15:27 ` Andreas Steinmetz
2005-04-21 17:00 ` Linux 2.6.12-rc3: various swsusp problems Andreas Steinmetz
2005-04-21 18:57 ` Pavel Machek
2005-04-21 20:02 ` Andreas Steinmetz
2005-04-25 9:50 ` Pavel Machek
2005-04-21 20:55 ` Andreas Steinmetz
2005-04-22 15:13 ` Stefan Seyfried
2005-04-23 2:57 ` Dmitry Torokhov
2005-04-23 8:18 ` Stefan Seyfried
2005-04-23 9:14 ` Pavel Machek
2005-04-21 19:10 ` Linux 2.6.12-rc3 Benoit Boissinot
2005-04-22 7:56 Borislav Petkov
2005-04-24 5:42 ` Greg KH
2005-04-24 6:27 ` Borislav Petkov
2005-04-24 7:30 ` Christoph Hellwig
[not found] <3VIcq-8ls-9@gated-at.bofh.it>
[not found] ` <3VIFr-px-7@gated-at.bofh.it>
[not found] ` <3VMJj-3Hv-61@gated-at.bofh.it>
[not found] ` <3VThx-16N-7@gated-at.bofh.it>
[not found] ` <3VUnf-1Ua-21@gated-at.bofh.it>
[not found] ` <3WfL8-33i-15@gated-at.bofh.it>
[not found] ` <3WgH8-3LO-3@gated-at.bofh.it>
[not found] ` <3WqZS-3qK-21@gated-at.bofh.it>
[not found] ` <3WtEl-5Ao-11@gated-at.bofh.it>
[not found] ` <3WBVe-3Qn-11@gated-at.bofh.it>
[not found] ` <3WIaj-8vN-3@gated-at.bofh.it>
2005-04-24 15:10 ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050424032622.3aef8c9f.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=drzeus-list@drzeus.cx \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pasky@ucw.cz \
--cc=pavel@ucw.cz \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).