Hi all,
Christmas has intervened! Today's linux-next (I was putting it together
in my spare moments) took too long, so it is not being released, sorry.
The next release of linux-next will be Dec 27, or 28 (my time). Have a
nice break and relax. :-)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, Dec 23, 2010 at 12:40 PM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> Christmas has intervened! Today's linux-next (I was putting it together
> in my spare moments) took too long, so it is not being released, sorry.
>
> The next release of linux-next will be Dec 27, or 28 (my time). Have a
> nice break and relax. :-)
>
> --
> Cheers,
> Stephen Rothwell [email protected]
> http://www.canb.auug.org.au/~sfr/
>
Personally, I have no problems w/o a linux-next (next-20101223)
release for today.
Today, you posted a lot of emails with merge problems from diverse
trees, beginning with vfs-scale-working.
Last night, I tried to merge rest-of-Linux-2.6.37-rc7 on top of
linux-next (next-20101221), fixed the conflicts manually.
Then I tried to pull-in vfs-scale-working and I guess I have solved
the merge-problems correct, but my build had several errors.
So, I need more exercise :-).
Now, to my questions:
[1] Linux-next tree as base?
Why are all those for-next/linux-next sub-trees not based/rebased on
linux-next and prepared for you as *the* main co-ordinator of
linux-next?
Funny, there are strange names around like "test" for linux-acpi-2.6
for example - is this a "for-next" tree or not?
I mean the nomenclature seems not to be consistent when I look over
the sub-tress.
Then submaintainers have branches like (what I prefer) "for-linus"
(aka upstream, for-2.6.37) or mostly "for-next" (or "linux-next", aka
for-2.6.38) within a single (same) GIT repository.
Others prefer two separated repos: For example net-2.6 ->
upstream/for-2.6.37 and net-next-2.6 -> linux-next/for-2.6.38.
Surely, it depends on the sub-tree and the interaction with other sub-trees.
Can't all submaintainers use "for-linus" (upstream-fixes) and
"for-next" (new code for upcoming release)?
That's leading to my next question: Ideal/optimal work-flow in merging
tress on top of "parent".
Here an example for a "wise" dependency chain for pulls/merges:
1. net-2.6 -> 2. wireless-2.6 -> 3. net-next-2.6 -> 4. wireless-next-2.6
So John Linville (maintainer of linux-wireless) and Dave Miller
(maintainer of net-2.6) are really working together (I missed that
John also pulls in bluetooth sub-tree). The work (pull-requests) are
documented by emails to both MLs.
For me, it seemd other sub-trees which interact or overlap are not
well co-ordinated (I have block-2.6, vfs-2.6 and *-fs in mind)
So, this needs a bit of an analysis/discussion which would help to
reduce this merge f-ups (I hope).
[2] Merge process?
Is this a script you are using? Is there a standard work-flow you
follow? tree1, then tree2, then tree3... Is this always the same
procedure? Does a script exist or you do that manually? Do you use
"brain-power" or which strategies do you perform to solve merge
conflicts? Which help can give git tool on this?
My 0.02EUR.
- Sedat -