> It would be useful for you to advertise this intention and send
> 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
> 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
"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
> I try to help and keep the impact of ARM down for you guys but
> 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
>> 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
> 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
>> Patches, particularly out-of-tree patches, should get some simple
> 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
>> 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
> 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
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 :-)