Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Fengguang Wu]

On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
> 
> > This is the 0-day kernel testing backend I recently started can help.
> > 
> > It runs kernel build/boot tests on each developer's tree and tries to
> > find and report possible defects within 24 hours. The timely report
> > can effectively constraint the scope of impact to the related people,
> > rather than hurting the larger crowd of people in the integration tree.
> 
> Perhaps you would be the perfect candidate to house a linux-devel.git
> repo. Have it set up like so:

Actually Stephen jumps to my mind at the very start. He has all the
experiences, tools and infrastructure to maintain such a tree.

The most important problem may be, how many developers we can attract
to send pull requests to linux-devel. It would be a good quiz in the KS :-)

> master                  - holds an integration of set branches *
> 
> include-developer-topic - holds a branch that a developer has asked you 
>                           to pull from. This is is also integrated into
>                           the master branch as the developer may request
> 
> exclude-developer-topic - holds a branch that a developer has asked you
>                           to pull from. The difference between the above
>                           is that this branch is not to be integrated
>                           into master. It may cause unneeded conflicts
>                           that need to be settled still (even the -rt
>                           tree can go here).
> 
> Basically have a series of branches like:
> 
> include-jejb-scsi
> include-rostedt-ftrace-multi-buf
> include-jiri-sched-deadline
> exclude-rostedt-preempt-rt
> [..]
> 
> 
> * master would be an integration of all include-* branches. If one of
> those branches are found to be broken, then you can rebase master to
> exclude it, send an email to the owner of that branch and tell them it
> will not be included until they fix it.
> 
> Any branch that starts suffering bit rot, you can send an email to that
> developer to ask them if its still valid. If not, just nuke the branch.
> If it is, encourage them to do more work on it or explain why it's
> suffering from rot, otherwise just nuke it anyway.
> 
> This is much easier to do with git than quilt, which is why I do not
> believe this will be like -mm, and mostly ignored (except for a small
> few)

It looks like a clean solution. Stephen may know more caveats about it.

> This can also be a central location to see what's being developed. I
> would even publish where the branches are being pulled from, so if
> people want to know more about the development they can find it.
> 
> I really have no clue about all the great things going on in development
> of parts of linux, and I'm sure there's things going on that I do not
> know about that I would like to look in to. This can be a way to show
> what's being done.

FYI, I've added about 170 git trees as my test targets, which contain
about 550 active branches. I enjoy a lot looking at the freshly cooked
commits being compiled and ran to the degree to keep the servers busy
all day :-)

> If you do not have the time to set up such a repo, I'm willing to do it.
> I just do not have the hardware to do the testing that should be done,
> but as it would be public, others could test it, and report back to me.

Yeah either way is possible and I can sure carry out tests on it. But
IMHO Stephen could be the perfect candidate to maintain the tree :)

Thanks,
Fengguang

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Steven Rostedt]

On Thu, 2012-06-21 at 23:26 +0800, Fengguang Wu wrote:
> On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> > On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
> > 
> > > This is the 0-day kernel testing backend I recently started can help.
> > > 
> > > It runs kernel build/boot tests on each developer's tree and tries to
> > > find and report possible defects within 24 hours. The timely report
> > > can effectively constraint the scope of impact to the related people,
> > > rather than hurting the larger crowd of people in the integration tree.
> > 
> > Perhaps you would be the perfect candidate to house a linux-devel.git
> > repo. Have it set up like so:
> 
> Actually Stephen jumps to my mind at the very start. He has all the
> experiences, tools and infrastructure to maintain such a tree.

I didn't want to burden him more ;-)

> 
> The most important problem may be, how many developers we can attract
> to send pull requests to linux-devel. It would be a good quiz in the KS :-)

Agreed. Of course this is the chicken/egg problem. How do you know how
many developers that it would attract without first doing it.

So far I know of 1 (me ;-)  And I think even GregKH said he liked the
idea.

> 
> FYI, I've added about 170 git trees as my test targets, which contain
> about 550 active branches. I enjoy a lot looking at the freshly cooked
> commits being compiled and ran to the degree to keep the servers busy
> all day :-)

What about trees like my own, where 'master' is very stale, and all the
goodies happen in the other branches. And last I looked, in my public
repo, I have 124 branches!

> 
> > If you do not have the time to set up such a repo, I'm willing to do it.
> > I just do not have the hardware to do the testing that should be done,
> > but as it would be public, others could test it, and report back to me.
> 
> Yeah either way is possible and I can sure carry out tests on it. But
> IMHO Stephen could be the perfect candidate to maintain the tree :)

If he wants to then sure. Otherwise it may become my hobby :-)

-- Steve

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Paul E. McKenney]

