qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PROPOSITION] SH4 workflow improvement


From: Paul Mundt
Subject: Re: [Qemu-devel] [PROPOSITION] SH4 workflow improvement
Date: Wed, 10 Dec 2008 14:02:17 +0900
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Dec 10, 2008 at 03:04:12AM +0900, address@hidden wrote:
> Thank you, Jean for your effort.
> 
> >     My idea is to create a git repos to coordinate the SH4 patches
> I believe this helps people testing new code easily.
> It is much better than my bulk patch.
> 
> But, as you said 
> >     The final goal is allow us to have a patch series on which we can send
> >     a pull request to have it applied in the SVN
> This workflow, and the person who actually apply it, is important.
> Otherwise this will be a forked project, and possibly affect negatively,
>  discouraging people to merge sh patches to official repository.
> 
It makes sense to have a staging tree where stuff can be queued up,
tested, and reworked until it is merged upstream. For the development of
new features, it is helpful to prevent fragmentation. We've already seen
this with at least 3 different people working on CF at basically the same
time without any knowledge of what was going on, this is something we
want to avoid.

In any event, I would also like to start using QEMU for other SH targets,
not strictly limited to SH-4/SH-4A, which requires a bit of rework,
especially for SH-2A.

I've set up a git tree on kernel.org for this purpose, which will track
the existing svn->git mirror that already exists. I've pulled in
Kawasaki-san's changes as well:

        git://git.kernel.org/pub/scm/virt/qemu/lethal/qemu-sh.git

I can trivially pull from Kawasaki-san also if there is new stuff there,
but in general things should be going to the list directly and being
applied from there.

> I have added your git repos as a remote branch here, but I found I don't have
>  enough time to work with two repository.
> So, I think I'm going to post mainly to ML even in future.
> 
Work aimed at a staging tree is intended to be merged, not for long-term
out-of-tree development. Having said that, the staging tree itself should
never be in a situation where it is that badly out of sync with upstream
that getting patches applied becomes problematic. Effort should certainly
be concentrated on qemu-devel and the central SVN.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]