Re: Linux 2.6.12-rc3

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Greg Kroah-Hartman
On Sun, Apr 24, 2005 at 03:26:22AM -0700, Andrew Morton wrote:
> Greg KH <[hidden email]> wrote:
> > 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.

It would?  Ok, that's easy to change.

> 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.

Heh, ok, I can take a hint, I'll work on this this week.  I already have
the "export a series of patches from a git tree that are not in another
git tree" working, so it shouldn't be tough to get the rest in an
"automated" manner.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Pavel Machek
Hi!

> > Greg KH <[hidden email]> wrote:
> > > 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.
>
> It would?  Ok, that's easy to change.
>
> > 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.
>
> Heh, ok, I can take a hint, I'll work on this this week.  I already have
> the "export a series of patches from a git tree that are not in another
> git tree" working, so it shouldn't be tough to get the rest in an
> "automated" manner.

I started to do something like that, but got to dead end (shared
object directories...). Maybe this is usefull to someone, and maybe
not...

                                                                Pavel

        Kernel hacker's guide to git
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      2005 Pavel Machek <[hidden email]>

You can get git at http://pasky.or.cz/~pasky/dev/git/ . Compile it,
and place it somewhere in $PATH. Then you can get kernel by running

mkdir clean-git; cd clean-git
git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

... Run git log to get idea of what happened in tree you are
tracking. Do git pull linus to pickup latest changes from Linus. You
can do git diff to see what changes you done in your local tree. git
cancel will kill any such changes.

You can commit changes by doing git commit... If you want to get diff
of your changes against mainline, do

git diff -r origin:

. If you want to get the same diff but separated patch-by-patch, do

git patch origin:

. (Does something unexpected after first merge).

To update your tree against name "foo", do:

        git track linus
        git pull

or

        git merge linus


How to set up your trees so that you can cooperate with linus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What I did:

Created clean-git. Initialized straight from Linus (as above). Then I
created my "dirty" working tree:

git fork pavel /data/l/linux-git

and created "nice" tree, good for pulling

git fork good /data/l/linux-good

. I do my work in linux-git. If someone sends me nice patch I should
pass up, I apply it to linux-good with nice message and do

git merge good

in my working tree.


Publishing your trees
~~~~~~~~~~~~~~~~~~~~~

on remote server: (as an optimization...)

cd ~/WWW/git
rsync -zavP rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git .
mv linux-2.6.git good.git

then on localhost:

cd /data/l/linux-good
rsync -zavP -essh --delete .git [hidden email]:~/WWW/git/good.git

[Oops, bad. cogito -created forks use symlinks in a way which is quite "interesting".]



--
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Pavel Machek-2
In reply to this post by Greg Kroah-Hartman
Hi!

> > > > 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?

I'd like to use git. It sucks for actuall development, but seems to be
very usefull for taking nice and clean patches from people...

> - Which maintainers will continue to use bk?
>
> - Can Andrew legally use the bk client?

I guess you need to Cc Larry on this one....
                                                                Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

David Miller-13
In reply to this post by Greg Kroah-Hartman
On Sun, 24 Apr 2005 03:26:22 -0700
Andrew Morton <[hidden email]> wrote:

> - Which subsystem maintainers will have public git trees?

I am pretty much exclusively using GIT for networking
and sparc stuff now and I plan to provide my trees
on kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Marcel Holtmann
In reply to this post by Greg Kroah-Hartman
Hi Andrew,

> - Which subsystem maintainers will have public git trees?

if someone gives me an account on kernel.org, I am happy to put the tree
for the Bluetooth subsystem there.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Anton Altaparmakov
In reply to this post by Greg Kroah-Hartman
Hi Andrew,

On Sun, 2005-04-24 at 03:26 -0700, Andrew Morton wrote:
> - Which subsystem maintainers will have public git trees?

Ntfs is not quite a subsystem, but if it would be possible for me to
have an account on kernel.org, I would be very happy to place .git trees
replacing the ntfs and ntfs-devel bk repositories there.  Otherwise I
have nowhere to host such beasts.

Best regards,

        Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Geert Uytterhoeven
In reply to this post by Greg Kroah-Hartman
On Thu, 21 Apr 2005, Al Viro wrote:

