On 11/01/2017 05:18 PM, Steve Beattie wrote: > On Wed, Nov 01, 2017 at 03:46:17PM -0500, Tyler Hicks wrote: >>> Am Mittwoch, 1. November 2017, 08:27:12 CET schrieb Steve Beattie: >>>> There more work to do to flesh out the above and standardize on some >>>> practices around git, but this should let us make progress. >>> >>> One thing we use for the openSUSE infrastructure salt code is the >>> "Protected Branches" feature: >>> https://docs.gitlab.com/ce/user/project/protected_branches.html >>> >>> Protected branches prevent force pushing and deleting a branch, which >>> IMHO makes sense for master and the apparmor-* maintenance branches. >>> (Ideally we'll never notice that we have that sort of protection, but it >>> helps to prevent accidents.) >> >> This sounds like a very good thing to enable. > > Agreed, I'll set this up for the apparmor and apparmor-profiles repos. > >>> That's something time will tell, and it probably also depends on the >>> size of the patch. (I'll assume everybody has notifications for new merge >>> requests enabled in the gitlab config, right? ;-) >> >> I recently contributed a fairly complex patch set to a GitHub project >> and will assume that it is a similar experience in GitLab in order to >> give my opinion here. >> >> I really enjoyed the web-based merge request workflow and think it can >> be an improvement over the mailing list patchset based flow. However, >> I'd strongly recommend that we require contributors to: >> >> 1) Create a merge request >> 2) Receive feedback from maintainers >> 3) If changes are required, fold changes necessary to address feedback >> into the existing patches, rebase, and force push to their merge request >> branch. >> >> #3 is necessary to avoid a bunch of fixup patches that shouldn't be >> standalone. It also makes for an bisect-able tree since there's no >> broken commits being merged (with separate fixup commits). >> >>> I also wonder how to handle the Acked-by messages in case we use merge >>> requests - while it's possible with git rebase + using the "reword" >>> keyword, it means we'll have to force-push to those branches before >>> merging them. >> >> What the maintainer did for the GitHub contribution that I mentioned >> above was to merge my pull request into a local branch, interactive >> rebase to add his Signed-off-by, and then push the resulting branch to >> to the master branch on GitHub. > > Do you have a pointer to the merge request/commit so that we can see > what that ended up looking like in git?
PR: https://github.com/seccomp/libseccomp/pull/92 My branch for the PR: https://github.com/tyhicks/libseccomp/commits/improved-logging Upstream commit log after merging: https://github.com/seccomp/libseccomp/commits/0cc7203760c4776c67602a531bd633aba63a7851 Tyler
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
