[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Markos Chandras]

Set --with-arch instead of --with-tune for MIPS so that the
generated code will be optimal for the given MIPS ISA.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
 arch/Config.in.mips | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/Config.in.mips b/arch/Config.in.mips
index 6242bcc..86fbe64 100644
--- a/arch/Config.in.mips
+++ b/arch/Config.in.mips
@@ -72,7 +72,7 @@ config BR2_ENDIAN
 	default "LITTLE"	if BR2_mipsel || BR2_mips64el
 	default "BIG" 	    	if BR2_mips || BR2_mips64
 
-config BR2_GCC_TARGET_TUNE
+config BR2_GCC_TARGET_ARCH
 	default "mips1"		if BR2_mips_1
 	default "mips2"		if BR2_mips_2
 	default "mips3"		if BR2_mips_3
-- 
1.8.4

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Markos Chandras,

On Mon, 28 Oct 2013 14:21:09 +0000, Markos Chandras wrote:
> Set --with-arch instead of --with-tune for MIPS so that the
> generated code will be optimal for the given MIPS ISA.
> 
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>

Applied to for-peter-2013.11, a branch that I will ask Peter to pull
when he comes back. I will mark such patches as Accepted in patchwork,
making the (maybe optimistic) assumption that Peter will pull my entire
branch.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Oct 30, 2013 at 6:45 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Mon, 28 Oct 2013 14:21:09 +0000, Markos Chandras wrote:
>> Set --with-arch instead of --with-tune for MIPS so that the
>> generated code will be optimal for the given MIPS ISA.
>>
>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>
> Applied to for-peter-2013.11, a branch that I will ask Peter to pull
> when he comes back. I will mark such patches as Accepted in patchwork,
> making the (maybe optimistic) assumption that Peter will pull my entire
> branch.

Why not use the 'Delegated to' field in patchwork instead? It will
keep the patch as New, until being applied, and it is clear whose
branch it is in.

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 31 Oct 2013 10:19:01 +0100, Thomas De Schampheleire wrote:

> > Applied to for-peter-2013.11, a branch that I will ask Peter to pull
> > when he comes back. I will mark such patches as Accepted in patchwork,
> > making the (maybe optimistic) assumption that Peter will pull my entire
> > branch.
> 
> Why not use the 'Delegated to' field in patchwork instead? It will
> keep the patch as New, until being applied, and it is clear whose
> branch it is in.

Could be a possibility indeed, but it means that I continue to see
these patches in patchwork. Admittedly with a different state, but it's
not as nice as not having them anymore.

I've been quite conservative on the patches I've taken (i.e no new
packages or version bumps), so I'm pretty confident that Peter should
take all of them.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas De Schampheleire]

On Thu, Oct 31, 2013 at 10:22 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 31 Oct 2013 10:19:01 +0100, Thomas De Schampheleire wrote:
>
>> > Applied to for-peter-2013.11, a branch that I will ask Peter to pull
>> > when he comes back. I will mark such patches as Accepted in patchwork,
>> > making the (maybe optimistic) assumption that Peter will pull my entire
>> > branch.
>>
>> Why not use the 'Delegated to' field in patchwork instead? It will
>> keep the patch as New, until being applied, and it is clear whose
>> branch it is in.
>
> Could be a possibility indeed, but it means that I continue to see
> these patches in patchwork. Admittedly with a different state, but it's
> not as nice as not having them anymore.

It would be great if we could add extra states to the patchwork
configuration. I looked at the patchwork sources, which has an xml
file with the different states, but it was unclear to me where this
file is read, and whether it is project specific or patchwork-global.

Do note that it is possible to change the search filter, and specify
'Nobody' in the Delegate field. Since the search is HTTP/GET based,
you can add this URL as a bookmark.
http://patchwork.ozlabs.org/project/buildroot/list/?delegate=-

>
> I've been quite conservative on the patches I've taken (i.e no new
> packages or version bumps), so I'm pretty confident that Peter should
> take all of them.

I have no doubt on your good judgement here. I'm only considering what
will happen if several people start acting as a maintainer-proxy. In
patchwork, it will not be visible at all who has taken a given patch.
Suppose that for some reason the maintainer-proxy forgets about the
patch, then it will be lost unless the submitter notices it and pings.

Best regards,
Thomas

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Arnout Vandecappelle]

