On Wed, Jul 16, 2008 at 02:59:40PM -0400, Daniel J Walsh wrote:
Christopher J. PeBenito wrote:
On Wed, 2008-07-16 at 19:44 +0200, David Härdeman wrote:
On Wed, Jul 16, 2008 at 01:13:03PM -0400, Daniel J Walsh wrote:
David Härdeman wrote:
While working on SELinux-enabling a Debian system, I often Google for
avc messages that show up in dmesg and 90% of the time it seems that the
problem has already been solved in Fedora's version of the refpolicy but
not in the upstream version.
...
The question is how to treat the patches after that? Should I post them
as I go through them (a couple per day for a couple of weeks?) and hope
that someone at Tresys will apply them?
[...]
I guess what I'm really wondering is if I can help you in some way?
The main points which would improve upstreaming efficiency from Dan's
set are:
1. description / justification
...
2. style
...
3. patch composition
...
Basically all three requirements are the same as the general rules that
apply for patch submissions to the linux-kernel mailing list (or to any
well-behaved OSS project).
And the problem I have with all of these is volume of change. When a
new release goes out and a whole bunch of new users start using SELinux
the volume of bugzillas generated is use. My first responsibility is to
get SELinux fixed for these users.
I can't imagine that a one-line commit comment would be an overwhelming
burden when committing a couple of lines of policy changes? Heck, most
maintainers should welcome it as it serves as a support for their own
memory as well...I mean, most of these issues aren't exactly new for
FOSS projects and SCM repos is the best answer people have come up with
so far...
Marking up the policy with lots of
bugzilla's or justifications is both time consuming and I believe just
dirties the policy.
Comments about patches are generally carried as commit messages and not
inline. I don't see how it would dirty any policy. And in-line comments
for unconventional changes I'd see not as "dirty" but as a great help to
the person reading through the policy (I've already had a few "huh?"
moments when reading through the RedHat patch, and that's not because
they are bad in any way, its because its inevitable without the proper
context).
In the more bizarre categories that should be
required. My goal is to get the non-bizarre changes upstreamed so we
could concentrate on the bizarre ones and either justify or remove them.
The question is if it's even possible to hunt down the original
explanation for the bizarre ones after a few hundred of them have
accumulated and they have been obscured by the passing of time?
Changes like adding fs_list_inotify should just get into the upstream.
I realize I'm stepping into a debate which is somewhat over my head
here, but couldn't Tresys arrange so that you get direct commit access,
then you could commit trivial patches directly and send more
unconventional ones to the list for discussion?
Or alternatively...perhaps a shadow branch could be setup where the
commit rules would be more lax and then the changes could be synced over
at intervals...
(Or even better, everything could be done via git...but that's a
pipedream at this stage) :)
--
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.
