[PATCH] Added 'make rpm'

Spencer R. Shimko sshimko at tresys.com
Mon Apr 2 18:44:54 UTC 2012


On 4/2/12 2:35 PM, "Jeffrey Blank" <blank at eclipse.ncsc.mil> wrote:

>
>Spencer, is there a project with a similar workflow that you believe
>does this in a preferable way?  We will reach resolution on this (but I
>am swamped today).

Yup the libvirt project.  They actually started down a similar path as SSG
without the need for ACKs before merge.  But as the project matured and
the number of contributors grew the work flow changed to the ACK/NACK
model.  As another example the SELinux userspace project follows this
model.  SELinux's userspace workflow changed fairly recently.  Now they
queue submitted patches in what is effectively a second branch.  Then
someone (anyone) pops a patch off the queue in that branch and ACKs/NACKs
it and it gets merged into master.

>
>
>> I'd prefer to wait for at least one ACK before pushing.  IMO an ACK from
>> anyone with commit access should be sufficient for a merge/push.
>>Thoughts?
>
>
>Commits that involve moving directories or adding Makerules should
>definitely be vetted by a second party.  I think more minor stuff (like
>adding SCAP content such as references or new Rules) is fine for direct
>commit.  I also need to document some rules for writing Rules (ahem) on
>the wiki, to ensure proper granularity.

I agree the content is straight forward and *shouldn't* be an issue. But
there is always the chance it will break something, e.g. someone forgot to
"git add" a file and the build system breaks.  Perhaps just an elimination
period?  If someone posts something and 48 hours later hasn't gotten a
NACK they are free to merge.  I like some form of acknowledgement but I'm
not too stuck in my ways so if we just do straight merges and "advertise"
master->HEAD as possibly unstable I think that is fine too.

Thanks,
--Spencer
>_______________________________________________
>scap-security-guide mailing list
>scap-security-guide at lists.fedorahosted.org
>https://fedorahosted.org/mailman/listinfo/scap-security-guide



More information about the scap-security-guide mailing list