[Qemu-devel] [PROPOSITION] SH4 workflow improvement

[Qemu-devel] [PROPOSITION] SH4 workflow improvement

[Jean-Christophe PLAGNIOL-VILLARD]

Hi all,

	Actually it's difficult to work on the improvement of SH4
	because we do not have a place to work.

	My idea is to create a git repos to coordinate the SH4 patches

	I propose this because I've try to test different patch send to the ML
	and it's difficult because you can not apply them simply to generate a
	patch series suitable.

	For this I've create a git here
	http://uboot.jcrosoft.org/git?p=qemu-sh4.git;a=summary

	If you have a better place to put I've no problem with it.

	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

	Takashi YOSHII, Shin-ichiro KAWASAKI I've try to merge your patches on
	this tree please take a look and tell me if I do something wrong

Best Regards,
J.

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

[Kristoffer Ericson]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Sat, 6 Dec 2008 13:07:41 +0100
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:

> Hi all,
> 
> 	Actually it's difficult to work on the improvement of SH4
> 	because we do not have a place to work.

I've noticed the same, the main qemu repository 
doesn't contain much in the way of SH4. Seems to
take awhile to get stuff applied upstreams.

> 
> 	My idea is to create a git repos to coordinate the SH4 patches
> 
> 	I propose this because I've try to test different patch send to the ML
> 	and it's difficult because you can not apply them simply to generate a
> 	patch series suitable.
> 
> 	For this I've create a git here
> 	http://uboot.jcrosoft.org/git?p=qemu-sh4.git;a=summary
> 
> 	If you have a better place to put I've no problem with it.
> 
> 	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
> 
> 	Takashi YOSHII, Shin-ichiro KAWASAKI I've try to merge your patches on
> 	this tree please take a look and tell me if I do something wrong
> 
> Best Regards,
> J.
> 
> 


-- 
Kristoffer Ericson <kristoffer.ericson@gmail.com>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Shin-ichiro KAWASAKI]

Kristoffer Ericson wrote:
> On Sat, 6 Dec 2008 13:07:41 +0100
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> 
>> Hi all,
>>
>> 	Actually it's difficult to work on the improvement of SH4
>> 	because we do not have a place to work.
> 
> I've noticed the same, the main qemu repository 
> doesn't contain much in the way of SH4. Seems to
> take awhile to get stuff applied upstreams.

I have same thought, also.

>> 	My idea is to create a git repos to coordinate the SH4 patches
>>
>> 	I propose this because I've try to test different patch send to the ML
>> 	and it's difficult because you can not apply them simply to generate a
>> 	patch series suitable.
>>
>> 	For this I've create a git here
>> 	http://uboot.jcrosoft.org/git?p=qemu-sh4.git;a=summary
>>
>> 	If you have a better place to put I've no problem with it.
>>
>> 	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
>>
>> 	Takashi YOSHII, Shin-ichiro KAWASAKI I've try to merge your patches on
>> 	this tree please take a look and tell me if I do something wrong

I think it is one of the good ideas.  I'm trying the git repository. Thanks.

And I wonder why the merges of SH4 patches to the upstream are slow.
My guess is that the sent patches are not reviewed enough, and main QEMU developers
are too busy to spare time for them.  Reviewing on SH4 related patches by QEMU-SH4
developers might be a help.  Any comments on this idea?


Regards,
Shin-ichiro KAWASAKI

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

[Nobuhiro Iwamatsu]

Shin-ichiro KAWASAKI wrote:
> Kristoffer Ericson wrote:
>> On Sat, 6 Dec 2008 13:07:41 +0100
>> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>>
>>> Hi all,
>>>
>>> 	Actually it's difficult to work on the improvement of SH4
>>> 	because we do not have a place to work.
>> I've noticed the same, the main qemu repository 
>> doesn't contain much in the way of SH4. Seems to
>> take awhile to get stuff applied upstreams.
> 
> I have same thought, also.
> 
>>> 	My idea is to create a git repos to coordinate the SH4 patches
>>>
>>> 	I propose this because I've try to test different patch send to the ML
>>> 	and it's difficult because you can not apply them simply to generate a
>>> 	patch series suitable.
>>>
>>> 	For this I've create a git here
>>> 	http://uboot.jcrosoft.org/git?p=qemu-sh4.git;a=summary
>>>
>>> 	If you have a better place to put I've no problem with it.
>>>
>>> 	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
>>>
>>> 	Takashi YOSHII, Shin-ichiro KAWASAKI I've try to merge your patches on
>>> 	this tree please take a look and tell me if I do something wrong
> 
> I think it is one of the good ideas.  I'm trying the git repository. Thanks.
> 
> And I wonder why the merges of SH4 patches to the upstream are slow.
> My guess is that the sent patches are not reviewed enough, and main QEMU developers
> are too busy to spare time for them.  Reviewing on SH4 related patches by QEMU-SH4
> developers might be a help.  Any comments on this idea?
> 
I also think so.
I agree with management with Git.
However, it is necessary to think the patch is managed
and it is taken up-stream.
I think that it will do the fork the way things are going.
We might have it commit up-stream by deciding the manager of SH.

Best regards,
 Nobuhiro

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:07 Sat 06 Dec     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi all,
> 
> 	Actually it's difficult to work on the improvement of SH4
> 	because we do not have a place to work.
> 
> 	My idea is to create a git repos to coordinate the SH4 patches
> 
> 	I propose this because I've try to test different patch send to the ML
> 	and it's difficult because you can not apply them simply to generate a
> 	patch series suitable.
> 
> 	For this I've create a git here
> 	http://uboot.jcrosoft.org/git?p=qemu-sh4.git;a=summary
	I've rebase the git against current SVN
	Kawasaki-san please take a look I've regenerate a patch base on the
	current SVN

	Please also note as suggest buy Laurent Desnogues
	I've create also the git at
	http://repo.or.cz/w/qemu/sh4.git
	where other qemu repos are already presend

Best Regards,
J.

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

[takasi-y]

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.

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.

/yoshii

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

[Paul Mundt]

On Wed, Dec 10, 2008 at 03:04:12AM +0900, takasi-y@ops.dti.ne.jp 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.

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

[Shin-ichiro KAWASAKI]

Paul Mundt wrote:
> On Wed, Dec 10, 2008 at 03:04:12AM +0900, takasi-y@ops.dti.ne.jp 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.

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.

> 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.
SH-2A sounds Exciting!


>> 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.

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 want to make a correction.
The last commit with id f7a1672bb130d481c49dbea3f95f9649c03138f8
is not my work, but Yoshii-san's nice work.
I've just edited his patch to make it apply to the SVN HEAD.


Regards,
Shin-ichiro KAWASAKI

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

[Paul Mundt]

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.