On Wed, Jul 16, 2008 at 03:40:29PM -0400, Daniel J Walsh wrote:
All of these suggestions are fine and yes if we had to do it all over
again, every change would be documented with links to bugzilla.emails,
conversations in the hall. I am looking for help to get it better under
control. I am not looking for direct commit, or at least a commit via
an ack process.
I'm sorry, but I still haven't understood what *kind* of help you're
looking for...except for wishing Chris had > 24h per day. :)
Patches have been sent up stream in the past that have got lost in the
volume of work that Chris has to do. Not his fault. But we have a
system where we have only one person whose primary job is not to check
in policy patches, having to review every patch.
So obviously something is wrong in the refpolicy patch acceptance
process? As a comparison, every single patch is applied by Linus to the
kernel (even though they've been filtered by maintainers first) and going
from 2.6.25 to 2.6.26-rc1 alone was 7555 patches.
And we have the person
generating most of the policy falling further and further behind. While
the kernel has teams of engineers working on patches, reviewing them and
applying them. They also have people who just cherry pick obvious fixes
and apply them.
Well, I still don't know what should be done? Just splitting the RH patch
into per-module patches was a great help to me. Out of those 200+ patches,
about 50% were less than 100 lines and I'm guessing around 50% are of the
no-brainer kind (3 were 1000+ lines). If those 50% could be identified and
applied in quick succession by Chris...the RH patch wouldn't shrink by 50%
in number of lines but it would shrink by 50% in number of modules affected.
--
David Härdeman
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
