[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