On Fri, Dec 9, 2016 at 8:59 PM, Marek Marczykowski-Górecki wrote: > I think handling contributions there can be easily automated with > https://github.com/QubesOS/qubes-issues/issues/1818 > So, the only actual work needed, will be reviewing changes, then adding > a signed tag. Everything else will be handled automatically.
I think an important open question is: How should code-reviews be tracked? I think qubes-builder's model of not having untrusted code in the place that trusted code may be expected [1] is a good model. The same can be applied here with respect to pushing un-reviewed vs. peer/qubes-core reviewed code to "official" repos. I imagine this: 1) A community member comes up with some cool thing they want to add to qubes, which is clearly additional separate functionality that does not belong in a core repo. (Thinking qubes-app-linux-* here.) 2) The community member writes said code in their own repo. 3) When they consider it v1.0, they propose for it to be added to the set of core-approved community-contributed things. 4) The code is reviewed by core qubes people (and hopefully other community members) and a the reviewed copy is added to a newly created github.com/qubesos-contrib/qubes-app-foo-bar repo. 5) The community member makes some additional changes (features, bug fixes, etc.) and pushes it to their own repo, and opens a pull request to the qubesos-contrib/... repo. 6) The updates are reviewed, and if OK, merged. This maintains the invariant that qubesos-contrib/... repos (all heads of all branches) are always in a reviewed (and hopefully trustworthy) state, which I argue is a nice property. Some issues with this: 1) There is no longer any reason for the community member (and author of the contributed component) to be a member of the 2nd github organization (no nice badge on their github profile, which for some may serve as incentive to contribute) 2) If everything is to be reviewed before merging, then there is less of a reason to have a separate qubesos-contrib org in the first place. 3) How should patches to these contributed components from people other than the original author be handled? Should we require they be merged (or at least OK'd, perhaps with some timeout) by the original author? [1]: https://www.qubes-os.org/news/2016/05/30/build-security/#the-sources-verification-bug -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_DLKB2hTjNUKXagb1TidgXSMksmrHcj%3DxF1vG0e%2BRo%3Duw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