> On Thu, Apr 21, 2005 at 11:10:15AM +0200, Geert Uytterhoeven wrote:
> > On Thu, 21 Apr 2005, Jan Dittmer wrote:
> > > Linus Torvalds wrote:
> > > > Geert Uytterhoeven:
> > > >     [PATCH] M68k: Update defconfigs for 2.6.11
> > > >     [PATCH] M68k: Update defconfigs for 2.6.12-rc2
> > >
> > > Why do I still get this error when trying to cross-compile for m68k?
> >
> > Because to build m68k kernels, you (still :-( have to use the Linux/m68k CVS
> > repository, cfr. http://linux-m68k-cvs.ubb.ca/.
> >
> > BTW, my patch queue is at
> > http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/.
> > The main offender is POSTPONED/156-thread_info.diff.
>
> I think I have a sane splitup of that stuff.  If you have time to review - yell

Thanks a lot! Very well done!!

I did some (eyeball) review and the compiler liked it as well, so everything
seems OK.

Unfortunately due to various personal reasons I won't have time to test it on
real hardware anytime soon. But if anyone does, I'll take it for sure.

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Geert Uytterhoeven
In reply to this post by Greg Kroah-Hartman
On Thu, 21 Apr 2005, Al Viro wrote:
> As far as I can see that's the minimally intrusive header changes needed
> to avoid problems - better than variant with splitting sched.h as in m68k CVS.

We can discuss about that. IIRC, HCH is also in favor of splitting off struct
task_struct from sched.h.

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Al Viro
On Mon, Apr 25, 2005 at 09:14:01PM +0200, Geert Uytterhoeven wrote:
> On Thu, 21 Apr 2005, Al Viro wrote:
> > As far as I can see that's the minimally intrusive header changes needed
> > to avoid problems - better than variant with splitting sched.h as in m68k CVS.
>
> We can discuss about that. IIRC, HCH is also in favor of splitting off struct
> task_struct from sched.h.

Sure, but splitting sched.h is a separate story.  Mixing it with m68k
merge will only make both harder.  It requires more include reordering
and I'd rather keep that headache separate from m68k issues.  I agree
that eventual splitup of sched.h makes sense.  However, I think that
going for minimally intrusive variant of merge and then dealing with
sched.h would be easier for everyone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Brown, Len
In reply to this post by Greg Kroah-Hartman
On Sun, 2005-04-24 at 06:26, Andrew Morton wrote:

> 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?

I will continue to use bk
until an alternative emerges that makes my role
as a sub-system maintainer easier -- rather than harder.

My employer pays for a commercial bk license.

> - Can Andrew legally use the bk client?
>
> - Can Andrew legally use a bk client which won't go phut at cset 65535?

I don't see why not.  Given your central role to the Linux development
process, I would think it would be trivial to justify OSDL arming you
with any and all tools you desire if they make you even slightly more effective.

Also, I would think Bitmover would be interested in having you enabled
to keep people like me as happy paying customers.

The question for bk use is what do we do for a reference "Linus tree"
history.  It would be most effective if we could have a single bk history
rather than everybody rolling their own.

> - 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 can do this if you require it.  The current "acpi patch" includes
68 patches: 200 files changed, 7780 insertions(+), 5455 deletions(-)

Everything in it is intended to go to Linus on day-one of 2.6.13.
Some of it should really go into 2.6.12 - but frankly, I hesitate
to touch 2.6.12 while the tools are in such flux.

> 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.

Please do not roll -mm without including the ACPI sub-system.
-mm provides the broadest pre-integration test coverage we've ever had.
It has allowed us to significantly reduce regressions in Linus' tree
as we encounter the inevitable setbacks associated with making
the ACPI sub-system in Linux the best in the industry.

thanks,
-Len


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Andrew Morton-8
Len Brown <[hidden email]> wrote:
>
> ...
> Also, I would think Bitmover would be interested in having you enabled
> to keep people like me as happy paying customers.

hm.  I guess I can continue to use bk until the end of July or until we hit
the 65535th cset.  After that things become murky.

> The question for bk use is what do we do for a reference "Linus tree"
> history.  It would be most effective if we could have a single bk history
> rather than everybody rolling their own.

yes, someone needs to set up a bk tree which is fed diffs from Linus's git
tree.  Let's call this the linus-git-bk-tree.  You then pull this into the
acpi tree.

> > - 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 can do this if you require it.

Once you have the linus-git-bk-tree, then yes, it would be very nice if you
(or someone else) were to set up another machine which every six hours or
so does

        cd bk-acpi/
        bk pull bk://linux-acpi.bkbits.net/to-akpm
        gcapatch > /ftp-dir/bk-acpi.patch

and makes /ftp-dir available.  The same machine could also publish all the
other bk trees, such as Tony's
http://lia64.bkbits.net/linux-ia64-test-2.6.12.  I have all the bk url's.

The fact that some developers change the bk URL between major kernel
releases will be a bit of a pain.

>  The current "acpi patch" includes
> 68 patches: 200 files changed, 7780 insertions(+), 5455 deletions(-)
>
> Everything in it is intended to go to Linus on day-one of 2.6.13.
> Some of it should really go into 2.6.12 - but frankly, I hesitate
> to touch 2.6.12 while the tools are in such flux.

"flux".  I've never seen it spelled that way before ;)

> > 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.
>
> Please do not roll -mm without including the ACPI sub-system.
> -mm provides the broadest pre-integration test coverage we've ever had.
> It has allowed us to significantly reduce regressions in Linus' tree
> as we encounter the inevitable setbacks associated with making
> the ACPI sub-system in Linux the best in the industry.

OK, well once we have linus-git-bk-tree I can continue to do bk pulls until
either the bk license explodes or we hit the 65536-csets problem.

After that, the automated-patch-exports thing above would be needed.

In the very short-term, please email me the patch.  Some automated daily
thing would suit.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Linux 2.6.12-rc3

Geert Uytterhoeven
In reply to this post by Al Viro
On Tue, 26 Apr 2005, Al Viro wrote:

> On Mon, Apr 25, 2005 at 09:14:01PM +0200, Geert Uytterhoeven wrote:
> > On Thu, 21 Apr 2005, Al Viro wrote:
> > > As far as I can see that's the minimally intrusive header changes needed
> > > to avoid problems - better than variant with splitting sched.h as in m68k CVS.
> >
> > We can discuss about that. IIRC, HCH is also in favor of splitting off struct
> > task_struct from sched.h.
>
> Sure, but splitting sched.h is a separate story.  Mixing it with m68k
> merge will only make both harder.  It requires more include reordering
> and I'd rather keep that headache separate from m68k issues.  I agree
> that eventual splitup of sched.h makes sense.  However, I think that
> going for minimally intrusive variant of merge and then dealing with
> sched.h would be easier for everyone.

I agree, it's a separate story.

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/