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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
