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: Tue, 16 Dec 2008 16:07:43 +0900
User-agent: Mutt/1.5.13 (2006-08-11)

On Fri, Dec 12, 2008 at 01:24:17AM +0900, Shin-ichiro KAWASAKI wrote:
> Paul Mundt wrote:
> >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.
> 
> Hm, staging tree seems to have two roles.
> - Make it easy to review/test qemu-sh patches,
>   so that high quality patches are sent to upstream.
> - Avoid work duplications among qemu-sh developers.
> And the drawbacks are,
> - Might discourage merge to upstream.
> - Messy to send patch both upstream and staging.
> 
I don't think any of those drawbacks apply, that is precisely why it is a
"staging" tree. The idea is that people do all of their development
against QEMU SVN as they do now, and the staging tree simply keeps track
of them. The staging tree is mostly a benefit for users looking for the
complete available state of development for SH while providing a stable
point of reference for developers to make sure there is no overlapping
work.

After thinking about this some more, I have decided against a git tree,
mostly since having a forked git tree encourages people to do development
there instead of on SVN, and it is less obvious at first glance what is
provided by the tree and how badly it deviates from the SVN HEAD.

Nothing in the staging tree should be long-lived, and the only stuff
hanging around there are patches that are destined for merging but might
still be in need of wider testing, some incremental changes, etc. I
expect patches to be dropped from the staging tree just as quickly as
they are applied, so it should never be anything completely unwieldly,
and certainly not a fork. You should not confuse "staging" with
"development fork", they are wholly unrelated concepts, the latter of
which I don't believe anyone is interested in.

> Even though I'm not yet sure the staging tree will work fine or not,
> I'll try to use the repository 'http://repo.or.cz/w/qemu/sh4.git'
> to push my patches.
> # I'm going to work for U-Boot trouble on qemu-sh.
> 
I would prefer that you just send them to the list as usual rather than
fragmenting development. I don't think anyone really wants to track
multiple trees to see who is doing what. If it hasn't been posted to the
list, it shouldn't be in the tree, either.

Anyways, I have converted the aforementioned URL to be a quilt series,
there is some further documentation in there. I will announce it to the
linux-sh list later today. It already contains outstanding patches from
Vladimir, Yoshii-san, and Jean-Christophe.




reply via email to

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