On 31/10/13 11:13, Thomas De Schampheleire wrote:
> On Thu, Oct 31, 2013 at 10:22 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Thu, 31 Oct 2013 10:19:01 +0100, Thomas De Schampheleire wrote:
>>
>>>> Applied to for-peter-2013.11, a branch that I will ask Peter to pull
>>>> when he comes back. I will mark such patches as Accepted in patchwork,
>>>> making the (maybe optimistic) assumption that Peter will pull my entire
>>>> branch.
>>>
>>> Why not use the 'Delegated to' field in patchwork instead? It will
>>> keep the patch as New, until being applied, and it is clear whose
>>> branch it is in.
>>
>> Could be a possibility indeed, but it means that I continue to see
>> these patches in patchwork. Admittedly with a different state, but it's
>> not as nice as not having them anymore.

  I would set it as Superseded, instead of Accepted. The assumption is 
that you'll repost the series on the list, not send an empty pull 
request, right? Then Superseded is actually the correct state, or 
eventually it will be.

>
> It would be great if we could add extra states to the patchwork
> configuration. I looked at the patchwork sources, which has an xml
> file with the different states, but it was unclear to me where this
> file is read, and whether it is project specific or patchwork-global.
>
> Do note that it is possible to change the search filter, and specify
> 'Nobody' in the Delegate field. Since the search is HTTP/GET based,
> you can add this URL as a bookmark.
> http://patchwork.ozlabs.org/project/buildroot/list/?delegate=-
>
>>
>> I've been quite conservative on the patches I've taken (i.e no new
>> packages or version bumps), so I'm pretty confident that Peter should
>> take all of them.
>
> I have no doubt on your good judgement here. I'm only considering what
> will happen if several people start acting as a maintainer-proxy. In
> patchwork, it will not be visible at all who has taken a given patch.

  So it should both be delegated to and state superseded...

> Suppose that for some reason the maintainer-proxy forgets about the
> patch, then it will be lost unless the submitter notices it and pings.

  That seems to me like a very exceptional situation.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 31 Oct 2013 11:17:22 +0100, Arnout Vandecappelle wrote:

> >> Could be a possibility indeed, but it means that I continue to see
> >> these patches in patchwork. Admittedly with a different state, but it's
> >> not as nice as not having them anymore.
> 
>   I would set it as Superseded, instead of Accepted. The assumption is 
> that you'll repost the series on the list, not send an empty pull 
> request, right? Then Superseded is actually the correct state, or 
> eventually it will be.

No, I was not necessarily thinking of resending each patch to the list:
all those patches have been on the list, and I've made little to no
changes to them. I have also been careful to post my own patches on the
list, and only afterwards apply them, so that all patches have been
made visible to the list.

Of course, if the general opinion is that I should resend all of the
patches to the list, then I'm fine with doing that once Peter is back
from vacations.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas De Schampheleire]

On Thu, Oct 31, 2013 at 11:47 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Thu, 31 Oct 2013 11:17:22 +0100, Arnout Vandecappelle wrote:
>
>> >> Could be a possibility indeed, but it means that I continue to see
>> >> these patches in patchwork. Admittedly with a different state, but it's
>> >> not as nice as not having them anymore.
>>
>>   I would set it as Superseded, instead of Accepted. The assumption is
>> that you'll repost the series on the list, not send an empty pull
>> request, right? Then Superseded is actually the correct state, or
>> eventually it will be.
>
> No, I was not necessarily thinking of resending each patch to the list:
> all those patches have been on the list, and I've made little to no
> changes to them. I have also been careful to post my own patches on the
> list, and only afterwards apply them, so that all patches have been
> made visible to the list.
>
> Of course, if the general opinion is that I should resend all of the
> patches to the list, then I'm fine with doing that once Peter is back
> from vacations.
>

I think we need a single strategy to be used by all maintainer-proxies.
The problem with not resending the patches is that the
maintainer-proxy (or whatever you want to call it) needs to have a git
tree accessible by Peter. Although not impossible, I'm not really fond
of it.

Also, consider this scenario: a developer submits a patch on day 1, a
maintainer-proxy adds the patch to his branch on day 2. However,
another contributer gives some remarks on the patch and expects it to
be reworked. The maintainer-proxy could forget about this when v2 of
that patch is sent. In this case, v2 is pending in patchwork, and v1
is on a branch for which a pull request is sent. The actual contents
of the branch is not visible on the list. This opens a window for
errors. By sending the patches to the list, there is a bit more
visibility. The downside is that the list gets additional mails.

An additional question is: is there a policy on who takes which
patches, if certain actions need to be taken on these patches, etc.?
At this moment, I still don't really see the difference between
providing an Acked-by: and adding a patch to a for-peter branch,
except for the fact that incoming patches are prearranged in batches
for Peter.

