On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson pbrobinson@fedoraproject.org wrote:
commit ac67590916a449d1e71a791f6a0c3688251ec074 Author: Peter Robinson pbrobinson@gmail.com Date: Thu Oct 24 20:29:40 2013 +0100
Add patch for i.MX6 Utilite device dtb, drop old exynos patch
I thought we discussed on IRC that patches were going to get sent to the list first?
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
# CONFIG_CRYPTO_TEST is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set # CONFIG_XEN is not set
diff --git a/kernel.spec b/kernel.spec index d1ea97d..19e9e4e 100644 --- a/kernel.spec +++ b/kernel.spec @@ -675,7 +675,6 @@ Patch15000: nowatchdog-on-virt.patch # lpae Patch21001: arm-lpae-ax88796.patch Patch21004: arm-sound-soc-samsung-dma-avoid-another-64bit-division.patch -Patch21005: arm-exynos-mp.patch
# ARM omap Patch21010: arm-omap-load-tfp410.patch @@ -683,6 +682,10 @@ Patch21010: arm-omap-load-tfp410.patch # ARM tegra Patch21020: arm-tegra-usb-no-reset-linux33.patch
+# ARM i.MX6 +# http://www.spinics.net/lists/devicetree/msg08276.html +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it shows that changes have been requested, the patch isn't queued, and it isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear to be ready according to upstream. Can you elaborate?
josh
On Thu, Oct 24, 2013 at 3:48 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson pbrobinson@fedoraproject.org wrote:
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
I think I figured this part out, but the commit message should have mentioned it. Doesn't necessarily have to be in %changelog, but should be mentioned in the commit log.
josh
On (Thu) 24 Oct 2013 [16:02:31], Josh Boyer wrote:
On Thu, Oct 24, 2013 at 3:48 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson pbrobinson@fedoraproject.org wrote:
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
I think I figured this part out, but the commit message should have mentioned it. Doesn't necessarily have to be in %changelog, but should be mentioned in the commit log.
What's the reason?
Amit
On Wed, Oct 30, 2013 at 4:00 AM, Amit Shah amitshah@gmx.net wrote:
On (Thu) 24 Oct 2013 [16:02:31], Josh Boyer wrote:
On Thu, Oct 24, 2013 at 3:48 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson pbrobinson@fedoraproject.org wrote:
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
I think I figured this part out, but the commit message should have mentioned it. Doesn't necessarily have to be in %changelog, but should be mentioned in the commit log.
What's the reason?
I believe it's because we have CONFIG_VIRTIO_CONSOLE=m set in config-generic, and all the architectures that don't override it will inherit that. So the setting in config-arm-generic is redundant. Commit log should still mention it though, as the config-* merging is somewhat black magic and if you don't know how it works it looks like it was just disabled.
josh
On (Wed) 30 Oct 2013 [06:59:25], Josh Boyer wrote:
On Wed, Oct 30, 2013 at 4:00 AM, Amit Shah amitshah@gmx.net wrote:
On (Thu) 24 Oct 2013 [16:02:31], Josh Boyer wrote:
On Thu, Oct 24, 2013 at 3:48 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson pbrobinson@fedoraproject.org wrote:
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
I think I figured this part out, but the commit message should have mentioned it. Doesn't necessarily have to be in %changelog, but should be mentioned in the commit log.
What's the reason?
I believe it's because we have CONFIG_VIRTIO_CONSOLE=m set in config-generic, and all the architectures that don't override it will inherit that. So the setting in config-arm-generic is redundant. Commit log should still mention it though, as the config-* merging is somewhat black magic and if you don't know how it works it looks like it was just disabled.
Ah, OK. Thanks. Since it's black magic to me as well, I just wanted to ensure it's not getting switched off due to some bug or incompatibility.
Amit
Sorry for the delayed response, $dayjob has had me so busy I've not had time to look at kernel stuff since nor associated list mail.
Add patch for i.MX6 Utilite device dtb, drop old exynos patchI thought we discussed on IRC that patches were going to get sent to the list first?
Well it was discussed and agreed upon in a meeting that I wasn't present at and then I was basically informed on IRC what was expected. IMO this is stupid because it appears that I'm the only one it's targetted at as I'm the only one that regularly commits to the ARM section of the kernel and it doesn't appear to apply to anyone else.
What I don't also get is why it's suddenly a problem after nearly two years (my first commit was Jan 26th, 2012) of working in the way I have why it's suddenly become a huge problem. The way I've worked up to now was any issue that might affect non ARM was sent to the list [1] for approval and for anything ARM related you always made it abundantly clear that it was the ARM teams problem to deal with whether it be a bug or a patch, any time there's been a patch that hasn't applied you've just commented it out and pinged me to deal with it and I always have whether it be to rebase or drop. Any time there was a bug report you reassigned it to ARM people.
So what I would like to know is why after nearly two years it is now a problem, why was it taken to a meeting I wasn't present at rather than approaching me directly whether it be email or other ways to discuss the issue that was causing so much trouble and why it took nearly two years to have a problem with the way I was doing it? The way I see it all I've tried to do is make the ARM side of the maintenance as easy on the mainline kernel team as possible, support the ARM devices as best as possible for the ARM users while keeping the workload and process for me as simple as possible.
[1] https://lists.fedoraproject.org/pipermail/kernel/2013-August/004389.html
diff --git a/config-arm-generic b/config-arm-generic index 96a95e5..aaa88ee 100644 --- a/config-arm-generic +++ b/config-arm-generic @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m CONFIG_SMC91X=m CONFIG_SMC911X=m
-CONFIG_VIRTIO_CONSOLE=m
Why did this get dropped? The commit message doesn't say.
It should have been cleaned up as part of commit 1db1471 I had it locally for a few days but I must have missed the line when reviewing the diff for the commit message. Nothing more than an oversight.
# CONFIG_CRYPTO_TEST is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set # CONFIG_XEN is not set
<snip>
+# ARM i.MX6 +# http://www.spinics.net/lists/devicetree/msg08276.html +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it shows that changes have been requested, the patch isn't queued, and it isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear to be ready according to upstream. Can you elaborate?
Because there's HW available and it would be really useful to be able to support it. It's a self contained changed that has no means of breaking anything else because it adds one more dtb file to the kernel build that adds support for just that HW without having any other impact to any other platform or device. I don't see how this has any more impact than commit 87fb89b for Dell TouchPad support
Peter
On Tue, Nov 5, 2013 at 11:16 AM, Peter Robinson pbrobinson@gmail.com wrote:
Sorry for the delayed response, $dayjob has had me so busy I've not had time to look at kernel stuff since nor associated list mail.
Add patch for i.MX6 Utilite device dtb, drop old exynos patchI thought we discussed on IRC that patches were going to get sent to the list first?
Well it was discussed and agreed upon in a meeting that I wasn't present at and then I was basically informed on IRC what was expected.
Informed wasn't how I took that conversation.
IMO this is stupid because it appears that I'm the only one it's targetted at as I'm the only one that regularly commits to the ARM section of the kernel and it doesn't appear to apply to anyone else.
Untrue. It's targeted at anyone that wants to get a patch into the kernel that doesn't have a bug attached to it, or wants to bring in something not clearly headed into mainline. For example, Daniel Stone asked for an evdev patch to get in and I told him to post it here or file a bug and I'd grab it if it looked good. Neither happened, no patch has been pulled in.
We aren't making special rules just for you.
What I don't also get is why it's suddenly a problem after nearly two years (my first commit was Jan 26th, 2012) of working in the way I have why it's suddenly become a huge problem. The way I've worked up
Nobody said it was huge.
to now was any issue that might affect non ARM was sent to the list [1] for approval and for anything ARM related you always made it abundantly clear that it was the ARM teams problem to deal with whether it be a bug or a patch, any time there's been a patch that hasn't applied you've just commented it out and pinged me to deal with it and I always have whether it be to rebase or drop. Any time there was a bug report you reassigned it to ARM people.
It's not that simple any more. For 2 years we could do that because ARM was a secondary arch and things proceeded regardless of what happened there. Now, because of the good efforts of the ARM team, it's primary. Which means we wait, and we should arguably care a hell of a lot more about it. We can't just drop patches in f20 and rawhide and potentially break ARM because that isn't how a primary arch should be treated.
Also, for the past several years we've been less than transparent about what patches we take and why we take them. Not just for ARM, but overall. I think we need to fix that. I think having a bug attached to it is fairly clear. If there's no bug, post to the list. This isn't extremely difficult to do and it applies to everyone.
As I said before, config changes are probably fine without posting. Patches, particularly out-of-tree patches, should get some simple review.
So what I would like to know is why after nearly two years it is now a problem, why was it taken to a meeting I wasn't present at rather than
See above. Also, the meeting wasn't a random unrelated meeting, it was the bi-weekly ARM meeting. It is unfortunate you weren't there and I wasn't aware of that fact, but it wasn't intentional.
approaching me directly whether it be email or other ways to discuss
Because it isn't about and doesn't apply to just you.
the issue that was causing so much trouble and why it took nearly two years to have a problem with the way I was doing it? The way I see it
Because it took you 2 years to get ARM primary?
all I've tried to do is make the ARM side of the maintenance as easy on the mainline kernel team as possible, support the ARM devices as best as possible for the ARM users while keeping the workload and process for me as simple as possible.
And that is extremely appreciated. I'm not asking you or anyone else to stop. I'm asking you and everyone else to help us get things a bit tighter and consistent.
+# ARM i.MX6 +# http://www.spinics.net/lists/devicetree/msg08276.html +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it shows that changes have been requested, the patch isn't queued, and it isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear to be ready according to upstream. Can you elaborate?
Because there's HW available and it would be really useful to be able to support it. It's a self contained changed that has no means of breaking anything else because it adds one more dtb file to the kernel build that adds support for just that HW without having any other impact to any other platform or device. I don't see how this has any more impact than commit 87fb89b for Dell TouchPad support
That commit was already in an upstream tree when it was done. This patch had been sent to the list for review and committed almost as quickly as it was posted. The upstream review wasn't anywhere near complete.
In simple view, you are correct. It doesn't break anything else. In the larger view, I really want to start backing away from random patch grabs. Upstream has a review process for a reason, and I'd like to leverage that for patches we carry. Otherwise we wind up carrying patches that are "getting in RSN" which aren't actually getting in any time soon.
I'm not trying to limit your functionality. I'm trying to limit our liability and learn from past mistakes. This isn't even specific to ARM. The secure boot patches we're carrying? I really dislike those and now we're stuck with them until something happens upstream. They were necessary at the time and we had justification for grabbing them, but they broke things in F18 and F19 and we still don't have great solutions pending in trees.
josh
I thought we discussed on IRC that patches were going to get sent to the list first?
Well it was discussed and agreed upon in a meeting that I wasn't present at and then I was basically informed on IRC what was expected.
Informed wasn't how I took that conversation.
IMO this is stupid because it appears that I'm the only one it's targetted at as I'm the only one that regularly commits to the ARM section of the kernel and it doesn't appear to apply to anyone else.
Untrue. It's targeted at anyone that wants to get a patch into the kernel that doesn't have a bug attached to it, or wants to bring in something not clearly headed into mainline. For example, Daniel Stone asked for an evdev patch to get in and I told him to post it here or file a bug and I'd grab it if it looked good. Neither happened, no patch has been pulled in.
It would be useful for you to advertise this intention and send things like details out to the kernel mailing list. I'll need to re-read my IRC logs but I don't remember you mentioning any of the above, which does sound reasonable, to me in the conversation we had. I'm not sure the conversation that was outlined in the ARM mailing list but it sounds like something that should be broadcast more to the Fedora kernel list.
We aren't making special rules just for you.
We maybe it's just the way it seems as until now I've not seen anyone else be targeted prior to this.... maybe it's just me doing work!
What I don't also get is why it's suddenly a problem after nearly two years (my first commit was Jan 26th, 2012) of working in the way I have why it's suddenly become a huge problem. The way I've worked up
Nobody said it was huge.
Sorry, must have been my interpretation of your reaction.
to now was any issue that might affect non ARM was sent to the list [1] for approval and for anything ARM related you always made it abundantly clear that it was the ARM teams problem to deal with whether it be a bug or a patch, any time there's been a patch that hasn't applied you've just commented it out and pinged me to deal with it and I always have whether it be to rebase or drop. Any time there was a bug report you reassigned it to ARM people.
It's not that simple any more. For 2 years we could do that because ARM was a secondary arch and things proceeded regardless of what happened there. Now, because of the good efforts of the ARM team, it's primary. Which means we wait, and we should arguably care a hell of a lot more about it. We can't just drop patches in f20 and rawhide and potentially break ARM because that isn't how a primary arch should be treated.
Is that round about terms meaning that the Fedora kernel team are going to start to assist in the ARM issues :-D
I try to help and keep the impact of ARM down for you guys but kernel isn't a core skill I ever thought I wanted to learn (I often say about ARM that I now know more about the Fedora Core OS and kernel than I ever thought I wanted to know!) and if the process becomes too arduous I stop enjoying it and I'll go and find some other project to get my teeth into as there's no shortage. I'm not saying here that the process doesn't need to change and improve but just be aware I think it needs balance and it needs to be measured so that you don't scare off the people that are trying to help you.
Also, for the past several years we've been less than transparent about what patches we take and why we take them. Not just for ARM, but overall. I think we need to fix that. I think having a bug attached to it is fairly clear. If there's no bug, post to the list. This isn't extremely difficult to do and it applies to everyone.
Well I don't think targeting me (at least that's what it appears to me) is the way to fix that. I don't see any wider announcement to the list or even updated on the Kernel wiki page. In fact to quote from the wiki "If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable)."
As I said before, config changes are probably fine without posting. Patches, particularly out-of-tree patches, should get some simple review.
Probably fine? If they're more widely impacting I will most certainly post them just like I've done them in the past. Personally I think I have a pretty good overview of the impact of config changes in the ARM sphere and I think it then becomes arduous for all involved.
So what I would like to know is why after nearly two years it is now a problem, why was it taken to a meeting I wasn't present at rather than
See above. Also, the meeting wasn't a random unrelated meeting, it was the bi-weekly ARM meeting. It is unfortunate you weren't there and I wasn't aware of that fact, but it wasn't intentional.
approaching me directly whether it be email or other ways to discuss
Because it isn't about and doesn't apply to just you.
Yet you haven't seen fit to send the changes to your own list, update your own wiki or circulate it to any wider audience that I've seen.
the issue that was causing so much trouble and why it took nearly two years to have a problem with the way I was doing it? The way I see it
Because it took you 2 years to get ARM primary?
all I've tried to do is make the ARM side of the maintenance as easy on the mainline kernel team as possible, support the ARM devices as best as possible for the ARM users while keeping the workload and process for me as simple as possible.
And that is extremely appreciated. I'm not asking you or anyone else to stop. I'm asking you and everyone else to help us get things a bit tighter and consistent.
That's reasonable.... but please communicate your intentions more widely and consistently!
+# ARM i.MX6 +# http://www.spinics.net/lists/devicetree/msg08276.html +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it shows that changes have been requested, the patch isn't queued, and it isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear to be ready according to upstream. Can you elaborate?
Because there's HW available and it would be really useful to be able to support it. It's a self contained changed that has no means of breaking anything else because it adds one more dtb file to the kernel build that adds support for just that HW without having any other impact to any other platform or device. I don't see how this has any more impact than commit 87fb89b for Dell TouchPad support
That commit was already in an upstream tree when it was done. This patch had been sent to the list for review and committed almost as quickly as it was posted. The upstream review wasn't anywhere near complete.
It's a device tree file that impacts a single piece of HW, this isn't a core scheduler change we're talking about here! I think there needs to be perspective to keep us all sane and so we don't go from a relaxed straight forward process to one that is painful for us all.
In simple view, you are correct. It doesn't break anything else. In the larger view, I really want to start backing away from random patch grabs. Upstream has a review process for a reason, and I'd like to leverage that for patches we carry. Otherwise we wind up carrying patches that are "getting in RSN" which aren't actually getting in any time soon.
Believe me I don't like patch grabs either! But similar to secureboot there are some that are useful such as the BeagleBone Black support and some other devices that are key to getting people engaging and using Fedora on ARM and I believe in those cases, like secure boot, the patches are justifiable to open Fedora on ARM and Fedora in general up to a wider audience.
I'm not trying to limit your functionality. I'm trying to limit our liability and learn from past mistakes. This isn't even specific to ARM. The secure boot patches we're carrying? I really dislike those and now we're stuck with them until something happens upstream. They were necessary at the time and we had justification for grabbing them, but they broke things in F18 and F19 and we still don't have great solutions pending in trees.
Well I'm not even going to comment on SecureBoot, I believe enough has already been said there to last a lifetime.
I'm very aware of limiting of liability and of patch impact even if it's just so that I don't have to feel I'm walking on egg shells when dealing with the kernel team. Precisely the reason I dropped and didn't rebase the exynos patch set. When it was added it was useful as it was the only widely available A15 chipset and we wanted something. In hindsight it was a waste of time because there was wider issues with the HW. Like the SecureBoot patch sets you live and learn and ultimately it was low impact and contained.
Peter
On Wed, Nov 6, 2013 at 6:07 AM, Peter Robinson pbrobinson@gmail.com wrote:
I thought we discussed on IRC that patches were going to get sent to the list first?
Well it was discussed and agreed upon in a meeting that I wasn't present at and then I was basically informed on IRC what was expected.
Informed wasn't how I took that conversation.
IMO this is stupid because it appears that I'm the only one it's targetted at as I'm the only one that regularly commits to the ARM section of the kernel and it doesn't appear to apply to anyone else.
Untrue. It's targeted at anyone that wants to get a patch into the kernel that doesn't have a bug attached to it, or wants to bring in something not clearly headed into mainline. For example, Daniel Stone asked for an evdev patch to get in and I told him to post it here or file a bug and I'd grab it if it looked good. Neither happened, no patch has been pulled in.
It would be useful for you to advertise this intention and send things like details out to the kernel mailing list. I'll need to re-read my IRC logs but I don't remember you mentioning any of the above, which does sound reasonable, to me in the conversation we had. I'm not sure the conversation that was outlined in the ARM mailing list but it sounds like something that should be broadcast more to the Fedora kernel list.
You aren't wrong, and I'll be sure to do that with some of the stuff we're thinking about that came up last night. However, there are literally 4 people that commit. I thought I had spoken to each of them individually. Seems my memory is going.
We aren't making special rules just for you.
We maybe it's just the way it seems as until now I've not seen anyone else be targeted prior to this.... maybe it's just me doing work!
See the thread with Kyle from last night. Seriously, stop thinking we're targeting you.
to now was any issue that might affect non ARM was sent to the list [1] for approval and for anything ARM related you always made it abundantly clear that it was the ARM teams problem to deal with whether it be a bug or a patch, any time there's been a patch that hasn't applied you've just commented it out and pinged me to deal with it and I always have whether it be to rebase or drop. Any time there was a bug report you reassigned it to ARM people.
It's not that simple any more. For 2 years we could do that because ARM was a secondary arch and things proceeded regardless of what happened there. Now, because of the good efforts of the ARM team, it's primary. Which means we wait, and we should arguably care a hell of a lot more about it. We can't just drop patches in f20 and rawhide and potentially break ARM because that isn't how a primary arch should be treated.
Is that round about terms meaning that the Fedora kernel team are going to start to assist in the ARM issues :-D
Not exactly. It's more "hey, primary arches aren't supposed to be broken willy-nilly, so we should probably pay attention to ARM more now and not break it at random." That's not so much "assist" as it is "do no harm".
I try to help and keep the impact of ARM down for you guys but kernel isn't a core skill I ever thought I wanted to learn (I often say about ARM that I now know more about the Fedora Core OS and kernel than I ever thought I wanted to know!) and if the process becomes too arduous I stop enjoying it and I'll go and find some other project to get my teeth into as there's no shortage. I'm not saying here that the process doesn't need to change and improve but just be aware I think it needs balance and it needs to be measured so that you don't scare off the people that are trying to help you.
Please review the thread with Kyle last night. That's kind of where we're headed and feedback on that would be good.
Also, for the past several years we've been less than transparent about what patches we take and why we take them. Not just for ARM, but overall. I think we need to fix that. I think having a bug attached to it is fairly clear. If there's no bug, post to the list. This isn't extremely difficult to do and it applies to everyone.
Well I don't think targeting me (at least that's what it appears to me) is the way to fix that. I don't see any wider announcement to the
I'm beginning to believe that there is nothing I can say that will convince you that we aren't targeting you. Do you have some kind of persecution complex :)?
list or even updated on the Kernel wiki page. In fact to quote from the wiki "If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable)."
The wiki is a horribly out of date thing. To be honest, I haven't read the wiki in months. Point taken, we'll update it, possibly by just deleting a lot of things. Then probably adding whatever we come up with here.
As I said before, config changes are probably fine without posting. Patches, particularly out-of-tree patches, should get some simple review.
Probably fine? If they're more widely impacting I will most certainly post them just like I've done them in the past. Personally I think I have a pretty good overview of the impact of config changes in the ARM sphere and I think it then becomes arduous for all involved.
Sure. Wide ranging things can get posted as you have done. I was mostly referring to the "toggle 3 ARM drivers in the ARM configs" kind of things. To be honest, I'm good with posting everything, but I was trying to avoid additional burden.
In simple view, you are correct. It doesn't break anything else. In the larger view, I really want to start backing away from random patch grabs. Upstream has a review process for a reason, and I'd like to leverage that for patches we carry. Otherwise we wind up carrying patches that are "getting in RSN" which aren't actually getting in any time soon.
Believe me I don't like patch grabs either! But similar to secureboot there are some that are useful such as the BeagleBone Black support and some other devices that are key to getting people engaging and
Sure. Post them, we'll get them in.
using Fedora on ARM and I believe in those cases, like secure boot, the patches are justifiable to open Fedora on ARM and Fedora in general up to a wider audience.
Absolutely. That doesn't mean they shouldn't get posted (and tracked in patchwork if we go that way). It's arguable we want them reviewed even more closely because they're going to impact a wider audience with the explicit goal of attracting people.
Really, it's about knowing where things are coming from and where they're headed, and making sure we aren't grabbing incomplete stuff from upstream. The conversation with Kyle from last night on this list go towards that too, so please weigh in.
josh
It would be useful for you to advertise this intention and send things like details out to the kernel mailing list. I'll need to re-read my IRC logs but I don't remember you mentioning any of the above, which does sound reasonable, to me in the conversation we had. I'm not sure the conversation that was outlined in the ARM mailing list but it sounds like something that should be broadcast more to the Fedora kernel list.
You aren't wrong, and I'll be sure to do that with some of the stuff we're thinking about that came up last night. However, there are literally 4 people that commit. I thought I had spoken to each of them individually. Seems my memory is going.
Maybe, as it wasn't on list I couldn't comment, at least from the conversation you had with me I didn't get the idea that this was a general change of direction so maybe there was some miscommunication.
We aren't making special rules just for you.
We maybe it's just the way it seems as until now I've not seen anyone else be targeted prior to this.... maybe it's just me doing work!
See the thread with Kyle from last night. Seriously, stop thinking we're targeting you.
I have seen it now (mailing lists are good for procrastination!), this thread pre dates that though.
Is that round about terms meaning that the Fedora kernel team are going to start to assist in the ARM issues :-D
Not exactly. It's more "hey, primary arches aren't supposed to be broken willy-nilly, so we should probably pay attention to ARM more now and not break it at random." That's not so much "assist" as it is "do no harm".
:-D well the upstream ARM people seems to manage to do that all on their own... see omap4 and Panda* state as a perfect example of that :-P
I try to help and keep the impact of ARM down for you guys but kernel isn't a core skill I ever thought I wanted to learn (I often say about ARM that I now know more about the Fedora Core OS and kernel than I ever thought I wanted to know!) and if the process becomes too arduous I stop enjoying it and I'll go and find some other project to get my teeth into as there's no shortage. I'm not saying here that the process doesn't need to change and improve but just be aware I think it needs balance and it needs to be measured so that you don't scare off the people that are trying to help you.
Please review the thread with Kyle last night. That's kind of where we're headed and feedback on that would be good.
I've read and replied on one point. I've never used patchworks but seen it a lot around so I can't really comment on that specifically but it seems useful. On the rest it seems mostly OK.
Also, for the past several years we've been less than transparent about what patches we take and why we take them. Not just for ARM, but overall. I think we need to fix that. I think having a bug attached to it is fairly clear. If there's no bug, post to the list. This isn't extremely difficult to do and it applies to everyone.
Well I don't think targeting me (at least that's what it appears to me) is the way to fix that. I don't see any wider announcement to the
I'm beginning to believe that there is nothing I can say that will convince you that we aren't targeting you. Do you have some kind of persecution complex :)?
Nope! It's mostly just from what I've read myself and I've had others comment to me "Wow what did you do wrong to piss jwb off so bad" but I believe you now. Maybe it's just a communication problem. Believe me I generally couldn't give a shit and hell... I've been dealing with the pain of ARM kernel stuff for nearly two years now and I'm mostly still sane (shush!) and I'm still here...
list or even updated on the Kernel wiki page. In fact to quote from the wiki "If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable)."
The wiki is a horribly out of date thing. To be honest, I haven't read the wiki in months. Point taken, we'll update it, possibly by just deleting a lot of things. Then probably adding whatever we come up with here.
Even if you delete a lot of it and put a message "if your unsure go and ask on the kernel mailing list and #fedora-kernel IRC" :-)
As I said before, config changes are probably fine without posting. Patches, particularly out-of-tree patches, should get some simple review.
Probably fine? If they're more widely impacting I will most certainly post them just like I've done them in the past. Personally I think I have a pretty good overview of the impact of config changes in the ARM sphere and I think it then becomes arduous for all involved.
Sure. Wide ranging things can get posted as you have done. I was mostly referring to the "toggle 3 ARM drivers in the ARM configs" kind of things. To be honest, I'm good with posting everything, but I was trying to avoid additional burden.
Presumably the config updates during the rawhide kernel devel merge window is a special case here ;-)
In simple view, you are correct. It doesn't break anything else. In the larger view, I really want to start backing away from random patch grabs. Upstream has a review process for a reason, and I'd like to leverage that for patches we carry. Otherwise we wind up carrying patches that are "getting in RSN" which aren't actually getting in any time soon.
Believe me I don't like patch grabs either! But similar to secureboot there are some that are useful such as the BeagleBone Black support and some other devices that are key to getting people engaging and
Sure. Post them, we'll get them in.
I'm trying to get that done for 3.12 atm so that we can get some wider testing
using Fedora on ARM and I believe in those cases, like secure boot, the patches are justifiable to open Fedora on ARM and Fedora in general up to a wider audience.
Absolutely. That doesn't mean they shouldn't get posted (and tracked in patchwork if we go that way). It's arguable we want them reviewed even more closely because they're going to impact a wider audience with the explicit goal of attracting people.
Yep, seems reasonable.
Really, it's about knowing where things are coming from and where they're headed, and making sure we aren't grabbing incomplete stuff from upstream. The conversation with Kyle from last night on this list go towards that too, so please weigh in.
Yep, it sounds reasonable, I've always tried to provide a comment in the .spec to where I've pulled a patch from as much as for my own sanity and memory :-)
Peter
kernel@lists.fedoraproject.org
-
Amit Shah -
Josh Boyer -
Peter Robinson