linux-next: the purge :-)

linux-next: the purge :-)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Hi all,

Having published my expectations of what should be in linux-next, I am
no implementing what I think is what I said.  :-)

This is open to discussion (including suggestions about other trees).

The following trees are being excluded from today because I think that
they contain changes that:
	- have not been published/reviewed/tested sufficiently
	- are not currently intended for 2.6.26 or 2.6.27.
(not all reasons apply to all trees).  Please don't take offense, I am
just trying to obey my own guidelines.

ldp
x86_latest
sched_latest

Ingo, I assume that things will migrate from {x86,sched} latest to
for-akpm (for-next?) over time.  Greg, you might consider setting up a
subset (currently probably empty) of the ldp tree for drivers that are
readier for integration.

As an aside, the kbuild tree is still dropped for today since Sam is not
in a position to fix stuff until the weekend and the wireless tree is
dropped today because it can not be fetched.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: the purge :-)

[John W. Linville]

On Thu, May 08, 2008 at 11:21:30AM +1000, Stephen Rothwell wrote:

> As an aside, the kbuild tree is still dropped for today since Sam is not
> in a position to fix stuff until the weekend and the wireless tree is
> dropped today because it can not be fetched.

Sorry, just sent a note on another thread!  The wireless tree has
now adopted the "wireless-next-2.6" naming scheme.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: linux-next: the purge :-)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Hi John,

On Wed, 7 May 2008 21:56:16 -0400 "John W. Linville" <linville@tuxdriver.com> wrote:
>
> On Thu, May 08, 2008 at 11:21:30AM +1000, Stephen Rothwell wrote:
> 
> > As an aside, the kbuild tree is still dropped for today since Sam is not
> > in a position to fix stuff until the weekend and the wireless tree is
> > dropped today because it can not be fetched.
> 
> Sorry, just sent a note on another thread!  The wireless tree has
> now adopted the "wireless-next-2.6" naming scheme.

That's ok, I will pick it up for tomorrow.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: the purge :-)

[Greg KH]

On Thu, May 08, 2008 at 11:21:30AM +1000, Stephen Rothwell wrote:
> Greg, you might consider setting up a subset (currently probably
> empty) of the ldp tree for drivers that are readier for integration.

Ok, fair enough, I totally understand.

I've now moved my trees around a bit, and would like it if you could
include the following, in this order (the # NEXT_BASE variable is set in
them to make sure things get ordered properly.)
	driver-core.next
	usb.next
	driver-core
	usb
	ldp.next

The ".next" trees are what is going to Linus before the next major
release happens (bugfixes and new device ids at this point in time for
example.)  The other trees are what is going to go to Linus after the
next major kernel is out.

I also have a "ldp" tree as well, but I understand why you do not want
to pull it at this time into linux-next.

And, there is a real driver already in the ldp.next tree that should
show up in 2.6.27, so it isn't empty at this time :)

If you have any questions about these trees, please let me know.

thanks,

greg k-h

Re: linux-next: the purge :-)

[Adrian Bunk]

On Wed, May 07, 2008 at 09:27:53PM -0700, Greg KH wrote:
> On Thu, May 08, 2008 at 11:21:30AM +1000, Stephen Rothwell wrote:
> > Greg, you might consider setting up a subset (currently probably
> > empty) of the ldp tree for drivers that are readier for integration.
> 
> Ok, fair enough, I totally understand.
> 
> I've now moved my trees around a bit, and would like it if you could
> include the following, in this order (the # NEXT_BASE variable is set in
> them to make sure things get ordered properly.)
> 	driver-core.next
> 	usb.next
> 	driver-core
> 	usb
> 	ldp.next
> 
> The ".next" trees are what is going to Linus before the next major
> release happens (bugfixes and new device ids at this point in time for
> example.)  The other trees are what is going to go to Linus after the
> next major kernel is out.
>...

So the "next" in your .next has the opposite meaning of the one in 
linux-next?

Can you name it .fixes instead to make it clearer?

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: linux-next: the purge :-)

[Greg KH]