Thanks,
Thomas

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 31 Oct 2013 13:45:43 +0100, Thomas De Schampheleire wrote:

> I think we need a single strategy to be used by all maintainer-proxies.
> The problem with not resending the patches is that the
> maintainer-proxy (or whatever you want to call it) needs to have a git
> tree accessible by Peter. Although not impossible, I'm not really fond
> of it.
> 
> Also, consider this scenario: a developer submits a patch on day 1, a
> maintainer-proxy adds the patch to his branch on day 2. However,
> another contributer gives some remarks on the patch and expects it to
> be reworked. The maintainer-proxy could forget about this when v2 of
> that patch is sent. In this case, v2 is pending in patchwork, and v1
> is on a branch for which a pull request is sent. The actual contents
> of the branch is not visible on the list. This opens a window for
> errors. By sending the patches to the list, there is a bit more
> visibility. The downside is that the list gets additional mails.
> 
> An additional question is: is there a policy on who takes which
> patches, if certain actions need to be taken on these patches, etc.?
> At this moment, I still don't really see the difference between
> providing an Acked-by: and adding a patch to a for-peter branch,
> except for the fact that incoming patches are prearranged in batches
> for Peter.

What I merely intended to do with the for-peter-2013.11 is to act
more-or-less as an interim maintainer during the short period Peter is
not available. I've done this before (i.e not having commit access to
the official repository, but gathering relevant patches in a branch,
until Peter comes back). The idea here is that there would be only one
such 'interim maintainer' at a given point in time.

And yes, the only difference between the for-peter-2013.11 branch and
Acked-by is simply that the batch of patches is already prepared for
Peter to review and pull, he doesn't have to go in the list and/or
patchwork and filter out which patches he should have a look right now,
and which patches are anyway delayed to 2014.02.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas De Schampheleire]

Hi Thomas,

On Thu, Oct 31, 2013 at 3:55 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 31 Oct 2013 13:45:43 +0100, Thomas De Schampheleire wrote:
>
>> I think we need a single strategy to be used by all maintainer-proxies.
>> The problem with not resending the patches is that the
>> maintainer-proxy (or whatever you want to call it) needs to have a git
>> tree accessible by Peter. Although not impossible, I'm not really fond
>> of it.
>>
>> Also, consider this scenario: a developer submits a patch on day 1, a
>> maintainer-proxy adds the patch to his branch on day 2. However,
>> another contributer gives some remarks on the patch and expects it to
>> be reworked. The maintainer-proxy could forget about this when v2 of
>> that patch is sent. In this case, v2 is pending in patchwork, and v1
>> is on a branch for which a pull request is sent. The actual contents
>> of the branch is not visible on the list. This opens a window for
>> errors. By sending the patches to the list, there is a bit more
>> visibility. The downside is that the list gets additional mails.
>>
>> An additional question is: is there a policy on who takes which
>> patches, if certain actions need to be taken on these patches, etc.?
>> At this moment, I still don't really see the difference between
>> providing an Acked-by: and adding a patch to a for-peter branch,
>> except for the fact that incoming patches are prearranged in batches
>> for Peter.
>
> What I merely intended to do with the for-peter-2013.11 is to act
> more-or-less as an interim maintainer during the short period Peter is
> not available. I've done this before (i.e not having commit access to
> the official repository, but gathering relevant patches in a branch,
> until Peter comes back). The idea here is that there would be only one
> such 'interim maintainer' at a given point in time.

Ah, I had interpreted this branch according to the strategy discussed
at last BDD regarding the community organization. In that discussion,
such aggregation of submitted patches was also proposed. I thought you
were acting in that mode.

In that more general case, where there would me more than one
maintainer-proxy, the exact strategy is still somewhat unclear to me.

Best regards,
Thomas

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 31 Oct 2013 18:10:36 +0100, Thomas De Schampheleire wrote:

> Ah, I had interpreted this branch according to the strategy discussed
> at last BDD regarding the community organization. In that discussion,
> such aggregation of submitted patches was also proposed. I thought you
> were acting in that mode.
> 
> In that more general case, where there would me more than one
> maintainer-proxy, the exact strategy is still somewhat unclear to me.

I think the strategy for multiple maintainer-proxy hasn't been really
defined precisely. I believe that the thing we really believed in was
the addition of Acked-by/Tested-by information in the list of patches
in patchwork (both command line and web). This way Peter can much more
easily see which patches have received Acked-by/Tested-by, and look at
these with an higher priority. This would make the Acked-by/Tested-by
more useful, and potentially encourage us and others to do more of
those Acked-by/Tested-by.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Arnout Vandecappelle]

