From: jason@perfinion.com (Jason Zaman) Date: Thu, 9 Feb 2017 10:16:25 +0800 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: <20170209021625.GA6479@meriadoc.perfinion.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, Feb 09, 2017 at 12:27:53PM +1100, Russell Coker via refpolicy 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. Yep. So let me explain gentoo's workflow a bit. It's a little different cuz gentoo is rolling and not release based so waiting for refpolicy releases doesnt really work. I only use gentoo's hardened-refpolicy (official repo is here: https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ i mirror to my github too). Our release script (gentoo/release-prepare.sh) makes a big patchfile on top of the latest refpolicy release then our ebuilds extract refpol and apply the patch on top. Our releases are -r. eg currently for sec-policy/selinux-base: Available versions: 2.20151208-r4 2.20151208-r6 2.20161023-r1 2.20161023-r3 (~)2.20161023-r4 (**)9999 The 9999 version will pull the latest git HEAD and its what swift and I mostly use during dev. Before each release we pull in any changes from the refpol upstream repo and merge them into the gentoo one. For gentoo-specific things i'll apply them to our repo (almost always inside an ifdef distro_gentoo block). Otherwise I generally prefer to submit the patches upstream first then pull back down. I'll skip upstream if its a policy that we havent upstreamed yet or if something is super broken and I need to make a release right away. (or if im lazy ...) Mainly its cuz things are rolling, i'll only see that something is broken when it gets installed on my or someones system and they file a bug. so if eg apache had a problem and it just got stabilized i cant wait months for the next refpol release because people are using it. That said, more frequent releases is definitely not a bad thing at all, it just isnt as vital for my workflow as others. I *think* nicolas has a similar patchset on top of the git repo for Arch but not sure exactly. So to come back to your original question, yes, upstream git is tested very extensively on gentoo and the version numbers are somewhat meaningless in a way. I've been meaning to make a few blog posts about the selinux workflow in gentoo but havent had the time yet :(. Kind Regards, Jason > > > > 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. > > > > 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? > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy