[kernel] enable crash on other architectures

[Josh Boyer]

On Tue, Nov 5, 2013 at 8:23 PM, Kyle McMartin <kmcmarti at redhat.com> wrote:
> On Tue, Nov 05, 2013 at 07:48:36PM -0500, Josh Boyer wrote:
>> I like the idea of patchwork.  I've used it before.  Let me talk to
>> the infrastructure guys to see if we can get one set up.
>>
>> It would still require posting patches first.  Perhaps with the
>> limited number of reviewers we could do something like "post, tracked
>> in patchwork, at least one ACK" ?  Or did you have another idea?
>>
>
> That would be fine with me, and it would also give you and Justin a
> place to look for patches to commit before a build. Additionally,
> patches could be scratch-built or cross built or something to avoid
> breaking the build when built in koji.

Yeah, that sounds fairly good.  Maybe eventually we'll get to a point
where status changes in patchwork change associated bugzilla entries
to POST, MODIFIED, etc.  Let me look into what we can get hosted, etc.

About the only thing this doesn't work well for is upstream rebases.
Not sure there's much we can do there.

Would we consider "patch" here to just be the patch being added, or
would it also include the changes to the kernel.spec file for the
PatchNNNNN, ApplyPatch, %changelog additions?  I was mostly thinking
just the actual code patch, but I can see cases for both.  Thoughts?

>> > Also the kernel ACL should probably be cleaned up. ;-)
>>
>> Yes.  I'll look at that tomorrow.
>>
>> > I'd be happy to give up commit permissions if there was some accountable
>> > system in place beyond just begging for ACKs.
>>
>> I'm not sure giving up commit permissions is required or even wanted.
>> We don't want to get ourselves into a position where people are held
>> up because someone is on vacation.
>>
>
> Well, there's three of you? ;-P and given builds are limited to a much
> smaller set than the ACL...

Sure.

>> >> > documenting fixes to your patches beyond the %changelog is a waste of my
>> >>
>> >> %changelog is pretty limited.  Works great for bug numbers, kinda crap
>> >> for everything else.
>> >>
>> >
>> > No, but it does what you asked for, describes why something is there.
>> > Justifying why some random patch that's been in the tree more than six
>> > years isn't the job of my changelog entry, saying what I did was. And
>>
>> Yes, true.
>>
>> > given git makes it trivial to see all the changes (the config addition,
>> > the .patch change, and the %changelog entry...)
>>
>> So there's two things I'm concerned about in general.  1) Knowing why
>> a patch is added, which %changelog can cover, 2) knowing where it came
>> from (and where it's headed).
>>
>> Call that latter one "upstream status.  We could perhaps make that a
>> requirement of the git commit log, or part of the patch itself in a
>> specific format.  I've been trying to do this kind of ad hoc by
>> keeping PatchList.txt up to date in f20 and rawhide, but I have to
>> admit it kind of sucks.  Having it be part of the patch file itself
>> might make things easier.
>>
>
> That's fine with me.

OK.  I'll maybe poke at the existing patches later this week and add
the information to them.  The more I think about that, the more I
think it will make some things easier if we have a fixed format for
the information.  Like being able to run a tool against *.patch and
generate the monthly patch report for upstream.

josh