[kernel] enable crash on other architectures

[Kyle McMartin]

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.

> > 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...

> >> > 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.

--Kyle