From: Paul Mundt <lethal@linux-sh.org>
To: qemu-devel@nongnu.org
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PROPOSITION] SH4 workflow improvement
Date: Tue, 16 Dec 2008 16:07:43 +0900 [thread overview]
Message-ID: <20081216070743.GA27495@linux-sh.org> (raw)
In-Reply-To: <49413EB1.2030200@juno.dti.ne.jp>
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.
prev parent reply other threads:[~2008-12-16 7:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-06 12:07 [Qemu-devel] [PROPOSITION] SH4 workflow improvement Jean-Christophe PLAGNIOL-VILLARD
2008-12-06 13:37 ` Kristoffer Ericson
2008-12-07 16:39 ` Shin-ichiro KAWASAKI
2008-12-09 2:21 ` Nobuhiro Iwamatsu
2008-12-07 23:24 ` Jean-Christophe PLAGNIOL-VILLARD
2008-12-09 18:04 ` takasi-y
2008-12-10 5:02 ` Paul Mundt
2008-12-11 16:24 ` Shin-ichiro KAWASAKI
2008-12-16 7:07 ` Paul Mundt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081216070743.GA27495@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=aurelien@aurel32.net \
--cc=iwamatsu.nobuhiro@renesas.com \
--cc=plagnioj@jcrosoft.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).