From: martin@martinorr.name (Martin Orr)
Date: Wed, 02 Feb 2011 23:52:58 +0000
Subject: [refpolicy] [PATCH/RFC 0/19]: patch set to update the
	git	reference policy
In-Reply-To: <1296508737.18286.54.camel@tesla.lan>
References: <1295397630.3377.10.camel@tesla.lan>
	<4D383627.60804@tresys.com> <1295544776.4702.16.camel@tesla.lan>
	<4D397E26.4090904@tresys.com> <1295829820.3862.59.camel@tesla.lan>
	<4D471319.2000907@tresys.com> <1296508737.18286.54.camel@tesla.lan>
Message-ID: <20110202235258.96745g5m1222lvwo@webmail.tuffmail.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon 31 Jan 21:18:57 2011, Guido Trentalancia wrote:
> On Mon, 31/01/2011 at 14.52 -0500, Christopher J. PeBenito wrote:
>> One thing I want to clarify for each of the actual patches you need:
>>
>> * a better subject: "patch set to update the git reference policy" isn't
>> very informative.
>
> Then, it would probably be impossible to submit a patch set at all. We
> will just have many individual, separate patches. Because the whole
> patch set aims to tackle very different issues in many different places
> that it would probably be impossible to summarize everything in the
> subject.

I think this is the point: because you deal with many different  
issues, you do not really have a "set".  Chris can decide  
independently for each of the patches whether to apply it or not, and  
that will (usually) not break and will cause a measurable improvement  
in refpolicy.

The subject of each patch should be a short summary of what that  
individual patch does, for example "dbus file labelling" for patch 1  
and "Allow dbus messages" for patch 2.  If you can't give such a label  
to a particular patch, that might mean that you have divided up your  
patches badly.

>> * a detailed description of what the patch does.
>
> Sure. It will be done.
>
>> This will help facilitate review of the patches, and will help us
>> understand the details.
>
> In general, the set of patches is the result of testing refpolicy on a
> very recent generic Linux installation. It aims to fix generic issues
> with a few essential modules while trying to use the latest refpolicy on
> a recent unbranded Linux installation.

-- 
Martin Orr