On Thu, Jun 21, 2012 at 11:51:41AM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 23:26 +0800, Fengguang Wu wrote:
> > On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> > > On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
> > > 
> > > > This is the 0-day kernel testing backend I recently started can help.
> > > > 
> > > > It runs kernel build/boot tests on each developer's tree and tries to
> > > > find and report possible defects within 24 hours. The timely report
> > > > can effectively constraint the scope of impact to the related people,
> > > > rather than hurting the larger crowd of people in the integration tree.
> > > 
> > > Perhaps you would be the perfect candidate to house a linux-devel.git
> > > repo. Have it set up like so:
> > 
> > Actually Stephen jumps to my mind at the very start. He has all the
> > experiences, tools and infrastructure to maintain such a tree.
> 
> I didn't want to burden him more ;-)
> 
> > 
> > The most important problem may be, how many developers we can attract
> > to send pull requests to linux-devel. It would be a good quiz in the KS :-)
> 
> Agreed. Of course this is the chicken/egg problem. How do you know how
> many developers that it would attract without first doing it.
> 
> So far I know of 1 (me ;-)  And I think even GregKH said he liked the
> idea.
> 
> > 
> > FYI, I've added about 170 git trees as my test targets, which contain
> > about 550 active branches. I enjoy a lot looking at the freshly cooked
> > commits being compiled and ran to the degree to keep the servers busy
> > all day :-)
> 
> What about trees like my own, where 'master' is very stale, and all the
> goodies happen in the other branches. And last I looked, in my public
> repo, I have 124 branches!
> 
> > 
> > > If you do not have the time to set up such a repo, I'm willing to do it.
> > > I just do not have the hardware to do the testing that should be done,
> > > but as it would be public, others could test it, and report back to me.
> > 
> > Yeah either way is possible and I can sure carry out tests on it. But
> > IMHO Stephen could be the perfect candidate to maintain the tree :)
> 
> If he wants to then sure. Otherwise it may become my hobby :-)

Let me make sure that I understand the current state:

1.	Fengguang pulls from my tree (presumably from rcu/next)	
	whenever I push something.  He tests my commits in isolation
	from other maintainers' commits.
	
2.	Stephen also pulls from my tree (rcu/next) whenever I push
	something.  However, Stephen tests the merge of all
	maintainers' commits.

So it sounds to me that Stephen is already doing the job that Steven
is suggesting should be done.

So, what am I missing here?

							Thanx, Paul

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Steven Rostedt]

On Thu, 2012-06-21 at 16:38 -0700, Paul E. McKenney wrote:

> Let me make sure that I understand the current state:
> 
> 1.	Fengguang pulls from my tree (presumably from rcu/next)	
> 	whenever I push something.  He tests my commits in isolation
> 	from other maintainers' commits.
> 	
> 2.	Stephen also pulls from my tree (rcu/next) whenever I push
> 	something.  However, Stephen tests the merge of all
> 	maintainers' commits.
> 
> So it sounds to me that Stephen is already doing the job that Steven
> is suggesting should be done.
> 
> So, what am I missing here?

That linux-next is only for code that's ready for the next release
cycle.

What would be nice is a single public repository that holds development
code that is not ready for the next release cycle, but is in a "working
state". Basically, one of your "not for inclusion" changes.

For those of us with test machines, it may be nice that we also perform
some testing, as Fengguang may not hit all permutations that others may
find.

-- Steve
 

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Paul E. McKenney]

On Thu, Jun 21, 2012 at 07:45:48PM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 16:38 -0700, Paul E. McKenney wrote:
> 
> > Let me make sure that I understand the current state:
> > 
> > 1.	Fengguang pulls from my tree (presumably from rcu/next)	
> > 	whenever I push something.  He tests my commits in isolation
> > 	from other maintainers' commits.
> > 	
> > 2.	Stephen also pulls from my tree (rcu/next) whenever I push
> > 	something.  However, Stephen tests the merge of all
> > 	maintainers' commits.
> > 
> > So it sounds to me that Stephen is already doing the job that Steven
> > is suggesting should be done.
> > 
> > So, what am I missing here?
> 
> That linux-next is only for code that's ready for the next release
> cycle.
> 
> What would be nice is a single public repository that holds development
> code that is not ready for the next release cycle, but is in a "working
> state". Basically, one of your "not for inclusion" changes.
> 
> For those of us with test machines, it may be nice that we also perform
> some testing, as Fengguang may not hit all permutations that others may
> find.

So you are suggesting:

3.	Someone pulls from my tree (rcu/dev) whenever I push something,
	and tests the merge of all maintainers' commits.

My rcu/dev branch is often just a preview of rcu/next, but I sometimes
have longer lived topic branches (for example, the current rcu/idle
branch with stuff related to Frederic's work).  So maybe this tree
needs to pull from all of my "rcu/" branches.

							Thanx, Paul

Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Steven Rostedt]

On Thu, 2012-06-21 at 17:03 -0700, Paul E. McKenney wrote:

> So you are suggesting:
> 
> 3.	Someone pulls from my tree (rcu/dev) whenever I push something,
> 	and tests the merge of all maintainers' commits.
> 
> My rcu/dev branch is often just a preview of rcu/next, but I sometimes
> have longer lived topic branches (for example, the current rcu/idle
> branch with stuff related to Frederic's work).  So maybe this tree
> needs to pull from all of my "rcu/" branches.

Exactly! :-)

-- Steve