On Thu, May 08, 2008 at 09:27:15AM +0300, Adrian Bunk wrote:
> On Wed, May 07, 2008 at 09:27:53PM -0700, Greg KH wrote:
> > On Thu, May 08, 2008 at 11:21:30AM +1000, Stephen Rothwell wrote:
> > > Greg, you might consider setting up a subset (currently probably
> > > empty) of the ldp tree for drivers that are readier for integration.
> > 
> > Ok, fair enough, I totally understand.
> > 
> > I've now moved my trees around a bit, and would like it if you could
> > include the following, in this order (the # NEXT_BASE variable is set in
> > them to make sure things get ordered properly.)
> > 	driver-core.next
> > 	usb.next
> > 	driver-core
> > 	usb
> > 	ldp.next
> > 
> > The ".next" trees are what is going to Linus before the next major
> > release happens (bugfixes and new device ids at this point in time for
> > example.)  The other trees are what is going to go to Linus after the
> > next major kernel is out.
> >...
> 
> So the "next" in your .next has the opposite meaning of the one in 
> linux-next?

It does?  I was following the convention that people used for their git
tree branch names I thought.

> Can you name it .fixes instead to make it clearer?

I can name it anything that Stephen wants me to, I'll defer to him as he
is the only one that will ever really see this.

thanks,

greg k-h

Re: linux-next: the purge :-)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Hi Greg,

On Thu, 8 May 2008 15:04:43 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Thu, May 08, 2008 at 09:27:15AM +0300, Adrian Bunk wrote:
> > On Wed, May 07, 2008 at 09:27:53PM -0700, Greg KH wrote:
> > > 
> > > I've now moved my trees around a bit, and would like it if you could
> > > include the following, in this order (the # NEXT_BASE variable is set in
> > > them to make sure things get ordered properly.)
> > > 	driver-core.next
> > > 	usb.next
> > > 	driver-core
> > > 	usb
> > > 	ldp.next
> > > 
> > > The ".next" trees are what is going to Linus before the next major
> > > release happens (bugfixes and new device ids at this point in time for
> > > example.)  The other trees are what is going to go to Linus after the
> > > next major kernel is out.
> > >...
> > 
> > So the "next" in your .next has the opposite meaning of the one in 
> > linux-next?
> 
> It does?  I was following the convention that people used for their git
> tree branch names I thought.

In their git trees, people usually have a branch called "for-linus" for
fixes to the current tree and "for-next" or "for-akpm" (or "devel" or
"testing") for stuff for the next release).

> > Can you name it .fixes instead to make it clearer?
> 
> I can name it anything that Stephen wants me to, I'll defer to him as he
> is the only one that will ever really see this.

In linux-next, when the choice is left to me I name the trees like this:

xxx-current	bug fixes and stuff not take yet for Linus' current tree
xxx		stuff for the next release.

Today I have used your names, but Adrian is correct that they are
inconsistent with (at least) my normal usage.

One question: is the driver in ldp.next intended for 2.6.26? Because if
it is, ldp.next should be based on usb.next, not usb. If not then
ldp.next is wrongly named.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: the purge :-)

[Greg KH]

On Fri, May 09, 2008 at 11:16:08AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Thu, 8 May 2008 15:04:43 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, May 08, 2008 at 09:27:15AM +0300, Adrian Bunk wrote:
> > > On Wed, May 07, 2008 at 09:27:53PM -0700, Greg KH wrote:
> > > > 
> > > > I've now moved my trees around a bit, and would like it if you could
> > > > include the following, in this order (the # NEXT_BASE variable is set in
> > > > them to make sure things get ordered properly.)
> > > > 	driver-core.next
> > > > 	usb.next
> > > > 	driver-core
> > > > 	usb
> > > > 	ldp.next
> > > > 
> > > > The ".next" trees are what is going to Linus before the next major
> > > > release happens (bugfixes and new device ids at this point in time for
> > > > example.)  The other trees are what is going to go to Linus after the
> > > > next major kernel is out.
> > > >...
> > > 
> > > So the "next" in your .next has the opposite meaning of the one in 
> > > linux-next?
> > 
> > It does?  I was following the convention that people used for their git
> > tree branch names I thought.
> 
> In their git trees, people usually have a branch called "for-linus" for
> fixes to the current tree and "for-next" or "for-akpm" (or "devel" or
> "testing") for stuff for the next release).
> 
> > > Can you name it .fixes instead to make it clearer?
> > 
> > I can name it anything that Stephen wants me to, I'll defer to him as he
> > is the only one that will ever really see this.
> 
> In linux-next, when the choice is left to me I name the trees like this:
> 
> xxx-current	bug fixes and stuff not take yet for Linus' current tree
> xxx		stuff for the next release.
> 
> Today I have used your names, but Adrian is correct that they are
> inconsistent with (at least) my normal usage.

