| Message ID | 1382970069-16449-1-git-send-email-markos.chandras@imgtec.com |
|---|---|
| State | Accepted |
| Commit | f60dafe06833a17540608d1c8172d6535c513f1e |
| Headers | show |
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
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.
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
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
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
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
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
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
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
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
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 >
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
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
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(-)