From: pebenito@ieee.org (Chris PeBenito)
Date: Wed, 8 Feb 2017 22:19:45 -0500
Subject: [refpolicy] policy releases
In-Reply-To: <47972742.QHH7Tdg2Tm@russell.coker.com.au>
References: <1716668.X9W763Kd3L@russell.coker.com.au>
	<59007870-6ef9-1d3d-d12e-6921e59a8ebd@ieee.org>
	<47972742.QHH7Tdg2Tm@russell.coker.com.au>
Message-ID: <8f42a741-0bfc-2701-cec8-77678b07a2e3@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 02/08/17 20:27, Russell Coker wrote:
> On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote:
>> On 02/07/17 22:09, Russell Coker via refpolicy wrote:
>>> Could we have a shorter delay between official releases of refpolicy than
>>> normal for this cycle?
>>
>> I'm open to something sooner, to a point; perhaps a month.  I'd like to
>> make sure everyone, especially distros, have sufficient time to try out
>> the usrmerge stuff.
>
> Are the other distro maintainers trying out the git changes?
>
> I usually don't test git code, I only test it when it is part of a release.
> I'll only test git code if there is a significant amount of time and patches
> elapsed since the last release (like a year).  If you are hoping that I will
> test patches you accept from other people then it's not going to work out.
>
>>> Including the usrmerge patch in git makes most file context patches
>>> against
>>> the release policy not apply to git which is a significant annoyance when
>>> submitting patches upstream.
>>
>> As a former distro maintainer, I sympathize.  However, that kind of
>> problem is what you're signing up for when you do distro maintenance.
>> At least having two statements in differing order generally has no
>> impact for policy, unlike for code patches.
>
> It's a problem that you sign up for, but also something that can be reduced as
> a time sink by just not sending patches upstream as often.

True.  To be clear, I don't want to make it hard on maintainers, I'd 
rather it be easy.  But I also don't want to put out releases every 
month, without consideration of the policy state.


>>> I would also like to get most of the systemd patches I have merged soon,
>>> which also adds a significant point of conflict between release and git.
>> A large systemd change is another reason to provide enough time for
>> people to try out the changes.
>
> Again that theory only holds if people are actively testing git policy.  Is
> that happening?

It's a fair question, but my understanding is some people to test it out.


-- 
Chris PeBenito