Ok, I'll go rename them to be ".current" instead of ".next"

> One question: is the driver in ldp.next intended for 2.6.26?

No, 2.6.27, it will get sent to Jeff probably next week when I get the
last round of proposed patches into it.  But people are using it today,
so it is good for their testing and to work off of.

Same thing goes for the via framebuffer driver that I'll move into
ldp.next next week when the last round of cleanups to it happen.  It too
is for 2.6.27.

> Because if it is, ldp.next should be based on usb.next, not usb. If
> not then ldp.next is wrongly named.

No, the "ldp.next" tree is one kernel release away, I think I put it in
the correct place in the sequence because of this.

If you want me to move it, I'd be glad to do so.

thanks,

greg k-h

Re: linux-next: the purge :-)

[Greg KH]

On Thu, May 08, 2008 at 08:44:27PM -0700, Greg KH wrote:
> On Fri, May 09, 2008 at 11:16:08AM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > On Thu, 8 May 2008 15:04:43 -0700 Greg KH <greg@kroah.com> wrote:
> > >
> > > On Thu, May 08, 2008 at 09:27:15AM +0300, Adrian Bunk wrote:
> > > > On Wed, May 07, 2008 at 09:27:53PM -0700, Greg KH wrote:
> > > > > 
> > > > > I've now moved my trees around a bit, and would like it if you could
> > > > > include the following, in this order (the # NEXT_BASE variable is set in
> > > > > them to make sure things get ordered properly.)
> > > > > 	driver-core.next
> > > > > 	usb.next
> > > > > 	driver-core
> > > > > 	usb
> > > > > 	ldp.next
> > > > > 
> > > > > The ".next" trees are what is going to Linus before the next major
> > > > > release happens (bugfixes and new device ids at this point in time for
> > > > > example.)  The other trees are what is going to go to Linus after the
> > > > > next major kernel is out.
> 
> Ok, I'll go rename them to be ".current" instead of ".next"

Now done, the sequence is:
	driver-core.current
	usb.current
	driver-core
	usb
	ldp.next

I left ldp.next as that is really only for the -next tree.

If you have any problems with this, please let me know.

thanks,

greg k-h

Re: linux-next: the purge :-)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi Greg,

On Thu, 8 May 2008 21:18:02 -0700 Greg KH <greg@kroah.com> wrote:
>
> Now done, the sequence is:
> 	driver-core.current
> 	usb.current
> 	driver-core
> 	usb
> 	ldp.next
> 
> I left ldp.next as that is really only for the -next tree.
> 
> If you have any problems with this, please let me know.

That looks OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: the purge :-)

[Thomas Gleixner]

On Thu, 8 May 2008, Stephen Rothwell wrote:
> Hi all,
> 
> Having published my expectations of what should be in linux-next, I am
> no implementing what I think is what I said.  :-)
> 
> This is open to discussion (including suggestions about other trees).
> 
> The following trees are being excluded from today because I think that
> they contain changes that:
> 	- have not been published/reviewed/tested sufficiently
> 	- are not currently intended for 2.6.26 or 2.6.27.
> (not all reasons apply to all trees).  Please don't take offense, I am
> just trying to obey my own guidelines.
> 
> ldp
> x86_latest
> sched_latest
> 
> Ingo, I assume that things will migrate from {x86,sched} latest to
> for-akpm (for-next?) over time.

We are working on refactoring our x86 work flow. We'll give you
notice, when the dust of the demolition has settled.

Thanks,
	tglx

Re: linux-next: the purge :-)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Hi Thomas,

On Thu, 8 May 2008 11:55:14 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> We are working on refactoring our x86 work flow. We'll give you
> notice, when the dust of the demolition has settled.

OK, I look forward to it.

Thanks

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]