On 31/10/13 13:45, Thomas De Schampheleire wrote:
> On Thu, Oct 31, 2013 at 11:47 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Arnout Vandecappelle,
>>
>> On Thu, 31 Oct 2013 11:17:22 +0100, Arnout Vandecappelle wrote:
>>
>>>>> Could be a possibility indeed, but it means that I continue to see
>>>>> these patches in patchwork. Admittedly with a different state, but it's
>>>>> not as nice as not having them anymore.
>>>
>>>    I would set it as Superseded, instead of Accepted. The assumption is
>>> that you'll repost the series on the list, not send an empty pull
>>> request, right? Then Superseded is actually the correct state, or
>>> eventually it will be.
>>
>> No, I was not necessarily thinking of resending each patch to the list:
>> all those patches have been on the list, and I've made little to no
>> changes to them. I have also been careful to post my own patches on the
>> list, and only afterwards apply them, so that all patches have been
>> made visible to the list.
>>
>> Of course, if the general opinion is that I should resend all of the
>> patches to the list, then I'm fine with doing that once Peter is back
>> from vacations.
>>
>
> I think we need a single strategy to be used by all maintainer-proxies.

  Of course! And we agreed on it during the developer meeting, but Thomas 
has forgotten it. I'll try to get the report on the Wiki as quickly as 
possible so we can refer to it :-)

  The agreement was that we would resend the patch queue to the list, 
because:

- It's easy for Peter to apply them that way.

- No need to 'git pull --rebase', so if an individual patch doesn't apply 
anymore it can be skipped and it will still show up in patchwork.

- The final version of the patch will always be in patchwork and the 
mailing list, even if you make cosmetic changes.

- You don't need some public git repository to pull from.

- We're already at 2000 mails per month, so 300 more won't hurt :-).

  Well, I didn't write all these reasons in the report, just the 
conclusion, but I remember all of these were mentioned.


> The problem with not resending the patches is that the
> maintainer-proxy (or whatever you want to call it) needs to have a git
> tree accessible by Peter. Although not impossible, I'm not really fond
> of it.
>
> Also, consider this scenario: a developer submits a patch on day 1, a
> maintainer-proxy adds the patch to his branch on day 2. However,
> another contributer gives some remarks on the patch and expects it to
> be reworked. The maintainer-proxy could forget about this when v2 of
> that patch is sent. In this case, v2 is pending in patchwork, and v1
> is on a branch for which a pull request is sent. The actual contents
> of the branch is not visible on the list. This opens a window for
> errors. By sending the patches to the list, there is a bit more
> visibility. The downside is that the list gets additional mails.

  Actually, there's no window for error here: v2 is in patchwork so it 
won't be forgotten. However, you'll get a conflict when you try to apply 
it, since something similar has already been applied.


>
> An additional question is: is there a policy on who takes which
> patches, if certain actions need to be taken on these patches, etc.?
> At this moment, I still don't really see the difference between
> providing an Acked-by: and adding a patch to a for-peter branch,
> except for the fact that incoming patches are prearranged in batches
> for Peter.

  Exactly, that's the idea.

  We actually have two parallel concepts:

- for-peter branches (that are posted to the list)

- in the patchwork website, an overview of how many acks a patch has. 
This has more or less the same effect as for-peter branches, but it 
requires changing patchwork itself so can't be done right away.


  Regards,
  Arnout

>
> Thanks,
> Thomas
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] arch/mips: Set BR2_GCC_TARGET_ARCH for MIPS

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 31 Oct 2013 11:13:33 +0100, Thomas De Schampheleire wrote:

> It would be great if we could add extra states to the patchwork
> configuration. I looked at the patchwork sources, which has an xml
> file with the different states, but it was unclear to me where this
> file is read, and whether it is project specific or patchwork-global.
> 
> Do note that it is possible to change the search filter, and specify
> 'Nobody' in the Delegate field. Since the search is HTTP/GET based,
> you can add this URL as a bookmark.
> http://patchwork.ozlabs.org/project/buildroot/list/?delegate=-

Interesting, thanks for looking into this.

> > I've been quite conservative on the patches I've taken (i.e no new
> > packages or version bumps), so I'm pretty confident that Peter should
> > take all of them.
> 
> I have no doubt on your good judgement here. I'm only considering what
> will happen if several people start acting as a maintainer-proxy. In
> patchwork, it will not be visible at all who has taken a given patch.
> Suppose that for some reason the maintainer-proxy forgets about the
> patch, then it will be lost unless the submitter notices it and pings.

I agree. I will try to update the patches and move them back into the
Delegate To state.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com