[Open-scap] [PATCH] Update RHEL6 OVAL file to ignore world-writable files in /proc/ directory

[Martin Preisler]

----- Original Message -----
> From: "Petr Lautrbach" <plautrba at redhat.com>
> To: "Martin Preisler" <mpreisle at redhat.com>
> Cc: open-scap-list at redhat.com
> Sent: Tuesday, August 5, 2014 4:30:19 PM
> Subject: Re: [Open-scap] [PATCH] Update RHEL6 OVAL file to ignore world-writable files in /proc/ directory
> 
> On Tue, Aug 05, 2014 at 09:56:15AM -0400, Martin Preisler wrote:
> > > So when I want to try and test the latest sources then I should use the
> > > maintenance branch?
> > 
> > Not really. We have multiple branches, not just one "source". We have
> > latest source for the 1.0 branch, we have latest development code
> > (master). There is no single "latest source". We might even fix something
> > in the maintenance branch that was completely removed in master. The
> > change would be the latest (as in most recent) but you definitely don't
> > want it in master. I hope all is clear now.
> 
> How could one know which commit would be merged and which not? And how long
> should one wait if one follows the master branch?

Please note that we are talking about merging here, no cherry-picking, grafting or backporting. Long story short: every commit gets merged from maintenance to master by default. You have to take extra steps to avoid that. This is in contrast to backporting where you have to take extra steps to get the commits to the maintenance branch and nothing gets there by default.

We have guidelines for all of this, it's no rocket science. See http://open-scap.org/page/Versioning

> > I don't think merging from maintenance to master after every commit is
> > worth it and as it bloats the repo. The changes will for sure be merged
> > before releases.
> 
> I agree that it is not worth to bloat the repo, but I personally would rather
> change the process instead of delaying merges into
> master branch.

You had the opportunity when I was writing the Versioning guidelines and requested feedback. Still, I welcome any comments, so please go ahead and suggest improvements.

-- 
Martin Preisler