On Wed, Jul 16, 2008 at 4:18 PM, David Härdeman <david@xxxxxxxxxxx> wrote: > On Wed, Jul 16, 2008 at 03:40:29PM -0400, Daniel J Walsh wrote: >> 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. The difference being that Linus has trusted subsystem maintainers and anything from those people are pulled into his tree without any review. Linus actually looks at (relatively) few patches these day. As an example look at how Linus doesn't add his 'Signed-off-by' to SELinux patches. He didn't review them or even look at them. He trusted James and so in they went. In the policy world Chris looks at every single patch and we don't have any 'trust' from other people to commit. The main reason for that being that we only really have one other person in the community who really does a lot of active development (Dan) and he is the first to tell you that his primary motivation is to fix user problems and move on rather than try to 'do what is right for the technology." He doesn't have time to follow strict (unwritten) style guidelines or verify that every change is 'the right way' for upstream. Just not enough man hours in the day. As an example if my fedora sendmail program starts needing bogus permissions Dan is going to allow it in Fedora policy and will push back on the sendmail people to stop it from needing that bogus access. This shouldn't (and doesn't usually) get pushed towards upstream. What Dan doesn't have time for is to go back this quick fixes make sure they are clean and documented, and send them along. We have time constraints on both Dan and Chris. I'm told the Red Hat is trying to hire a new person to work full time on nothing but policy. My guess is that as this person becomes knowledgeable enough direct commit access to the upstream refpolicy will be given allowing him to bypass Chris. Chris will probably still be the overlord and might kick things out that he doesn't like (much as Linus does in the kernel) after the fact, but until there are multiple people who both can and want direct commit access this isn't going to resolve. (I don't think Dan even wants upstream direct commit access but I could be wrong) I don't think there is a solution with the manpower we have today to fix the issue of the ever growing backlog. My guess is that if you start showing Chris and the community that you can decide what from the monstrosity that is the Fedora patch set is reasonable and ready for upstream you can get direct commit access. Tresys is not trying to be a bottleneck, stranglehold, dictator, or sole proprietor of the policy they just happen to have the man who cares about the code above all else and he is rightfully the maintainer. If more people come along and want to do what's right for upstream we can start working on the web of trust rather than the one man show we have today. (moving the actual repository from tresys to sourceforge or to fedoraproject won't magically solve any of these issues. I haven't seen tresys reject developers, I just haven't seen nearly enough developers) The solution? Take what you find, clean it, send it, get it in through Chris. Hopefully RH will have a person to do the same soon! -Eric -- 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.
