[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo
dhaval.giani at gmail.com
Thu Jun 21 03:17:13 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.
> 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.
What I would be interested in knowing is if someone might be interested in
generating this tree, do we have a list of branches maintainers/developers
want to push right away available somewhere?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ksummit-2012-discuss