[kernel] enable crash on other architectures

[Josh Boyer]

On Tue, Nov 5, 2013 at 7:30 PM, Kyle McMartin <kmcmarti at redhat.com> wrote:
> On Tue, Nov 05, 2013 at 07:20:00PM -0500, Josh Boyer wrote:
>> > Fine, whatever, given this is a requirement no other package seems to
>> > have, I'm disinclined to contribute further. Congrats. Also, I think
>>
>> That's a fair point.  Would you suggest we stick with a model that
>> stuff gets put in and we figure out why later if it breaks or why we
>> added it?  I'm not asking that sarcastically.  My goal is to improve
>> things, not make them worse for arbitrary reasons.
>>
>
> Given there's a limited subset of people who can trigger builds, I'd be
> happy to see something more ``professional.'' But only if there's
> accountability. If people could submit patches to patchwork or
> something, and monitor their status, versus just getting an OK to commit
> on a mailing list with no guarantee of feedback, I think that would go
> along way.

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?

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

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

josh