[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo
Konrad Rzeszutek Wilk
konrad.wilk at oracle.com
Tue Jun 19 18:10:43 UTC 2012
> 2) Creating a linux-devel.git repo
> Some of the discussion so far has been about code getting into Linus's
> tree without going through linux-next. Or changing between the two. I
> would like to suggest adding a linux-devel.git repo that would let
> anyone that requests to add their development code to this repo. It may
> even spot duplicate work that is going on, or a place to house competing
> projects where it will be easier to do comparisons.
> If a pull causes the build to break or to break others code, then it
> will be reverted (not pulled), and a nasty email will be sent to the
> maintainer to fix it.
I like this... Is it also possible to add automatic cross builds
so the offending maintainer gets an email so she/he can fix it up?
> Rebases will be allowed, and even encouraged. No one should be basing
> their work off of this tree, but they can use this tree to test their
> work against other development code. I want this to be like the old -mm
> tree was.
> When your code has been vetted by the linux-devel repo, you can then
> push it to the linux-next repo. Ideally, your code will be good enough
> that it would no longer need to be rebased when it gets there, and the
> linux-next code will be ready for Linus to pull.
> I believe a repo like this will get new development code more exposure
> and may even find bugs before it gets to the linux-next stage. Maybe
> even give better review. If a developer notices something different
> (good or bad) with how their system is working, if they can spot the
> cause it can be reported to the maintainer of the developmental work.
> This will leave less surprises when code goes mainline.
> -- Steve
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
More information about the Ksummit-2012-discuss